Work Continues On FP64 Support For OpenGL 4.0 On Intel's Driver

[phoronix]

Phoronix: Work Continues On FP64 Support For OpenGL 4.0 On Intel's Driver

While the RadeonSI and Nouveau NVC0 Gallium3D drivers are now at OpenGL 4.1 compliance, the open-source Intel Mesa driver remains stuck at OpenGL 3.3. Blocking the Intel driver from OpenGL 4.0 compliance is FP64 and tessellation shader sub-routine. While work is underway on both extensions -- plus ARB_vertex_attrib_64bit for OpenGL 4.1 -- it looks like the FP64 support may not be too far out...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-OpenGL-FP64-Coming

[zanny]

If Intel doesn't have working 4.1 by Mesa 11's release, its just a reminder why doing your own thing outside the Gallium stack is duplicating a lot of work that doesn't need repeated. Years ago they said it would be too much work to use the community maintained Intel Gallium driver as a base and port all their optimizatoins to it, and years later... they are still paying technical debt having an independent stack in Mesa from Freedreno / Lima / AMD / Novueau / Broadcom / etc. And it only gets worse.

It wouldn't be a problem if Intel just threw so many people at it that their Linux driver was top notch like Nvidias blob... but they do not. So all this redundant effort on very limited resources really sucks.

[mattst88]

If Intel doesn't have working 4.1 by Mesa 11's release, its just a reminder why doing your own thing outside the Gallium stack is duplicating a lot of work that doesn't need repeated. Years ago they said it would be too much work to use the community maintained Intel Gallium driver as a base and port all their optimizatoins to it, and years later... they are still paying technical debt having an independent stack in Mesa from Freedreno / Lima / AMD / Novueau / Broadcom / etc. And it only gets worse.

No, not true at all. The things that we still have to do (I work for Intel on i965) from tessellation and fp64 on i965 are the hardware-specific parts that we'd have to do regardless of whether we used Gallium or not.

And for what it's worth, Chris Forbes (contracting for Intel) did a bunch of the initial work for tessellation shaders (and shader subroutine) that the Gallium drivers use -- and then Ken reviewed the core parts of tessellation and shader subroutine. Ian and I reviewed a lot of the core-fp64 work as well.

So the suggestion that Intel is off doing its own thing (and is now being hampered by it) is just flat wrong.

[smitty3268]

No, not true at all. The things that we still have to do (I work for Intel on i965) from tessellation and fp64 on i965 are the hardware-specific parts that we'd have to do regardless of whether we used Gallium or not.

And for what it's worth, Chris Forbes (contracting for Intel) did a bunch of the initial work for tessellation shaders (and shader subroutine) that the Gallium drivers use -- and then Ken reviewed the core parts of tessellation and shader subroutine. Ian and I reviewed a lot of the core-fp64 work as well.

So the suggestion that Intel is off doing its own thing (and is now being hampered by it) is just flat wrong.

Well, it has meant that Intel doesn't support DX9 or VDPAU while gallium drivers get it (almost) for free. Then again, that may be considered a positive benefit by Intel rather than a downside. The gallium HUD is another major feature a lot of people would love to see running on Intel hardware.

And it's also led to a fair amount of duplication of work - hard to believe that all drivers wouldn't be a bit further along if there wasn't such a division between them.

But ultimately it is Intel's driver and they have the right to develop it however they see as best for them. The biggest benefactors of Intel moving to Gallium would be the other gallium drivers, not Intel. So I can understand why the decision was made.

[Gusar]

If Intel doesn't have working 4.1 by Mesa 11's release, its just a reminder why doing your own thing outside the Gallium stack is duplicating a lot of work that doesn't need repeated.

If merely being a gallium driver would magically give you extension support, the ilo driver would have those extensions. But it doesn't. So no, it isn't at all how you claim.

If there's any duplication, it's in infrastructure/boilerplate code, which is certainly not "a lot". Core parts of an extension are shared between gallium and classic. And hardware-specific parts are, well, hardware-specific. You have to code them for each GPU vendor and GPU generation regardless of whether the driver is gallium or classic.
For example, Sandy Bridge does geometry shaders differently from later generations, so Ivy+ got geometry shaders first, then separate code was needed to enable them on Sandy.

The biggest benefactor's of Intel moving to Gallium would be the other gallium drivers, not Intel.

As mattst88 explained, Intel contributed to tessellation and fp64, either by direct code contribution to core (non-hw-specific) parts or by doing reviews. So gallium drivers are *already* benefiting from Intel, Intel's driver doesn't need to be gallium for that.

You do have a point with the HUD possibly, but I'm not sure about the other stuff. For example gallium having VAAPI doesn't mean all gallium drivers have it, nouveau doesn't - https://bugs.freedesktop.org/show_bug.cgi?id=89969. Likewise, similar to what I wrote above about ilo not having these GL extensions, it doesn't have VDPAU either. Like with GL extensions, hw-specific code is needed here as well.

[smitty3268]

As mattst88 explained, Intel contributed to tessellation and fp64, either by direct code contribution to core (non-hw-specific) parts or by doing reviews. So gallium drivers are *already* benefiting from Intel, Intel's driver doesn't need to be gallium for that.

I was specifically NOT discussing tessellation or fp64, so I'm not sure why you brought that up in relation to my quote. I never said Mesa as a whole didn't benefit from the work Intel is doing - it obviously does. I'm just saying that the other gallium drivers would benefit MORE if Intel switched to using it. All the work they do in meta would instead go into gallium, for example. And a lot of the higher level intel driver code would go into the state tracker as well. Obviously, there's still a lot that goes into hardware specific paths or basic Mesa code that is already shared, and that wouldn't change at all.

You do have a point with the HUD possibly, but I'm not sure about the other stuff. For example gallium having VAAPI doesn't mean all gallium drivers have it, nouveau doesn't - https://bugs.freedesktop.org/show_bug.cgi?id=89969. Likewise, similar to what I wrote above about ilo not having these GL extensions, it doesn't have VDPAU either. Like with GL extensions, hw-specific code is needed here as well.

Which is why I made a point of saying "almost" free. The i965 driver already has the necessary hardware backend support, and I can practically guarantee you someone would have hooked that up to the higher level state tracker code by now if they were able to use it.

[syrjala]

You do have a point with the HUD possibly, but I'm not sure about the other stuff. For example gallium having VAAPI doesn't mean all gallium drivers have it, nouveau doesn't - https://bugs.freedesktop.org/show_bug.cgi?id=89969. Likewise, similar to what I wrote above about ilo not having these GL extensions, it doesn't have VDPAU either. Like with GL extensions, hw-specific code is needed here as well.

Those pining for gallium hud should check out intel-gpu-overlay from intel-gpu-tools, and as for vaapi, there's libvdpau-va-gl

[Gusar]

and as for vaapi, there's libvdpau-va-gl

libvdpau-va-gl doesn't work with VLC or mpv. It might still work with flash, but last time I tried that, it actually consumed more resources than software decoding. So libvdpau-va-gl is not a solution, far from it. In my experience, all hw decode wrappers introduce additional copies and other inefficiencies that negate the advantage of using a hw decoder in the first place.
Not that it matters, mpv has great native vaapi support (VLC not so much, it's missing zero-copy with vaapi). And flash... meh, it's flash.

I'm not familiar with intel-gpu-overlay. Is it equivalent to the HUD, as in, can you get the same neat graphs the HUD has with it?


Note, I'm not actually advocating in this thread that Intel not using gallium is some sort of big deal. Quite the opposite, I don't see how exactly the entire graphics system could be significantly further along from where it is, just though the magic of Intel using gallium. The only point I see is the DX9 state tracker, but how critical it is that Intel doesn't have it is subject to debate.

[smitty3268]

I'm not familiar with intel-gpu-overlay. Is it equivalent to the HUD, as in, can you get the same neat graphs the HUD has with it?

Apparently it has to be run as root, and I don't think it provides nearly as much info. But it does apparently graph.

Note, I'm not actually advocating in this thread that Intel not using gallium is some sort of big deal. Quite the opposite, I don't see how exactly the entire graphics system could be significantly further along from where it is, just though the magic of Intel using gallium. The only point I see is the DX9 state tracker, but how critical it is that Intel doesn't have it is subject to debate.

Yeah, me neither. Intel has to do what they think is best for their driver. I just don't like it when people try to claim that it would accomplish nothing at all - it would definitely have some benefits, as well as some drawbacks. What that balance looks like is probably something only the driver devs can really say with any accuracy.