Gallium3D Compute Infrastructure Is On Approach

[phoronix]

Phoronix: Gallium3D Compute Infrastructure Is On Approach

The Gallium3D compute infrastructure, which is the underlying work for supporting OpenCL over this open-source graphics driver architecture, is on approach for landing in the very near future. This has been one damn good day for open-source Linux graphics drivers following the earlier Nouveau surprise announcements...

http://www.phoronix.com/vr.php?view=MTA3NTg

[elanthis]

Haven't looked into this myself yet, but if I'm reading this right, the OpenCL frontend is Clang which generated LLVM IR, which is translated into TGSI, which for AMD cards is then translated back into LLVM IR to be compiled into the hardware's machine code. If that's correct, can I ask what the point of even having/using TGSI is in this code path? Also, given the existence of an LLVM backend that targets NVIDIA GPUs (pretty sure that exists, but I don't recall if it requires NVIDIA's proprietary PTX compiler for machine code generation), and the llvmpipe driver that uses LLVM IR, is it possible that TGSI will be removed entirely in favor of just using LLVM IR as the sole IR in the Mesa/Gallium stack?

[liam]

Phoronix: Gallium3D Compute Infrastructure Is On ApproachThe Gallium3D compute infrastructure, which is the underlying work for supporting OpenCL over this open-source graphics driver architecture, is on approach for landing in the very near future. This has been one damn good day for open-source Linux graphics drivers following the earlier Nouveau surprise announcements...http://www.phoronix.com/vr.php?view=MTA3NTg

Can someone explain what mesa has to do with this work? Mesa, I think, is an open source implementation of OpenGL. That would seem to have exactly nothing to do OpenCL. I would expect a parallel project that does for OpenCL what mesa did for OpenGL.

[allquixotic]

The one use I have for OpenCL compute -- currently -- is reducing the time it takes to encode high-quality, high-resolution videos. I'm glad people are working on this, regardless of their motives. But I think we also urgently need some useful free software projects which take advantage of OpenCL. Otherwise, it's a tragically untapped resource!

I'm hoping for something similar to Sony Vegas Pro but open source and for Linux. Vegas Pro has a bunch of pretty fast OpenCL-powered encoders that can cut your encoding time between 3x and 10x depending on your memory bandwidth (at least in my case, the bottleneck seems to be system memory bandwidth, because the CPU isn't all that overloaded, and the GPU is sitting there bored for 80% of the time).

I just think of how closely GIMP matches Photoshop (it's not exactly there, but it's VERY close), or how well OpenOffice handles the same feature-set as MS Word (even if it doesn't always perfectly deal with MSFT's proprietary formats, it handles the same features very well in OpenDocument formats) and I wish that we could apply the same type of efforts into building useful things on top of OpenCL.

If I'm not too busy this summer -- it's a possibility that I might start something like this, or join an existing development team and contribute in my spare time.

[gigaplex]

Can someone explain what mesa has to do with this work? Mesa, I think, is an open source implementation of OpenGL. That would seem to have exactly nothing to do OpenCL. I would expect a parallel project that does for OpenCL what mesa did for OpenGL.

Gallium3D is part of Mesa and does more than just OpenGL.

[allquixotic]

Can someone explain what mesa has to do with this work? Mesa, I think, is an open source implementation of OpenGL. That would seem to have exactly nothing to do OpenCL. I would expect a parallel project that does for OpenCL what mesa did for OpenGL.

Mesa started out as an OpenGL software renderer. Since then, it has grown into more of an umbrella project, supporting a lot of very different efforts under common infrastructure.

These days, the most popular use of Mesa is to start with a "low level" hardware interface to some graphics chipset; pull that low-level interface up into a common representation called the Gallium3d API (accompanied by TGSI intermediary representation); and then do "stuff" with that medium-level hardware interface.

The raw Gallium3d interface isn't generally useful to application programmers, because it's too low level and requires a lot of hardware knowledge. That's why we then write something called a "state tracker", which hooks into that mid-level tier and provides some kind of application developer interface in the form of a public library, such as OpenGL, OpenCL, OpenGL ES, OpenVG, and so on.

Actually, there are quite a lot of state trackers in existence right now. OpenGL is by far the most popular, the most heavily maintained and the least buggy (at least for more "mature" hardware); but the other state trackers are coming around gradually. I would wager that OpenCL is probably going to be the second or third most popular state tracker, with another popular one being the one that does hardware-accelerated video decoding (I think it's called the "vaapi state tracker"?)

The neat thing about the mid-level interface is that you don't normally have to write your state tracker code for each piece of hardware. You might have to special-case certain things in certain state trackers, but overall, the idea is that the TGSI and Gallium3d API layer reduces the amount of work that the developers have to do, in order to provide the state tracker on top of an "assumed complete" low-level hardware interface.

In an ideal world, you could bring up brand new GPU hardware support into Gallium3d by just writing the low-level, hardware-specific bits; and once that work was completed, all of the state trackers sitting on top of Gallium3d would light up, like power being supplied to a light bulb - ping!, you've got OpenGL; ping!, you've got OpenCL; ping!, you've got OpenVG; and so on. It doesn't exactly happen that way due to practicalities such as the low-level drivers being generally incomplete unless a specific feature is seen as needed (and then the feature is added in order to support a specific use case in a specific tracker); but as these kinds of efforts continue to expand, you will hopefully see the hardware-dependent entrails showing up less and less frequently in the layers sitting "above" the Gallium3d mid-level API. So it's kind of a work in progress, but it's a very powerful idea for saving development time.

So whenever you hear about someone trying to use some library with the aid of GPU acceleration, chances are that it's going to wind up as a Mesa state tracker. We even have a Direct3D 11 state tracker, hehe.

[mattst88]

Haven't looked into this myself yet, but if I'm reading this right, the OpenCL frontend is Clang which generated LLVM IR, which is translated into TGSI, which for AMD cards is then translated back into LLVM IR to be compiled into the hardware's machine code. If that's correct, can I ask what the point of even having/using TGSI is in this code path?

Just a quick look would have told you the answer.

[PATCH 11/11] gallium/compute: Drop TGSI dependency.

This is mainly to accomodate AMD's LLVM compiler back-end by letting
it bypass the TGSI representation. Other drivers will keep using the
common TGSI instruction set for compute shaders.

[liam]

Mesa started out as an OpenGL software renderer. Since then, it has grown into more of an umbrella project, supporting a lot of very different efforts under common infrastructure.

These days, the most popular use of Mesa is to start with a "low level" hardware interface to some graphics chipset; pull that low-level interface up into a common representation called the Gallium3d API (accompanied by TGSI intermediary representation); and then do "stuff" with that medium-level hardware interface.

The raw Gallium3d interface isn't generally useful to application programmers, because it's too low level and requires a lot of hardware knowledge. That's why we then write something called a "state tracker", which hooks into that mid-level tier and provides some kind of application developer interface in the form of a public library, such as OpenGL, OpenCL, OpenGL ES, OpenVG, and so on.

Actually, there are quite a lot of state trackers in existence right now. OpenGL is by far the most popular, the most heavily maintained and the least buggy (at least for more "mature" hardware); but the other state trackers are coming around gradually. I would wager that OpenCL is probably going to be the second or third most popular state tracker, with another popular one being the one that does hardware-accelerated video decoding (I think it's called the "vaapi state tracker"?)

The neat thing about the mid-level interface is that you don't normally have to write your state tracker code for each piece of hardware. You might have to special-case certain things in certain state trackers, but overall, the idea is that the TGSI and Gallium3d API layer reduces the amount of work that the developers have to do, in order to provide the state tracker on top of an "assumed complete" low-level hardware interface.

In an ideal world, you could bring up brand new GPU hardware support into Gallium3d by just writing the low-level, hardware-specific bits; and once that work was completed, all of the state trackers sitting on top of Gallium3d would light up, like power being supplied to a light bulb - ping!, you've got OpenGL; ping!, you've got OpenCL; ping!, you've got OpenVG; and so on. It doesn't exactly happen that way due to practicalities such as the low-level drivers being generally incomplete unless a specific feature is seen as needed (and then the feature is added in order to support a specific use case in a specific tracker); but as these kinds of efforts continue to expand, you will hopefully see the hardware-dependent entrails showing up less and less frequently in the layers sitting "above" the Gallium3d mid-level API. So it's kind of a work in progress, but it's a very powerful idea for saving development time.

So whenever you hear about someone trying to use some library with the aid of GPU acceleration, chances are that it's going to wind up as a Mesa state tracker. We even have a Direct3D 11 state tracker, hehe.

Great explanation.
Thanks allquixotic!

Best/Liam

[Nille]

with another popular one being the one that does hardware-accelerated video decoding (I think it's called the "vaapi state tracker"?)

VDPAU State Tracker.

[smitty3268]

VDPAU State Tracker.

It's usually referenced as the "VA" state tracker, since it implements more than just VDPAU (such as XvMC).