Patches Revised Taking RadeonSI OpenGL Compatibility Profile To v4.0

[phoronix]

Phoronix: Patches Revised Taking RadeonSI OpenGL Compatibility Profile To v4.0

Valve's Timothy Arceri after getting the RadeonSI OpenGL compatibility profile support to GL 3.3 has been working on OpenGL 4.4 compatibility profile support but with one of those extensions taking a while to wire up, for now he sent out the patches bumping the support to OpenGL 4.0 under this compatibility mode...

http://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-GL-Compat-4.0-Patches

[gutigone]

Valve's Timothy Arceri after getting

Missing a few words there, doesn't make a lot of sense how you've written it.

[Michael]

Missing a few words there, doesn't make a lot of sense how you've written it.

Should be cleared up now. Thanks.

[DanL]

Missing a few words there, doesn't make a lot of sense how you've written it.

It makes sense if you put commas after "after" and "3.3"
That would also make it a very long and awkward sentence.

EDIT: Ninja'd

[darkbasic]

That was fast, I start to think that the whole opposition against compatibility profiles was more political rather than technical.

[chithanh]

I think bridgman explained a number of times that the problem was not getting compatibility profile to be supported. The problem is that a lot of behavior isn't defined by the spec, but rather implementation-dependent. In order to usefully support compatibility profiles, the behavior of the NVidia proprietary driver needs to be emulated.

[shmerl]

I think bridgman explained a number of times that the problem was not getting compatibility profile to be supported. The problem is that a lot of behavior isn't defined by the spec, but rather implementation-dependent. In order to usefully support compatibility profiles, the behavior of the NVidia proprietary driver needs to be emulated.

Shouldn't the reference rather be AMD's closed driver? That's the most common use case for compat profile on AMD now (various legacy CAD applications and the like), and replacing it with Mesa can avoid this code duplication. So why should Nvidia be emulated instead?

[chithanh]

NVidia sets the standard here, due to their market position.
AMD's closed driver also needs to emulate NVidia's driver in order to execute OpenGL compatibility profile applications properly.

[schwarzman]

I think bridgman explained a number of times that the problem was not getting compatibility profile to be supported. The problem is that a lot of behavior isn't defined by the spec, but rather implementation-dependent. In order to usefully support compatibility profiles, the behavior of the NVidia proprietary driver needs to be emulated.

Also it was more important to implement OpenGL 4.5/4.6 + optimize OpenGL performance (+ DAL/DC upstreaming, support for Vega/Raven Ridge, ...). As all of that is resolved by now (with the major ongoing task being nir conversion/SPIRV) is seems like AMD figured they can afford some resources to implement support for OpenGL compatibility profiles.

I suspect we are really seeing the "final phase" of AMD's proprietary (Linux) OpenGL driver. Once OpenGL 4.6 compat is implemented AMD likely checks the most important "workstation" applications and put the proprietary driver into "maintenance" mode. So it might be that the proprietary driver can finally die in maybe 2-3 years...

[smitty3268]

That was fast, I start to think that the whole opposition against compatibility profiles was more political rather than technical.

I think that was always the case on the Intel side, and likely still is. At least, if you include "this isn't well defined so we just don't want to do it, and apps should adjust anyway" as a political reason.

I don't recall hearing a whole lot on the subject from the AMD side, though. I think it was just a manpower situation there, with them wanting to get solid core profile drivers out before starting to work on (as others have mentioned) the much more nebulously defined compatibility profile.

The truth is that open source and embedded apps don't really need the compat profile, so there wasn't a lot of reason for Intel to care about them. It's more used by the gaming sector and workstation apps, which are typically only well supported by AMD and NVidia (and vice versa), so it makes sense that they would be the ones bringing support into Mesa.