New OpenCL Ray Tracing App...

http://davibu.interfree.i...lptgpu/smallptGPU.html

(Download link at the very bottom of the page.)

FYI: It uses a .tgz file, I used this free app to un-crunch it: http://download.cnet.com/...67135.html?tag=lst-0-1

SmallptGPU is a small and simple demo written in OpenCL in order to test the performance of this new standard. It is based on Kevin Beason's Smallpt available at http://www.kevinbeason.com/smallpt/. SmallptGPU has been written using the ATI OpenCL SDK 2.0 on Linux but it should work on any platform/implementation (i.e. NVIDIA). Some discussion about this little toy can be found at Luxrender's forum

Note that this app just runs forever!

It uses 1 GPU, and at least 4 CPU cores:



Once again... The ATI boys do well in this OpenCL app.
http://www.xtremesystems....howthread.php?t=241904

Thanks for the post...

I had 7-zip installed I thought? Oh well. I got er done!

Odd again on the Nvidia boys and CPU utilization, and your lack thereof...
That would be a fun answer to find out. It could be a key as to a performance bottleneck, or could be helping us?
Tough call...

One might initially think that the CPU must surly be helping...
However, if whatever the CPU is doing, would be better processed on the GPU, it might be actually hurting us?

Almost 15K Samples a second is stunning.

Yep, 7-zip works just fine on the archive. You've got to unpack it twice though.

It probably means points of light rendered. Simular to pixel count I think.

They look outstanding, but are CPU only apps...

I have yet to tackle .rar files.

Thanks for the link though.
I am considering downloading the Pinball game real bad, and just might mess with the rar.

luv2increase

Talonman

They look outstanding, but are CPU only apps...

I have yet to tackle .rar files.

Thanks for the link though.
I am considering downloading the Pinball game real bad, and just might mess with the rar.

.rar is just like .zip

7-zip handles both files the same.  Install 7-zip and just "right-click" on the files and extract it to its own folder.  Literally "2" clicks of the mouse, and you have your nice little normal folder...

7-zip is a great utility. Also check out Winrar. Its my go to archiving program.

Thanks so much talonman! You have made some great contributions to this forum. I really love all these different programs/benchmarks that stress my GPU. I would love nothing more than perfect balance between all of the components of my system.

Raytracing is really so beautiful. Hopefully GF100 or I guess I hope that maybe GF200/HD6000 is powerful enough to show us what raytracing is really about.

no samples per pixel is not a 1.1KB/s. basically with this ray tracing method you are rendering the color for 1.1 milllion pixels per second. love 2 is rendering 15 million pixels per second. i forget how much data one rgba value has.

chumbucket843

Talonman

That's why the second time was a charm...

On the Sample rate, it does actually have 14883.7K...

What is that actually? 14,883,700 samples a second?

And I'm getting 1,157,100? Wowzer! (12.86 X slower)

luv2increase
Something interesting to note is that a single 5870 is getting 13x better performance that 1/2 of your GTX295 here.  The 5870 is able to render a sample size of 14.883 MB every single second whereas you are able to render a sample size of 1.157 MB per second.

Agree...

Rather sick about it... but agree.

Just for the record, we did get a second ATI guy report 0% CPU utilization, in the link at the bottom of the OP.

here is a secret about gpgpu. you cant write a program and expect it to run fast on all cards. this was written on ATi openCL SDK and with an ATi card. when you write a gpgpu app its easy to make it run but to make it run fat is the hard part. in other words it runs well on ATi but crap on nvidia. its still really cool though!

its even more believable after luvs post about open cl and si sandra

i want something thats vendor neutral so we can see who has the muscle in open cl

Via Sin Dios

its even more believable after luvs post about open cl and si sandra

i want something thats vendor neutral so we can see who has the muscle in open cl

Read my post in the other thread.

Basically OpenCL is a standard, and all these programs are based upon OpenCL 1.0.  The main dealbreaker in determining how well the architecture can handle parallel computing and the drivers brought out by the manufacturer.  Granted, the way the program is designed can be tailored to a specific architecture and device (CPU vs GPU), but that is not the most important aspect in determing the performance.

This is evident in the DirectCompute benchmark.  The developer Pat made it blatantly clear that it is indeed a "VENDOR NEUTRAL" benchmarking application.

luv2increase

Via Sin Dios

chumbucket843
its even more believable after luvs post about open cl and si sandra

i want something thats vendor neutral so we can see who has the muscle in open cl

Read my post in the other thread.

Basically OpenCL is a standard, and all these programs are based upon OpenCL 1.0.  The main dealbreaker in determining how well the architecture can handle parallel computing and the drivers brought out by the manufacturer.  Granted, the way the program is designed can be tailored to a specific architecture and device (CPU vs GPU), but that is not the most important aspect in determing the performance.

This is evident in the DirectCompute benchmark.  The developer Pat made it blatantly clear that it is indeed a "VENDOR NEUTRAL" benchmarking application.

have you ever written a gpgpu program? just because the API does not support IHV exclusive optimizations like warps/wavefronts does not mean that a program will not favor one architecture over the other. most games have optimized codepaths too. just look at stalker. it uses non dx11 tessellation (before CoP) and nvidia cards are still faster than their ATi counterpart.

****? i never wrote that.

http://www.hpcwire.com/fe...8625442.html?viewAll=y

An insight from a compiler writers perspective on OpenCL.  

For Luv and Chum: 

"So, are OpenCL programs going to be performance portable or not? Sadly, not. An OpenCL kernel is a low-level representation of the work to be done on the accelerator or GPU itself. To optimize the performance, you must know and take advantage of device-specific information such as the optimal number of work-items in a work-group, the amount of local memory and perhaps the number of banks, and trade-offs between parallelism and efficiency. An optimized kernel for one device may or may not perform well on another, but is unlikely to be optimal for that second device. This is not a condemnation of OpenCL, or even a failure of the language. It was intended and designed to be a low-level, high-performance, close-to-the-metal, efficient programming interface, borrowing phrases. The intent is apparently that OpenCL will support an ecosystem of tools, middleware and applications, not to be the portable parallel abstraction. Even though the kernels are not performance portable, even if you have to tune your kernels for each device, the ability to write your kernels for different devices in the same language is a great leap forward from where we are today."

It isn't just about one vendor vs, another (like we see in games etc.).  This is far more localized to the environment and target platform the app is being coded for (and, of course, on).  Yes, OpenCL is an open standard and yes the apps should be portable.  But to really achieve efficiency and performance (speaking of optimal performance of course) the host will play a rather large part.  So, say a programmer at X institution is coding for an ATI cluster...of course he/she will code to that particular platform.  Same goes for someone coding an app using the Nvidia SDK on an Nvidia cluster.  Personally, I don't believe this will be because they are intentionally trying to undercut or somehow exclude another vendor (as is often alluded to when discussing games).  It's just a local reality programmers will have to deal with due to the nature of the paradigm itself. 

This won't be limited to OpenCL btw.  Direct Compute and obviously CUDA will have the same limitations imposed on the devs as well.  Unless, of course, we start to see standardization of GPU technology (which as we all know ain't gonna happen anytime soon).  Parallel programming is not easy.  In fact, it's bloody effing difficult.  OpenCL, CUDA, Direct Compute, Stream...whatever....certainly are terrific tools an offer up a whole new level of powerful tools in a much more accessible manner but they aren't going to be 100% performance portable no matter how hard a developer tries to achieve this lofty goal.  As the writer mentions, the ability to port the apps between hosts is indeed terrific regardless.

It's a good read and certainly worth your time to have a look through if you are interested in this topic.  

For giggles, I'm going to compile that app with the Nvidia SDK under Linux sometime soon (when I have a chance) just to see what (if any) differences might show up.  Could take me a while...knee deep in all sorts of stuff atm.  When I'm done, I'll post results.

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.