Sisoft GPGPU benches

Not sure this is true... this definitely all goes through the WDDM in DC, and perhaps in CUDA too (depending on whether they tunnel it through there or try to abstract their own little space). Typically the WDDM/OS owns all GPU memory and command buffer submission on Windows though, so normally anything that goes to the GPU goes through there in some manner.

Now obviously an IHV can go around that (rather than through it) to some extent with things like CUDA, but potentially with some pitfalls.

 

How much direct access does MS allow to hardware? Wasn't WDDM a move towards removing direct access in order to reduce the chances of a buggy driver blue-screening the OS?

Or a problem piece of hardware doing the same?

Regards,
SB

 

Since DirectCompute runs within DirectX (and even uses the D3D driver), buffer sharing is trivial. Sharing buffers between other APIs (such as between OpenCL and OpenGL) may be more problematic.

 

Let me rephrase--the additional overhead imposed by WDDM versus other driver models (e.g., the cost of accessing hardware in Linux) should cause no meaningful performance penalties in the basic streaming case. What I was wondering in particular is if DC could be faster because of some hooks into WDDM, for instance (to avoid some additional user/kernel transitions), but I don't know enough about DC to be able to say either way.

 

Do CS kernels count as being evil in terms of the concurrent kernel execution stuff or do they behave nicely in NV-GPUs and do not block the chip for their duration?

 

Agreed, although it all depends on how - for instance - the CUDA and OpenCL runtimes are implemented with respect to WDDM. There's always a possibility of some inefficiencies there, although again I'd assume that with simple streaming kernels we're going to be far from CPU-limited.

I'm assuming this is a limitation of current NVIDIA hardware (specifically since it is called out as a benefit of Fermi) rather than anything in software. Thus I expect DC on current NVIDIA hardware to behave like the other APIs.

 

SiSoft's own benchmark numbers:

SP/DP: http://sisoftware.co.uk/index.html?dir=qa&location=cpu_vs_gpu_proc&langx=en&a=

Bandwidth: http://sisoftware.co.uk/index.html?dir=qa&location=cpu_vs_gpu_mem&langx=en&a=

 

Their PCIe numbers are totally crazy; getting 5+GB/s on NV hardware (and AMD hardware, for what it's worth) is trivial. Maybe they're using paged memory?

edit: yeah, I get 5.8/5.2 GB/s on my i7 system for pinned memory and 3GB/s bidirectional for paged, but PCIe transfers from paged memory are more of an issue of CPU memcpy bandwidth than PCIe performance (which is why they're so radically higher on Nehalem than previous Intel CPUs).

 

Totally crazy PCIe numbers? sure!

I get 0.4 GB/s in OpenCL on 4850.

And this one :



1/8th memory transfer performance.

 

I didn't even take the time to check the graphs properly.. but what about the CUDA/OCL variance between two essentially the same platforms, the 9400M and ION?

 

There is a new version of SiSoft Sandra 2010: 1611.
How can I get OpenCL working with my HD4850? OpenCL&CPU work.

 

I don't get it to work with HD 5870 either. Freshly installed Windows 7, Cat 9.11 WHQL, Sandra 1611, Stream SDK 2.0 b4 - Stream and Direct Compute work, but I don't get anything Open CL.

Any hints?

 

Wait for tomorrow's Cats and pray Terry did his job?

 

Hopefully - thx for the exceptionally helpful hint btw

edit:
Never mind - seems like a royal FU with Sandra 2010-1611 or with me. Everything else OpenCL works.

 

A hint would be something about a GTS330, GTS350, GTX360/380 and HD5830 and 5890.. I'm not giving those

 

I meant that rather sarcastic, given that everyone in the world and their dogs follow Terry on Twitter.

 

He never said it would support OpenGL 3.2 though.. (but that's not the subject at hand)

 

http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=72

It works.