luv2increase

fredbsd

I had time to install driver, SDK, etc.  Haven't had time to configure it all.  The Linux binary distributed w/ that program did not work.  I'll look into later.  It's probably something simple.

Thanks!  Keep us updated on how it goes.

Indeed!!

and thanks for posting that 'insight from a compiler writers perspective' post.

I think I needed it the worst! 

My tail is wagging higher again after reading that...

Thanks for that tip too.

My call to Nvidia to sound the Red Alert on OpenCL Benchmarks...  

http://forums.nvidia.com/.dex.php?showtopic=154318

I took your outstanding link too:

http://www.hpcwire.com/features/Compilers-....html?viewAll=y

fredbsd

Well...

After a few hours of mucking about with this...I have come to the conclusion I'd hold off on OpenCL until all these vendors can get their act together.  In a word: it's a mess and still, imho, not ready for prime time (if it is really intended to be an open platform).  I don't blame the companies who are adopting CUDA for their commercial undertakings.  OpenCL has a long, long way to go imho. 

I can compile and run all the Nvidia demos (both CUDA and OpenCL).  I even wrote my very own little 'hello world' app in OpenCL that works just fine.  Technically, OpenCL is working on my Linux system just hunky dory.

Hehe, getting that benchmark to work properly...well...yeah.  hehe...haha...woo...eeee....hahaha....I'll probably do it just because...but man...I'll probably kick a few cats in the process.

My understanding is that programming for "parallel computing" is EXTREMELY difficult.  Also, with OpenCL, it is even more so difficult than CUDA, but the performance is better.  Maybe by the 2nd revision, they will have made it a little easier to program with.

It's working.

Just another stupid idiotic miscommunication from Nvidia.  They have their 'beta' OpenCL driver, SDK, and toolkit out...but of course that's buried somewhere other than their official website which seems to have their own set of problems.  Seems to have fixed the loading issue I was having.

The beta 195 driver on Linux kinda...well...sucks to be honest.

More later.  I'm getting similar results to Talon but I am using a 260 192 card on a stock E8500.  Something is a bit odd...I think there's a flag we gotta switch somewhere when running this thing.  I'll be back later.

And Dave, all the examples (both CUDA and OpenCL) provided by Nvidia compiled and ran just fine.  I just needed to upgrade to the 195 driver (beta) for this app to work...although I have to no update all my OpenCL and Cuda stuff as well..../grrrrr

fredbsd

It's working. (Snip...)

I just love that your messing around with this... 

Looking forward to anything you might find of interest...  

Considering this is our latest combined data, with the XS link in the OP:
DosDuoNo ----------- GTX 260 --- Sample/sec --- 1,093.2K
Chumbucket843 ---- GTX 260 --- Sample/sec --- 1,123.2K
Talonman ---------- 1/2 a 295 --- Sample/sec --- 1,159.2K
NovoRei --------------- 4870 ------ Sample/sec --- 5,616.1K
PyrO ------------- 1/2 a 4870X2 -- Sample/sec --- 5,796.2K
mattkosem ----------- 4890 ------ Sample/sec --- 6,751.6K
fellix bg --------------- 5870 ------ Sample/sec -- 13,719.6K
luv2increase --------- 5870 ------ Sample/sec -- 14,883.7K

Making note that in both Pat's OpenCL test, and this test, Nvidia guys have high CPU utilization, and the fact that Nvidia doesn't support OpenCL on the CPU, it can only be unhealthy activity.

Most Probable Cause:
Unoptimized code for Nvidia GPU's, causing unwanted performance sucking memory paging, from GPU to PC. 

fredbsd  I'm getting similar results to Talon but I am using a 260 192 card on a stock E8500.  Something is a bit odd...I think there's a flag we gotta switch somewhere when running this thing.  I'll be back later.

Say what??  A magic switch would be fun...

Well, okay...here's where I'm at...I've put the project code into the Nvidia SDK and am now using the Nvidia makefile template to build the app.  Sometime this week I'll actually spend some time analyzing what is going on with this app and why it has such horrible performance w/ the Nvidia OpenCL implementation.  Something doesn't quite add up...but we'll figure it out in due time.

Here's where I'm at atm.  As you can see, I'm getting roughly the same performance as the other Nvidia cards here.  My rig isn't overclocked atm (testing stuff on BSD so I have to turn off all the fun) and this app is using a crapload of CPU cycles which of course makes zero sense all thing considered. 

Meh...we'll get to the bottom of it :P

I just spotted this post:
http://forums.nvidia.com/.dex.php?showtopic=154710

'vu64' date='Dec 30 2009, 03:59 AM' post='972523'
When I run the OpenCL Nbody demo, it fully utilize one core of my Core 2 Quad Machine. Why does a GPU application takes up CPU resources ?

'_Big_Mac_' date='Dec 30 2009, 10:24 AM' post='972661'
This is because Nbody uses alternating memory buffers that are being updated with blocking enabled. It constantly copies data to and from device to integrate and draw.

Blocking copy causes the issuing thread to wait and it's a spinlock wait, not a sleep wait.

I figured we might be seeing the same thing?
What the post doesn't say is if there is a better way to handle that.
(Or if it does, it's beyond my understanding!) 

Bah...no luck....back to the drawing board....:P

Any ATI guy feel like lending me a hand?  (Luv, get on it...:P)

I need someone who can compile and run this http://www-graphics.stanf...l/notes/clInfo.c  on their platform.  

NOTE: in that program you need to change two lines.

Line 387:

From: deviceList = malloc(numDevices * sizeof(cl_device_id));
To: deviceList = (cl_device_id *)malloc(numDevices * sizeof(cl_device_id));

Line 423:

From: platformList = malloc(sizeof(cl_platform_id) * numPlatforms);
To: platformList = (cl_platform_id *)malloc(sizeof(cl_platform_id) * numPlatforms);

GCC will spit it right back at you if you don't make the explicit conversion.  I'm not sure about MS.

I would like to see what information is given back from ATI platforms.


edit: that link is busted...so...hrmm....try this

Hrmmmm....no volunteers from the Red Camp? 

I'll bake cookies!

Talonman

I guess the key is can you get better performance on Nvidia systems, than what we are currently seeing...

Do we really need them?  :)

Hehe...well...it would be helpful.  I suppose I can have a buddy do it for me.   I just felt like keeping in house here ;>).

Talonman

luv2increase
My understanding is that programming for "parallel computing" is EXTREMELY difficult.  Also, with OpenCL, it is even more so difficult than CUDA, but the performance is better.  Maybe by the 2nd revision, they will have made it a little easier to program with.

CUDA's performance is better than OpenCL I believe.

CUDA is more developed, and a Nvidia GPU's native language.

Accessing CUDA directly will be faster since it's "close to metal".  The same goes if you the ATI equivalents to access the hardware.  The idea with OpenCL is that the API is the same for ATI, Nvidia, etc... and the layers below (CUDA, Brooke, etc...) handle the hand off to the hardware.  That way the application at the top of the stack doesn't need talk to the hardware using different APIs depending on the vendor used.  These different GPGPU APIs have held back general purpose programming on the GPU which OpenCL will hopefully resolve.

Talonman

Thanks...

It is a shame that OpenCL code will have to be optimized for each GPU vendor.
I think that is the reason for the performance difference that we are seeing in this OpenCL app.

One OpenCL code is not best for all GPU brands.
It appears it will always favor one or the other.

I guess it's the curse of GPU programming...
It will be easy to not use the GPU to it's max potential, if you have lots of GPU to PC memory transfers going on.  

Patience mate.  This is a very 'new' platform (OpenCL).  There's going to be hiccups along the way and certainly some issues that show up. 

After mucking about with it, I can see it's potential.  That particular application uses data structures and algorithms not well suited for GPU computing (yet the ATI compiler can handle it no problem which speaks volumes how far ATI has come with their compiler).  Nvidia, imho, will eventually 'fix' their implementation.  Yep, I think it's kinda borked atm.

What I'd like to see in OpenCL:

1. more language bindings (C++, Java, etc.)
2. a workable profiler (Nvidia's segfaults on OpenSuSE...I was too lazy to try figure out a workaround)
3. more involvement from large corporations (Sun, IBM, et al.).  Probably won't happen soon, but eventually they will all hop on board and start developing tools.  Many of the 'big guys' helped write the spec.  I'd like to see them start making tools as well.
4. This is up to Nvidia/ATI/et al and is more of a personal preference: ffs, make it more cross platform.  Would be nice to work on this in Solaris or BSD as I am far more comfortable on those platforms (and there's quite a few who feel the same exact way).  Right now it's limited to Mac, Windows, and Linux.  Pipe dream imho.  The only one I see even having a remote chance of doing it would be Nvidia as they already support FreeBSD and Solaris.  They don't, however, currently support either CUDA or OpenCL on other *nix platforms.  I felt 'dirty' working under Linux :P

In short, OpenCL is quite immature at this point.  In time, however, I think you'll see a lot of these teething pains go away.  When Java was released...there were quite a few 'issues' between platforms.

I'll get back to that thing sometime this weekend.  Still looking for someone from the red camp to run that program and return the results.  It's not important but it would be helpful.

 

Talon, you want to see something interesting?

Download this: http://davibu.interfree.i...ndelgpu/mandelGPU.html

Then zoom far in.  Watch what happens to the image.  You'll see it becomes quite pixelated very fast.  

These guys explain it here: http://www.luxrender.net/...mp;t=2947&start=20