ATI released OpenCL SDK with hardware support

[Eros]

For me - the answer is PINK... with simple.scn
Pink for caustic.scn
green for cornell.scn
Blue for Cornell_large.scn

Not sure exactly what all that would mean... but - ya

[Dade]

For me - the answer is PINK... with simple.scn
Pink for caustic.scn
green for cornell.scn
Blue for Cornell_large.scn

Not sure exactly what all that would mean... but - ya

The test is meaningful only with cornell.scn. It means the data are uploaded correctly ... quite worrying, both input and output work fine so it is something in the middle: in the path tracing code .. and this start to sound as a compiler bug because everything works fine under linux/windows and apple CPU. Anyway, I will write a simplified kernel tomorrow to do some more test and isolate where is the problem in the code.

[jensverwiebe]

If you ran it you should the following screen colours:

green: all ok;
blue: camera wrong, scene ok
red: camera ok, scene wrong
pink: both wrong

if you move the camera (i.e. pressing a cursor key) or a sphere (i.e. pressing key '4') the related buffer should become "wrong";

Dade, my results:

jens-macpro:SmallptGPU-v1.6alpha jensverwiebe$ ./smallptGPU 1 32 preprocessed_rendering_kernel.cl 640 480 scenes/cornell.scn

Starting -----> green
arrow ---->blue
"4" ----> red

hmm, all as expected, keep in mind OSX is a good testmule, not forgiving anything

EDIT: just found list for upcoming OSX 10.63, there are some related things adressed:

OpenCL
- Resolves some OpenCL compiler issues.
- Resolves some OpenCL conversion issues.
- Fixes some OpenCL crashes.
- Resolves some  OpenCL Framework issues.

llvm
- Resolves segmentation faults.
- Resolves some compiler crashes.
- Improvements for OpenCL and OpenGL.

Could help us on OSX, release is expected at the nd of january perhaps....

Jens

[jensverwiebe]

Dade...found some more info on potentially wrong output with NV.

Has todo with usage of __global vs. __constant and mem_objects.

http://forums.nvidia.com/index.php?show ... ntry952629

http://stackoverflow.com/questions/1752 ... -incorrect

http://stackoverflow.com/questions/1576 ... cl-kernels



Hope it is helpful, i haven´t got through it though, will try today...

Jens

[Knio]

Hi all,

I couldn't get SmallptGPU to run (would crash after initializing OpenCL) or build (MingW doesn't work?), so I created a Visual Studio 2008 project and built it with that. Had to change a bit of code and linker stuff to get it to work, but here it is: http://github.com/Knio/SmallptGPU

I will try to do the same for SmallLuxGPU tomorrow, and fix some bugs (It won't build in release mode for some reason right now)

[Dade]

Dade...found some more info on potentially wrong output with NV.

Has todo with usage of __global vs. __constant and mem_objects.

http://forums.nvidia.com/index.php?show ... ntry952629

http://stackoverflow.com/questions/1752 ... -incorrect

http://stackoverflow.com/questions/1576 ... cl-kernels

Hope it is helpful, i haven´t got through it though, will try today...

This Apple's bug about __constant buffers fits quite well our case. Check http://www.khronos.org/message_boards/v ... =37&t=2148 for a confirmation. Going to post a kernel not using __constant memory in a minute.

@Kido: I'm compiling SmallptGPU under Windows with VisualC++ Express (the free edition), if you need I can post here the project Yup, SmallLuxGPU is probably in need of few fix already applied to SmallptGPU.

[Dade]

Going to post a kernel not using __constant memory in a minute.

It is attached to this message

[jensverwiebe]

Aaaaaah...finally. Many thx Dade, bugreport to Apple filed, i hope next update fixes this thing complete.

It works now:

Fiddled a bit to find god workgroupsize, here 32 or 64 was best:

jens-macpro:SmallptGPU-v1.6alpha_wo_const jensverwiebe$ ./smallptGPU 1 64 preprocessed_rendering_kernel.cl 640 480 scenes/cornell.scn

Here 192 was best:

jens-macpro:SmallptGPU-v1.6alpha_wo_const jensverwiebe$ ./smallptGPU 1 0 preprocessed_rendering_kernel.cl 640 480 scenes/simple.scn

CPU was 0.9% in both cases, so thats fine on OSX.


Again the specs:

Code: Select all

Reading scene: scenes/cornell.scn
Scene size: 9
OpenCL Platform 0: Apple
OpenCL Device 0: Type = TYPE_GPU
OpenCL Device 0: Name = GeForce 8800 GT
OpenCL Device 0: Compute units = 14
OpenCL Device 0: Max. work group size = 512
OpenCL Device 1: Type = TYPE_CPU
OpenCL Device 1: Name = Intel(R) Xeon(R) CPU            5150  @ 2.66GHz
OpenCL Device 1: Compute units = 4
OpenCL Device 1: Max. work group size = 1
[SELECTED] OpenCL Device 0: Type = TYPE_GPU
[SELECTED] OpenCL Device 0: Name = GeForce 8800 GT
[SELECTED] OpenCL Device 0: Compute units = 14
[SELECTED] OpenCL Device 0: Max. work group size = 512
Reading file 'preprocessed_rendering_kernel.cl' (size 16931 bytes)
OpenCL Device 0: kernel work group size = 192
OpenCL Device 0: forced kernel work group size = 64


So now we know about this

Source prepared for OSX + binaries(64bit) for interested people: http://www.jensverwiebe.de/LuxRender/Sm ... ha_OSX.zip

Jens

[Dade]

Aaaaaah...finally. Many thx Dade, bugreport to Apple filed, i hope next update fixes this thing complete.

AHAH, finally, yes ! Performances looks on track with what I have seen elsewhere with NVIDIA.

So now we know about this

I deeply hate Apple at the moment If there is a thing that drives a developer crazy is a compiler bug.

Just just joking. The next thing I have for you, Jens, is the multiple OpenCL device support:

This is SmallptGPU2 running at the same time on my OpenCL GPU device ATI HD4870 and OpenCL CPU device Q6600. You can read the workload distribution on the "Help"screen (i.e. 90.5% done by the GPU, 9.5% done by the CPU). It is optionally visible also on the screen as a green bar on the left (the zone rendered by the GPU) and red bar (the one done by the CPU). This is gone be very interesting with multi-GPU setups.

Can I say that CPUs are starting to look a bit pathetic ? My poor Q6600 is totally owned by the 4870 The GPU is 9.83 times faster than the CPU

Gone do some more clean-up and to apply Apple's bug work around and than I will post the sources.

[SATtva]

Can I say that CPUs are starting to look a bit pathetic ? My poor Q6600 is totally owned by the 4870 :D The GPU is 9.83 times faster than the CPU :?

I know now how my next budget on the renderfarm upgrade will be spent. ^_______________^

I've already said that, but want to reiterate one more time: thank you guys for your great work!