PDA

View Full Version : For OpenGL 4.6 deprecate non DSA functions in favor of DSA functions, counterparts.



Gedolo2
09-05-2014, 12:57 PM
Feature request:
As given in the title:
For OpenGL 4.6 core profile, deprecate non DSA functions in favor of DSA functions, counterparts.
To allow modern, less error prone, less bloated code in core profile. Being able to use only DSA functions would be very useful. It simplifies programming especially interfacing with middleware. Makes programming less error-prone, more error-resilient, easier to get it right.
The programming will form a smaller jump to port applications to future API's, such as the OpenGL NG work.

malexander
09-08-2014, 11:27 AM
I'm fine with this as long as the non-DSA functions are deprecated in, but not removed from, the core profile. The forward compatibility profile can remove them as it does with all deprecated features. The core profile is required for some modern GL3+ implementations (eg. OSX, Intel, Mesa), and I wouldn't want to suddenly have to support both after a hypothetical GL4.6 driver update. Some GL implementators can take a long time to get their driver to the most recent specification.

This is assuming that the ARB is even interested in doing deprecation anymore. It almost seems like deprecation itself is deprecated.

mbentrup
09-08-2014, 04:13 PM
I wonder who is the intended target for this DSA-only GL. Khronos already works on OpenGLng, which is presumably an entirely different API, with much lower driver overhead, less "cruft" and (I guess) better DirectX compatibility. So new projects and those who can afford to rewrite their OpenGL based apps will probably go straight for OpenGLng, and those who are locked into their legacy OpenGL code cannot simple rewrite in DSA style either.

Gedolo2
09-14-2014, 02:26 PM
We don't know when OpenGL NG might come out.
Since it's a complete rewrite from the ground up, it might take a lot of time.
In the meantime the current OpenGL would get some improvements, API cleanups, tidying up.
Writing in OpenGL NG might be very different from old OpenGL and application developers might want to wait until the ecosystem (driver stability) settles. Adding even more time before adoption.

The suggestion is mostly to reduce ridiculously ancient cruft in current OpenGL.
Not everyone who will be able to afford to rewrite to a completely new api but some might be able to afford or want only a step to DSA. As a compromise or cleanup before a big OpenGL NG rewrite of the rendering engine.


@malexander
I'm fine with what you suggest.

Mikkel Gjoel
09-29-2014, 05:17 AM
Yes, it would be great to get rid of the redundancy of dsa - for all the effort going into cleaning up OpenGL, dsa adds a remarkable amount of new cruft - complicating the API unnecessarily.

If we could possibly come up with a more consistent naming scheme as well, that would be lovely :) Having glNamed* on some functions, glTex* -> glTexture* is rather a mess. And no, I do not want to completely mangle my code by renaming functions myself - it makes it impossible for others to understand the code and look up the functions online.

While I understand and share the excitement for the nextgen-gl, and weariness of the eternal discussion of cleaning up current opengl, I think we can all agree that work on nextgen-gl will take some time - followed a good bit of time until devices (e.g. mobile) actually support it - then time for the drivers to properly support it and settle in. All in all, I think it is immensely important for current-gen OpenGL to remain in focus until we actually have a replacement.

Groovounet
10-08-2014, 06:15 AM
Yes, it would be great to get rid of the redundancy of dsa - for all the effort going into cleaning up OpenGL, dsa adds a remarkable amount of new cruft - complicating the API unnecessarily.

If we could possibly come up with a more consistent naming scheme as well, that would be lovely :) Having glNamed* on some functions, glTex* -> glTexture* is rather a mess. And no, I do not want to completely mangle my code by renaming functions myself - it makes it impossible for others to understand the code and look up the functions online.

While I understand and share the excitement for the nextgen-gl, and weariness of the eternal discussion of cleaning up current opengl, I think we can all agree that work on nextgen-gl will take some time - followed a good bit of time until devices (e.g. mobile) actually support it - then time for the drivers to properly support it and settle in. All in all, I think it is immensely important for current-gen OpenGL to remain in focus until we actually have a replacement.

Agreed 100%. I made suggestion directly following your reasoning to the group during ratification but the group rejected it. I am kind of still pissed of at this.

Gedolo2
10-13-2014, 11:34 AM
In OpenGL 4.6 DSA should become the preferred way to do things.
It's part of the core profile in OpenGL 4.5 already.
https://www.opengl.org/registry/doc/glspec45.core.pdf.

malexander
10-13-2014, 02:26 PM
It could be the preferred way to do things now in GL4.5. Why wait for another version?

Gedolo2
10-15-2014, 11:07 AM
I mean deprecating the non DSA ways.
For adapting applications it may be helpful to have one OpenGL version that has DSA(ARB) version and the old stuff not yet deprecated. You can rewrite things without deprecation warnings, you can look out for other mistakes warnings.

Since this version (OpenGL 4.5) is already out. This is a done deal.

Gedolo2
10-18-2014, 02:00 PM
Finally getting rid of the old state machine that only gets in the way!