3 ms·

I'm curious - what would you need OpenGL compatibility profile for?

rnhmjoj 9y ago
I have no idea why but there are video games (even fairly recent ones) that requires the compatibility profile. No Man's Sky and Dying Light for example.
badsectoracula 9y ago
Regardless of what i'd personally need it for, it is still something that NVIDIA's drivers provide and AMD/Mesa lack and thus a negative on Mesa's side (especially considering that NVIDIA not only provides all that extra stuff but they still manage to be faster than the implementations - like Mesa and Apple - that do not). Now as for what I would need the compatibility profile, it is very simple: i just find it more convenient to use so i have a ton of code that uses it. The original idea for the separation of profiles was that the core profile would make implementing OpenGL easier and make it faster but neither of those actually happened (as i said, NVIDIA despite implementing the entirety of OpenGL is still the fastest implementation) while i really disagree with the idea of pushing the complex bits towards the end users (of the API) in order to avoid the implementors doing it. It is better to have 1 developer on the driver/implementation side handle the complexity that 1000 users (of the API) are going to enjoy than have each one of those 1000 users make 1000 individual solutions to that complexity, thus multiplying the time spent on the complexity by 1000 (this of course applies to all tech that by itself is "simple" only because it pushes the hard bits to its clients - see Wayland as another example). Ok, so actually i have two reasons, one practical (i find it convenient) and one more ideological (pushing complexity upwards). Actually i have two ideological reasons, the second (and actually more important) is that i dislike backwards incompatible breakage in APIs and libraries (unless that API is meant for internal or utility use, of course, or is in beta/development stage). This is a much bigger issue though, so let's leave it at that :-P.
- gmueckl 9y ago
  The hard truth is that OpenGL 3.0 was far too tame when it came to breaking compatibility. Initially, they tried to design something much closer to Vulkan (back in 2008!), but ended up with a far too conservative final specification to make backwards compatibility possible. The disappointment among OpenGL users after the release of the final 3.0 specification was very real. If you have a good understanding of how GPUs actually work (of which the OpenGL pipeline is just a very crude and simplistic abstraction), you can understand why modern APIs like Vulkan and DX12 are the way they are and also the power they hand to a capable user. The hardware model underlying the design of OpenGL has aged. The one used for 1.0 and 1.1 is so outdated now that using it runs exactly counter to what the driver needs to do on hardware built within the last 15 years. The story gets a bit better once you get to vertex buffers, but those are not exposed in a way that lets the driver handle them without any guesswork on its part. The same is true for textures and framebuffers. Even that damned global OpenGL state is a quint relic of the past. Modern drivers should get the desired new state all at once instead of piecemeal through a chain of calls that triggers expensive recomputation of the desired actual GPU hardware state at each step. Instead of clinging to OpenGL 1.x or 2.x for no good reason, you should really switch to a high level drawing library or rendering engine that knows how to pass things properly to an underlying modern API.
  - badsectoracula 9y ago
    > The hard truth is that OpenGL 3.0 was far too tame when it came to breaking compatibility. That is your opinion, mine is that breaking compatibility is the wrong answer in all but the most extreme cases (of which OpenGL was not). Keep in mind however that i am talking about OpenGL. IMO they should have indeed created a more low level API similar to Vulkan back in 3.0, but instead of calling it OpenGL 3.0 they should have called it something else (like, i dunno, Vulkan :-P) and left OpenGL 3.0 alone to be an easy to use and fully backwards compatible API without creating an unnecessary schism (like the one we have with Apple/Mesa and everyone else today). Of course that is what they eventually did with Vulkan, but i'd rather have that without the damage that they made to OpenGL. > Instead of clinging to OpenGL 1.x or 2.x for no good reason I have a good reason, i already explained it in my post. > you should really switch to a high level drawing library or rendering engine That library already exists and is called OpenGL with the compatibility profile. The only problem is that it isn't supported by every vendor that claims OpenGL support.

I have no idea why but there are video games (even fairly recent ones) that requires the compatibility profile. No Man's Sky and Dying Light for example.

badsectoracula 9y ago

Regardless of what i'd personally need it for, it is still something that NVIDIA's drivers provide and AMD/Mesa lack and thus a negative on Mesa's side (especially considering that NVIDIA not only provides all that extra stuff but they still manage to be faster than the implementations - like Mesa and Apple - that do not). Now as for what I would need the compatibility profile, it is very simple: i just find it more convenient to use so i have a ton of code that uses it. The original idea for the separation of profiles was that the core profile would make implementing OpenGL easier and make it faster but neither of those actually happened (as i said, NVIDIA despite implementing the entirety of OpenGL is still the fastest implementation) while i really disagree with the idea of pushing the complex bits towards the end users (of the API) in order to avoid the implementors doing it. It is better to have 1 developer on the driver/implementation side handle the complexity that 1000 users (of the API) are going to enjoy than have each one of those 1000 users make 1000 individual solutions to that complexity, thus multiplying the time spent on the complexity by 1000 (this of course applies to all tech that by itself is "simple" only because it pushes the hard bits to its clients - see Wayland as another example). Ok, so actually i have two reasons, one practical (i find it convenient) and one more ideological (pushing complexity upwards). Actually i have two ideological reasons, the second (and actually more important) is that i dislike backwards incompatible breakage in APIs and libraries (unless that API is meant for internal or utility use, of course, or is in beta/development stage). This is a much bigger issue though, so let's leave it at that :-P.

gmueckl 9y ago
The hard truth is that OpenGL 3.0 was far too tame when it came to breaking compatibility. Initially, they tried to design something much closer to Vulkan (back in 2008!), but ended up with a far too conservative final specification to make backwards compatibility possible. The disappointment among OpenGL users after the release of the final 3.0 specification was very real. If you have a good understanding of how GPUs actually work (of which the OpenGL pipeline is just a very crude and simplistic abstraction), you can understand why modern APIs like Vulkan and DX12 are the way they are and also the power they hand to a capable user. The hardware model underlying the design of OpenGL has aged. The one used for 1.0 and 1.1 is so outdated now that using it runs exactly counter to what the driver needs to do on hardware built within the last 15 years. The story gets a bit better once you get to vertex buffers, but those are not exposed in a way that lets the driver handle them without any guesswork on its part. The same is true for textures and framebuffers. Even that damned global OpenGL state is a quint relic of the past. Modern drivers should get the desired new state all at once instead of piecemeal through a chain of calls that triggers expensive recomputation of the desired actual GPU hardware state at each step. Instead of clinging to OpenGL 1.x or 2.x for no good reason, you should really switch to a high level drawing library or rendering engine that knows how to pass things properly to an underlying modern API.
- badsectoracula 9y ago
  > The hard truth is that OpenGL 3.0 was far too tame when it came to breaking compatibility. That is your opinion, mine is that breaking compatibility is the wrong answer in all but the most extreme cases (of which OpenGL was not). Keep in mind however that i am talking about OpenGL. IMO they should have indeed created a more low level API similar to Vulkan back in 3.0, but instead of calling it OpenGL 3.0 they should have called it something else (like, i dunno, Vulkan :-P) and left OpenGL 3.0 alone to be an easy to use and fully backwards compatible API without creating an unnecessary schism (like the one we have with Apple/Mesa and everyone else today). Of course that is what they eventually did with Vulkan, but i'd rather have that without the damage that they made to OpenGL. > Instead of clinging to OpenGL 1.x or 2.x for no good reason I have a good reason, i already explained it in my post. > you should really switch to a high level drawing library or rendering engine That library already exists and is called OpenGL with the compatibility profile. The only problem is that it isn't supported by every vendor that claims OpenGL support.