Radeon HD 7000 Series Will Bring New 3D Driver

[bridgman]

Also, is this code is the actual Catalyst OpenCL implementation with the obvious Tom's glue code for gallium3D. What performance numbers to be expected? Any closer to Catalyst?

It's one piece of the implementation (the LLVM back end which generates AMDIL). The Catalyst stack uses a different C99 front end ahead of LLVM and runs the AMDIL through our proprietary shader compiler so I expect there will still be differences.

[Drago]

It's one piece of the implementation (the LLVM back end which generates AMDIL). The Catalyst stack uses a different C99 front end ahead of LLVM and runs the AMDIL through our proprietary shader compiler so I expect there will still be differences.

Ah, there were no references for AMDIL in your pipeline diagrams.
So this code drop makes LLVM->AMDIL only. This AMDIL will be converted to ISA with existing shader compiler from r600g for the current generation, and with GCN shader compiler for next generation. It is not clear to me where this AMDIL fits in.

[bridgman]

The AMDIL generator is interesting for the LLVM developers and for people using the Catalyst OpenCL implementation, but we're not using AMDIL at all in the open source stack AFAIK. Tom built a direct hardware ISA back end on top of the AMDIL code provided by the OpenCL team. We didn't see any benefit in going through AMDIL in the open stack; the idea is to keep common interfaces across HW-specific drivers wherever possible.

The previous paths were for graphics on GCN and for compute on EG and up; we don't plan to change the path for graphics on current HW at all; that's where the existing r600g shader compiler comes in.

[Drago]

Thanks for the info. I will try to assimilate it during sleep Good night.

[duby229]

For GCN and up, this code + LLVM will more-or-less replace the shader compiler in r600g; at least that's our current thinking. The compiler will accept either TGSI or LLVM IR depending on whether the graphics or compute state tracker is running.

For graphics, the path will be :

[GLSL] >> (GLSL compiler) >> [glsl ir] >> (GLSL IR to TGSI converter) >> [tgsi] >> (new tgsi to llvm code) >> [llvm ir] >> (new llvm to ISA code) >> [gpu instructions]

..while for compute the path will be :

[OpenCL C99] >> (clover using clang/llvm) >> [llvm ir] >> (new llvm to ISA code) >> [gpu instructions].

Something like that anyways. There are a couple of points in the stack where LLVM runs some optimizing passes on the IR but I don't remember offhand where they are and need to get back to chopping firewood so am not looking at the code right now

square brackets for [data], parentheses for (processing)

OK, so the compute path seems to be pretty straight forward.... But the graphics path seems to be a bit of a kludge, why not just eliminate tgsi altogether and convert straight from glsl to llvm directly? Why the need for tgsi at all? Also, is there something wrong with tgsi that focus has been shifted over to llvm? I dont know much about it, but most conversations I've trolled left me with the impression that llvm ir sucked as a runtime interface...

Can you help clear up this strange tgsi conversion in the middle of the graphics path. And also help clear up the decision to focus on llvm ir over tgsi.

[smitty3268]

OK, so the compute path seems to be pretty straight forward.... But the graphics path seems to be a bit of a kludge, why not just eliminate tgsi altogether and convert straight from glsl to llvm directly? Why the need for tgsi at all? Also, is there something wrong with tgsi that focus has been shifted over to llvm? I dont know much about it, but most conversations I've trolled left me with the impression that llvm ir sucked as a runtime interface...

Can you help clear up this strange tgsi conversion in the middle of the graphics path. And also help clear up the decision to focus on llvm ir over tgsi.

TGSI probably will go away at some point, it's just the current standard that's already working so it makes sense to keep that around for a little while for testing to see if the new LLVM backend works the same as the TGSI backend.

Most devs aren't crazy about TGSI, but they don't really know what they'd replace it with. LLVM is one possibility. One of the shortcomings with TGSI is that it lacks many of the features necessary for computing - that could be added into TGSI, or they could choose a new IR altogether like LLVM.