Radeon HD 7000 Series Will Bring New 3D Driver

[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.

[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.

[Drago]

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

[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]

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]

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]

I always wanted to live like this. One day maybe...
What about the performance numbers?

[bridgman]

Chipping firewood, really You are not living in a cabin in the woods, aren't you

Actually I *do* live in the woods (a red pine forest), the house design is basically a big cabin (albeit with a basement and a carport), and the floor plan was designed around a masonry heater that can keep the place cozy on all but the coldest days, so for all practical purposes "yes I live in a cabin in the woods".

My friends call it "the cabin" so I guess that makes it official. No TV, but I get deer in the front yard and wild turkeys in the back.

This sounds like a plan. Do you know the work LunarGLASS has made to make LLVM graphics friendly. http://www.lunarg.com/3d-driver-deve...gy/lunarglass/
What do you think?

It seemed pretty good to me -- essentially using two different levels of IR with standard code to optimize and convert between them, in order to help get around the "one size really doesn't fit all" problems we hit when trying to standardize on a single IR for all workloads and all hardware.

[Drago]

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?

[Drago]

Chipping firewood, really You are not living in a cabin in the woods, aren't you
This sounds like a plan. Do you know the work LunarGLASS has made to make LLVM graphics friendly. http://www.lunarg.com/3d-driver-deve...gy/lunarglass/
What do you think?