Gallium3D OpenCL GSoC Near-Final Status Update

[89c51]

i was googling around to try to get a better idea on the discussion happening here and i found this quote by Zack Rusin:

In the case of AMD it's even sadder because the crucial code that we need for OpenCL right now is OpenCL C -> TGSI LLVM backend which AMD already does for their IL. Some poor schmuck will have to sit down and write more/less the same code."

does this mean that AMD has already writtern the code we need to make it run on GPUs ????

[bridgman]

does this mean that AMD has already writtern the code we need to make it run on GPUs ????

Sort of... we have an LLVM backend which generates AMD IL, then we run AMD IL through the proprietary shader compiler to generate hardware ISA, ie LLVM IR => AMD IL => ISA. We are looking at the LLVM bits from the proprietary stack to see what can be opened and re-used.

Zack's statement assumes we can open up the proprietary shader compiler, which is not an option today. We are looking at options for the open stack, and with some luck we can discuss at XDC.

[plonoma]

Hello,

Here are more details about the status of Clover:

• The API is complete, that means that any application can now use Clover and will not fail due to missing or unimplemented symbols.
• The implementation in itself is complete: there are no stubs, and all the API actually does something.
• The interesting part: Clover can launch native kernels (Phoronix spoke about that two months ago), and compiled kernels. So, it is really feature-complete.
• The only thing missing are built-ins functions. It means that even if we can create memory objects, images, events, command queues and all the OpenCL objects, and that we can compile and launch OpenCL C kernels, these kernel cannot yet use functions like clamp(), smooth(), etc.
• The most complex built-ins are implemented though, like image reading and writing, and barrier() (a built-in that will be described in detail in the documentation as it uses things like POSIX contexts (man setcontext)).

I'll write the documentation in the following days (I already begun). It will be in Doxygen format, and I was pleased yesterday to see that Doxygen is now able to produce exceptionally good and beautiful documentation, in regards of what it produced one or two years ago. Then, I'll rework some part of the image functions (they are currently tied to the x86 architecture using SSE2, I will reimplement them in a more architecture-neutral way).

The documentation will be available in the source code and also on my people.freedesktop.org page, so anybody will be able to view it.

Please add what version of OpenCL is implemented on the main page of your documentation. The references used from khronos to build this would be very informative.

[plonoma]

Sort of... we have an LLVM backend which generates AMD IL, then we run AMD IL through the proprietary shader compiler to generate hardware ISA, ie LLVM IR => AMD IL => ISA.

Zack's statement assumes we can open up the proprietary shader compiler, which is not an option today. We are looking at options for the open stack, and with some luck we can discuss at XDC. We are looking at the LLVM bits from the proprietary stack to see what can be opened and re-used.

But it's still possible to have different devices to work together with a mix of open and closed stack.
If I used the free OpenCL from GSoC on the CPU and used AMD's proprietary driver alongside, it should still work right?

[bridgman]

But it's still possible to have different devices to work together with a mix of open and closed stack.
If I used the free OpenCL from GSoC on the CPU and used AMD's proprietary driver alongside, it should still work right?

Not sure. The proprietary driver exposes an OpenCL ICD so would need to make sure they can co-exist. I don't know if clover supports the ICD model yet.

http://www.khronos.org/registry/cl/e...cl_khr_icd.txt

[b15hop]

Not sure. The proprietary driver exposes an OpenCL ICD so would need to make sure they can co-exist. I don't know if clover supports the ICD model yet.

http://www.khronos.org/registry/cl/e...cl_khr_icd.txt

Bridgman, did you see the video posted by JC recently about Rage, on pcper.com?

http://www.pcper.com/reviews/Editorial/John-Carmack-Interview-GPU-Race-Intel-Graphics-Ray-Tracing-Voxels-and-more

JC mentions that the consoles have a very efficient method to access texture data. Where as the PC suffer with poor utilisation of hardware capability. This sounds pretty crazy to me. Something doesn't quite make sense. It seems like it's frustrating him quite a lot in fact.

[bridgman]

Bridgman, did you see the video posted by JC recently about Rage, on pcper.com?

http://www.pcper.com/reviews/Editorial/John-Carmack-Interview-GPU-Race-Intel-Graphics-Ray-Tracing-Voxels-and-more

JC mentions that the consoles have a very efficient method to access texture data. Where as the PC suffer with poor utilisation of hardware capability. This sounds pretty crazy to me. Something doesn't quite make sense. It seems like it's frustrating him quite a lot in fact.

I haven't had a chance to watch the video yet (I read a lot faster than I can watch video ) but sounds like a combination of API limitations on texture updates and overhead to transfer new texture data to video memory -- so reading between the lines it sounds like he wants to "update small bits of a bunch of textures" on a regular basis and that means lots of little operations because the API patterns don't match what the app wants to do... and lots of little operations means slow in any language.

Will post back when I have time to slog through the video. People talk so slo...o...o...owly.

[b15hop]

I haven't had a chance to watch the video yet (I read a lot faster than I can watch video ) but sounds like a combination of API limitations on texture updates and overhead to transfer new texture data to video memory -- so reading between the lines it sounds like he wants to "update small bits of a bunch of textures" on a regular basis and that means lots of little operations because the API patterns don't match what the app wants to do... and lots of little operations means slow in any language.

Will post back when I have time to slog through the video. People talk so slo...o...o...owly.

There is a transcript on the 3rd / 4th Page, with all the written information that is recorded from the interview. So glad they did that, because I like to go over and revisit some parts.

Must admit though, JC is a fast talker compared to some people. Heh. x)

[steckdenis]

Hello,

I've uploaded a new version of the documentation online at http://people.freedesktop.org/~steck...ver/index.html . The front page now says that OpenCL 1.1 is implemented, many new classes are documented, and I directly uploaded the documentation from my computer instead of producing it on the Freedesktop.org server. It is now beautiful !

[89c51]

Denis have you tried any actual OpenCl apps ???


Also in case you are interested in a better branding/logo for the documentation site let me know