Inspired by the discussion here: https://www.opengl.org/discussion_boards/showthread.php/199851-Official-feedback-on-OpenGL-4-6-thread/page2
It’s great to have GL_ARB_shader_draw_parameters in core OpenGL with the OpenGL 4.6 release.
But the parameters could be done better.
Please bring Vulkan’s VertexIndex and InstanceIndex input values to OpenGL.
They can be hooked into the OpenGL semantics, using KHR_vulkan_glsl’s definition of
gl_InstanceIndex. And the SPIR-V equivalent would allow us to use
And some well specified conversion functions for converting between
gl_InstanceID + gl_BaseInstance. Using specialized, standardized conversion functions could allow software tools to more easily, automatically detect conversions and optimize them.
Maybe call it GL_ARB_shader_draw_index_parameters, GL_ARB_shader_draw_elements_index,
GL_ARB_shader_draw_better_parameters or something else.
Might get a bit messy because some extension equivalents and mappings are a superset of their OpenGL equivalent extension. Such as VK_KHR_shader_draw_parameters being a superset.
Anyway, the extra functionality mentioned, some sort of arrayed drawing commands is interesting.
The functionality could be put in the proposed new draw parameters extension.
Bring arrayed drawing commands to OpenGL for as well they can be brought to OpenGL.
[Vulkan® 1.0.245 - A Specification (with all registered Vulkan extensions)](Index of /vulkan/specs/1.0-extensions /html/vkspec.html#VK_KHR_shader_draw_parameters)
Interactions and External Dependencies
Requires the SPV_KHR_shader_draw_parameters SPIR-V extension.
Requires GL_ARB_shader_draw_parameters for GLSL source languages.
Adding arrayed drawing commands in the equivalent SPIR-V extension is bad.
They should have put the support for arrayed drawing commands in a separate extension.
A clean mapping would have been better.
If you add a mapping, conversion extension for something. Do not extend it, do not make it a superset!