Intel Starts Landing Another OpenGL 4.3 Extension

[kalrish]

Then I guess I wonder what the difference between Gallium and DRI is. Are they competing? Or do they need each other?

I'm blindly walking on a swamp, but I recall hearing that Gallium turned all hardware-dependent API calls into an intermediate representation (IR) called TGSI; it allows every driver under its umbrella to support any API for which there exists a state tracker (a translator between API calls and TGSI). Thus, each driver either provides API interfaces by itself (as Intel's driver do) or plugs into Gallium and works with TGSI.

(Please, correct me if I am wrong.)

bridgman's answer, however, holds more truth than any I could give you.

[bridgman]

I'm blindly walking on a swamp, but I recall hearing that Gallium turned all hardware-dependent API calls into an intermediate representation (IR) called TGSI; it allows every driver under its umbrella to support any API for which there exists a state tracker (a translator between API calls and TGSI). Thus, each driver either provides API interfaces by itself (as Intel's driver do) or plugs into Gallium and works with TGSI.

Yep. One of the confusing things was that when Gallium3D was introduced there was obviously discussion and documentation about the new API and IR, but since the info was aimed at existing Mesa developers nobody bothered to document that there was an existing API and IR because "everyone knew that".

In that sense Gallium3D is just a newer and different interface for hardware drivers with some definite advantages, but the "which is best" question was hotly debated until everyone got tired of the debate (which suggests that one may not be obviously better than the other). Some teams decided to go with Gallium3D and others decided to stay with classic Mesa and make changes (eg using GLSL IR) to address specific concerns. My impression is that the decisions were a function of both perceived technical advantages/disadvantages and the degree of investment in classic Mesa at the time.

[bridgman]

but I recall hearing that Gallium turned all hardware-dependent API calls into an intermediate representation (IR) called TGSI; it allows every driver under its umbrella to support any API for which there exists a state tracker (a translator between API calls and TGSI). Thus, each driver either provides API interfaces by itself (as Intel's driver do) or plugs into Gallium and works with TGSI.

One minor clarification... API calls are not turned into IR... the IR is how shader programs are described to the HW driver, while API calls perform the actual setup & drawing functions.

The drawing functions typically make use of shader programs, eg: "draw this list of triangles, but run vertex shader program A on every vertex in the list and use the output of the shader as vertex position & corner colours, then run fragment shader program B on every pixel in each of the resulting triangles to determine what colour should be painted in for that pixel". So you need API calls *and* IR representation of shader programs.

[chrisf]

For those asking how much of this is useful to other drivers, in this case "all of it". I've only landed the driver-independent bits, since we ran into a snag with the i965 backend bits where the obvious approach doesn't do the right thing for out-of-range values.

Having the driver-independent bits in allows Ilia to land his nouveau support for the extension (which are on the list now) even before that's sorted out.

-- Chris

[chrisf]

As a clarification, this hasn't actually been actively worked on for months -- they're just old patches that were rattling around on the mailing list, had review tags, and would be useful