Gallium3D OpenCL GSoC Near-Final Status Update

[bridgman]

The future when there will be SIMD GPUs, like AMD HD8xxx family.

One minor terminology point -- the AMD GPUs are all SIMD today (SIMD "this way" and VLIW "that way", eg a 16x5 or 16x4 array). In the future, they will still be SIMD, just not SIMD *and* VLIW.

There are certainly lots of IRs to choose from, each with their own benefits and drawbacks. One more wild card is that our Fusion System Architecture (FSA) initiative will be built in part around a virtual ISA (FSAIL) designed to bridge over CPUs and GPUs, so I think we have at least 5 to choose from -- 4 if you lump LunarGLASS and LLVM IR together since LunarGLASS builds on and extends LLVM IR. I'm assuming nobody is arguing that we should go back to Mesa IR yet

It's going to be an interesting few months, and an interesting XDC. I might even learn to like compilers, although that is doubtful.

[Drago]

Didn't LunarGLASS (http://www.lunarglass.org/), made already LLVM IR branch already compatible with GLSL ( new instincts and such). Currently they do GLSL IR -> LLVM IR -> TSGI -> Gallium Drv. They do that, because want to evaluate, whether they can make LLVM IR suitable. And they do it successfully till now. Later TSGI may go away, and there will be one IR for graphics and compute. Much like AMDIL. After that, there can be GLSL compiler based on clang, the way there is OpenCL one ( ask Steckdenis). One have to think about the future, though. The future when there will be SIMD GPUs, like AMD HD8xxx family.

[benjamin545]

i think the worst idea would be to have multiple ir's. its just asking for one ir to be well developed (the graphics one of course) and the other ir to be lagging behind. im not too sure which ir would be best, i like llvm as a compiler and i like the idea of one all powerful solution used all through your system. but the drivers have all been written for tgsi already, and as people have mentioned it may not be capable of describing graphics operations efficiently.

i think it may just be best to extend tgsi, it was designed with the intent of it being easy for the gpu vendors to easily port their drivers to interface with tgsi, but thats obviously a pipe dream. glsl could be nice since its designed to represent the glsl code well, but then im not sure if that represents the actual hardware capabilities well or if that represents other functionalities of the devices like compute or video decode.

there is a lot of stuff this ir will need to be used for, obviously graphics, compute, video decode (which is basically using compute for decode and graphics for display).
also, probably the best way to do remote desktop and accelerated virtual machine desktops is to use a gallium based driver model that passes the ir directly.

my personal favorite option is to make everything compile to a tgsi like ir that takes into consideration it may be passed through a network layer, basically just an easily streamable ir that is capable of describing everything graphics wise. then the driver backends convert that into the native gpu code and anything that cant be done on the gpu gets conveted to llvm to be done by the cpu.

i of course dont know if that last part is fully doable. but its kinda done already in a small sense with the i915g drivers. (since they dont have a vertex shader part there is break out in gallium that allows vertex shaders to be sent to a software driver.

[Plombo]

I still find the idea about two or more IRs puzzling, as an interested outsider.

Is the AMD IR found in Catalyst drivers used for both compute and shader tasks? If so, shouldn't we also strive towards a "universal" IR that you would only need to target once? Why doesn't TGSI work for computing anyway? It's not like OpenCL was unknown when it was designed.

Yes, I'm aware that it's anything but easy, I'm just interested.

TGSI doesn't work for computing because it was designed only for graphics, and more specifically, because it was based on Direct3D assembly. It thus has no concept of things like memory and pointers. And although it could be added to TGSI, since every driver has its own IR already, TGSI just gets out of the way.

Also, code-generating from TGSI is suboptimal for some hardware, especially SoA targets like nv50/nvc0. It's the same reason we're trying to propagate GLSL IR through the Gallium interface.

AMD can get away with a "universal" IR (AMD IL) because all the hardware they target closely matches that IR. We don't have that advantage for TGSI, because we have to target a wider range of hardware.

[pingufunkybeat]

I still find the idea about two or more IRs puzzling, as an interested outsider.

Is the AMD IR found in Catalyst drivers used for both compute and shader tasks? If so, shouldn't we also strive towards a "universal" IR that you would only need to target once? Why doesn't TGSI work for computing anyway? It's not like OpenCL was unknown when it was designed.

Yes, I'm aware that it's anything but easy, I'm just interested.

[bridgman]

Is the GLSL IR documented somewhere?

I've been looking at...

http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/README

http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/ir.h

http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/ast_to_hir.cpp

http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/TODO

... in the same way that the proverbial hog looks at the digital watch. The code seems to be nicely commented, and if it were anything but a compiler I would probably find it easy to understand. Unfortunately compilers and I do not get along.

[Silverthorn]

Is the GLSL IR documented somewhere?

[bridgman]

all Gallium drivers: GLSL IR -> TGSI -> gallium mesa state tracker -> driver code

Does "gallium mesa state tracker" belong there ? Smells like a copy/paste glitch...

But yeah, GLSL IR is very recent compared to the others, enough so that I expect most people are still trying to find enough time to look at it and form an opinion about its suitability for graphics and compute. It often seems easier to stick with the devil you know

[smitty3268]

I've been wondering about this for a while now so I just have to ask. Why are we using either LLVM or TGSI instead of GLSL IR to begin with? Were the first two already in existence or an adaptation of existing code or is there some benefit of using them over using GLSL natively? Or am I misunderstanding something entirely?

Originally every driver in Mesa used the Mesa IR.

When the devs decided to create a new driver framework (named Gallium) they decided that Mesa IR had to go, and built Gallium around a new TGSI that I believe they based at least somewhat on what Direct3D does internally. Or at least some of the Windows drivers. For reasons of backwards compatibility and not to have to rewrite all of Mesa, most of Mesa remained using the old Mesa IR and it was simply converted into TGSI when passed into Gallium.

Later, the Intel devs (who were not using Gallium) created a new GLSL compiler which was a lot better than the old one. Since they were creating it from scratch, they decided that they should simply use it's internal GLSL IR dircetly within their drivers rather than converting it into Mesa IR first. They also didn't like TGSI, because they felt the unstructured nature of the bytecode would keep them from doing some of the optimizations that would be possible in their structured GLSL IR. To keep backwards compatibility they went ahead and wrote a translation for GLSL IR -> the old Mesa IR, and and from there all the drivers worked exactly the same as before. Since then, they've updated the i965 drivers to directly use GLSL IR while the old pre-i965 drivers are still using Mesa IR. And plombo wrote a GLSL IR -> TGSI translator to avoid the old Mesa IR in the middle, mostly because the old Mesa IR lacked features that both GLSL IR and TGSI have (for GL 3.0) and because it simplifies the whole chain.

So, the current status is:
Intel pre-965: GLSL IR -> Mesa IR -> driver code
Intel 965+: GLSL IR -> driver code
all other classic drivers: GLSL IR -> Mesa IR -> driver code
all Gallium drivers: GLSL IR -> TGSI -> gallium mesa state tracker -> driver code (technically r300g then converts back to Mesa IR inside it's compiler to reuse old code there)


Originally, TGSI was designed to be a modernized version of Mesa IR that would be compatible across hardware and OSs. However, while perfectly adequate, it's never really been considered that great by the developers. So after Intel came out with GLSL IR and basically said it was superior in every way (not sure if that's really true or not) there was a lot of talk about dropping TGSI for it since that way they could directly use what the Intel devs are most focused on rather than translating it in the middle to another language. There was also talk about just using LLVM IR, since that would open up a lot of optimizations using the LLVM framework and possibly make more complicated stuff more manageable. I think that is a particular concern with compute where longer and more complicated programs become more and more common.

The problem is that the Gallium drivers are built around TGSI, so any change is going to require a fair amount of work, and up to this point no one has really seemed that interested in doing it. Instead, the focus has been on adding new features to drivers, and just getting the hardware to work.

[Prescience500]

So, let me see if I got this right...

Clover implements the complete OpenCL API and can execute OpenCL programs. But at the moment, all of it runs on the CPU, and getting it to actually run on GPUs will be a hitload of work and nobody really knows how it should be done.

And this is due to a few factors:

- the situation regarding IRs in Gallium is muddy: Mesa IR seems to be on the way out, with TGSI being generated directly, but there are attempts to use LLVM too, and GLSL IR is also in the mix
- TGSI is good for graphics (shaders), but is not good for computing, like OpenCL, which is why people are proposing LLVM
- LLVM sucks at graphics

So we're likely looking at (at least) two IRs coexisting: one for shaders, one for OpenCL stuff?

I've been wondering about this for a while now so I just have to ask. Why are we using either LLVM or TGSI instead of GLSL IR to begin with? Were the first two already in existence or an adaptation of existing code or is there some benefit of using them over using GLSL natively? Or am I misunderstanding something entirely?