Bindless Textures Land In Mesa Git For RadeonSI

[plonoma]

I would say maybe bindless textures, ES3.2, int64, No_error, ASTC and SPIR-V.

Thanks.
Interesting selection.

What's your opinion about the GL_ARB_indirect_parameters and GL_ARB_shader_draw_parameters extensions?
Would those be interesting extensions too?
https://www.khronos.org/registry/Ope...parameters.txt
https://www.khronos.org/registry/Ope...parameters.txt

[mibo]

DXMD doesn't like this extension, there is a game bug that Feral is going to fix soon.

Thanks for the info. Then I'll continue to wait :-)

[Azpegath]

Using mesamatrix.net, what extensions would you like to see adopted in the OpenGL core profile for an OpenGL 4.6 release?

I'm actually not experienced enough with these new extensions, to feel I have anything educated to say on the matter
AZDO does definitely feel like one, as well as the other ones that LinAGKar listed. I'd actually say "all of them", if it is in fact the last official OpenGL Core release. But perhaps it isn't? My impression from Khronos, as of lately, is that Vulkan has hit the ground running, and that it seems to be successful enough to completely supersede/replace OpenGL in the future.

[plonoma]

I'm actually not experienced enough with these new extensions, to feel I have anything educated to say on the matter
AZDO does definitely feel like one, as well as the other ones that LinAGKar listed. I'd actually say "all of them", if it is in fact the last official OpenGL Core release. But perhaps it isn't? My impression from Khronos, as of lately, is that Vulkan has hit the ground running, and that it seems to be successful enough to completely supersede/replace OpenGL in the future.

What would you think about an OpenGL AZDO profile in addition to the core and other profiles?

Just because Vulkan is doing very well doesn't mean OpenGL has reached it's final end point, destination or version.
I'm in favor of another OpenGL release for integrating some stuff into core.
Things like OpenGL ES 3.2 profile making desktop GL a pure superset of ES.
Using ASTC: predecessor S3TC is technically inferior and patented: http://www.patentcountdown.org/,
SPIR-V much better than source code shaders,
AZDO: Almost Zero Driver Overhead https://www.khronos.org/assets/uploa...-GDC-Mar14.pdf.
And maybe, if it provides some practical benefits, some OpenGL-Vulkan interoperability extension(s).
Some of these extensions would allow graphics engine makers build code more similar to Vulkan.
Thus making the jump from OpenGL to Vulkan less one giant leap, more multiple smaller leaps.

[Azpegath]

What would you think about an OpenGL AZDO profile in addition to the core and other profiles?

Just because Vulkan is doing very well doesn't mean OpenGL has reached it's final end point, destination or version.
I'm in favor of another OpenGL release for integrating some stuff into core.
Things like OpenGL ES 3.2 profile making desktop GL a pure superset of ES.
Using ASTC: predecessor S3TC is technically inferior and patented: http://www.patentcountdown.org/,
SPIR-V much better than source code shaders,
AZDO: Almost Zero Driver Overhead https://www.khronos.org/assets/uploa...-GDC-Mar14.pdf.
And maybe, if it provides some practical benefits, some OpenGL-Vulkan interoperability extension(s).
Some of these extensions would allow graphics engine makers build code more similar to Vulkan.
Thus making the jump from OpenGL to Vulkan less one giant leap, more multiple smaller leaps.

I agree with all those points. Perhaps it's time for them to deprecate even more of the old stuff, to clean up how you handle memory, write shaders and to remove old ENUMs.

I'd actually like a slimmed down gl.h file, to only contain the stuff you should use, and not the old, deprecated API.

[plonoma]

I agree with all those points. Perhaps it's time for them to deprecate even more of the old stuff, to clean up how you handle memory, write shaders and to remove old ENUMs.

I'd actually like a slimmed down gl.h file, to only contain the stuff you should use, and not the old, deprecated API.

Thanks.
But would you want a cleaned up AZDO profile in OpenGL or not?

And they already have a somewhat slimmed down OpenGL header file:

<GL/glcorearb.h> - OpenGL core profile and ARB extension interfaces, as described in appendix G.2 of the OpenGL 4.3 Specification. Does not include interfaces found only in the compatibility profile.

But then again having an even more slimmed down header file having only a specific OpenGL core version would be a great thing to have.
Khronos providing an <GL/glcore4_5.h> with only stuff in that specific profile and an <GL/glcore4_5arb.h> with the addition of ARB extension interfaces would be great.

[Azpegath]

Thanks.
But would you want a cleaned up AZDO profile in OpenGL or not?

And they already have a somewhat slimmed down OpenGL header file:

But then again having an even more slimmed down header file having only a specific OpenGL core version would be a great thing to have.
Khronos providing an <GL/glcore4_5.h> with only stuff in that specific profile and an <GL/glcore4_5arb.h> with the addition of ARB extension interfaces would be great.

I'm not sure another profile would be high on my priorities list, since some of the features are still Nvidia-only (or am I mistaken? I thought there was at least one NV_ extension, but hopefully they will all become core extensions now), but I don't think it would be a bad thing.

And they already have a somewhat slimmed down OpenGL header file:

Thank you for the tip on glcorearb.h! I didn't know that existed, that will help me. Perhaps, like you said, an even more specific one, with the pure AZDO profile, would be the next step to take then.

[plonoma]

I'm not sure another profile would be high on my priorities list, since some of the features are still Nvidia-only (or am I mistaken? I thought there was at least one NV_ extension, but hopefully they will all become core extensions now), but I don't think it would be a bad thing.

The idea of a standardized AZDO profile would ideally not have any vendor specific extensions.
However an extension originating from one vendor does not mean it can not be supported and become standard functionality on multiple other vendors hardware.
It's also just a part of a name. Might not mean much if anything concerning standardization.

Thank you for the tip on glcorearb.h! I didn't know that existed, that will help me. Perhaps, like you said, an even more specific one, with the pure AZDO profile, would be the next step to take then.

Yep. Slimmed down header files could be very interesting for application developers.

[plonoma]

Thank you for the tip on glcorearb.h! I didn't know that existed, that will help me. Perhaps, like you said, an even more specific one, with the pure AZDO profile, would be the next step to take then.

You can help make these new headers become a reality by asking The Khronos Group yourself:
Go to The Khronos Group forums and ask:

https://www.opengl.org/discussion_boards/

https://forums.khronos.org/forum.php

[plonoma]

I agree with all those points. Perhaps it's time for them to deprecate even more of the old stuff, to clean up how you handle memory, write shaders and to remove old ENUMs.

I'd actually like a slimmed down gl.h file, to only contain the stuff you should use, and not the old, deprecated API.

I would like some old, long deprecated stuff to be deprecated and removed too.
I think they will not integrate OpenGL ES 3.2 due to lack of popularity.
It seems OpenGL ES 3.1 is popular but not ES 3.2.
Maybe the best way for The Khronos Group to handle this is to find out which extensions are not popular and make an OpenGL ES 4.0 release without those ES 3.2 extensions.
Removing requiring them and breaking backwards compatibility.
While improving the API with some nice stuff such as GL_ARB_multi_bind, GL_ARB_direct_state_access, GL_ARB_indirect_parameters,
GL_ARB_shader_draw_parameters, GL_ARB_gl_spirv and other extensions.


I definitely want to see the following extensions integrated into core OpenGL:
GL_ARB_indirect_parameters
GL_ARB_shader_draw_parameters

They allow for more compact and higher performance code.
Adding those extensions to core OpenGL (and OpenGL ES) would really improve the OpenGL API. Would help with application code quality and performance.
GPUs are SIMD processors, let the API reflect that.
Reducing draw calls is good.
Especially with external GPUs.


(And I believe there is a somewhat similar extension in Vulkan.
Adding these similar OpenGL extensions to core would make OpenGL more similar to Vulkan.
And thus could help with porting OpenGL applications to Vulkan.)