Valve Begins Working On OpenGL External Objects Support For Mesa

[phoronix]

Phoronix: Valve Begins Working On OpenGL External Objects Support For Mesa

Andres Rodriguez of Valve has published initial support for the OpenGL EXT_external_objects within Mesa, the new GL extensions likely to be part of OpenGL 4.6...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-GL-External-Objects

[Kemosabe]

This can be used for a hypothetical hybrid OpenGL/Vulkan scenario? Or what's the point of making OpenGL more Vulkan like. To ease the transition so nobody has to rewrite the whole rendering pipeline at once?

[ElectricPrism]

This can be used for a hypothetical hybrid OpenGL/Vulkan scenario? Or what's the point of making OpenGL more Vulkan like. To ease the transition so nobody has to rewrite the whole rendering pipeline at once?

You answered your own question maybe?

Who is SBC Global again?

[computerquip]

This can be used for a hypothetical hybrid OpenGL/Vulkan scenario? Or what's the point of making OpenGL more Vulkan like. To ease the transition so nobody has to rewrite the whole rendering pipeline at once?

Whenever an extension has questionable purpose, lookup the extension. The overview is generally very human-readable: https://www.khronos.org/registry/Ope...al_objects.txt

Overview

The Vulkan API introduces the concept of explicit memory objects and reusable synchronization objects. This extension brings those concepts to the OpenGL API via two new object types:
Memory objects
Semaphores

Rather than allocating memory as a response to object allocation, memory allocation and binding are two separate operations in Vulkan. This extension allows an OpenGL application to import a Vulkan memory object, and to bind textures and/or buffer objects to it. No methods to import memory objects are defined here. Separate platform-specific extensions are defined for this purpose. Semaphores are synchronization primitives that can be waited on and signaled only by the GPU, or in GL terms, in the GL server. They are similar in concept to GL's "sync" objects and EGL's "EGLSync" objects, but different enough that compatibilities between the two are difficult to derive. Rather than attempt to map Vulkan semaphores on to GL/EGL sync objects to achieve interoperability, this extension introduces a new object, GL semaphores, that map directly to the semantics of Vulkan semaphores. To achieve full image and buffer memory coherence with a Vulkan driver, the commands that manipulate semaphores also allow external usage information to be imported and exported.

[plonoma]

the new GL extensions likely to be part of OpenGL 4.6.

OpenGL is going to get a 4.6 release.

it looks like these new OpenGL extensions will help out as part of their SteamVR on Linux push for games not relying exclusively on Vulkan.

Seems OpenGL hasn't stopped just yet.
Here are some other things they could do:

Add following extensions to the core profile:

GL_ARB_shader_draw_parameters

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shader_draw_parameters.txt

GL_ARB_indirect_parameters

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_indirect_parameters.txt

GL_ARB_seamless_cubemap_per_texture
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_seamless_cubemap_per_texture.txt

Make desktop OpenGL a pure superset of the newest OpenGL ES (OpenGL ES3.2):
Add GL_ARB_ES3_2_compatibility to core

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_ES3_2_compatibility.txt

Improve texture compression formats:
Make S3TC support optional and recommend supporting ASTC as preferred texture storage format.
ASTC is technically better and also not patented.

SPIR-V
GL_ARB_gl_spirv

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt

Maybe OpenGL can relax some requirements?
Specify OpenGL drivers have to at least support either source code shaders or SPIR-V.
Allow application developers to specify a generally preferred version of the shaders when drivers implement both (well).
Useful for when application developers package both in their OpenGL application.
Or alternatively add SPIR-V support to core. And drivers have to at least support SPIR-V.
SPIR-V is much better than the previous OpenGL source code solution.
Helps driver development.

When making new extensions.
Try to make OpenGL like Vulkan.
Reducing the leap between OpenGL and Vulkan when porting an application.

Deprecate and remove as much obsolete stuff as practical from the OpenGL core profile.
Maybe start deprecating and removing stuff replaced by direct state access in the core profile:

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_direct_state_access.txt

GL_ARB_direct_state_access has been core starting from OpenGL 4.5, released in August 11, 2014 and is currently the most recent version.

Improve the OpenGL specification/documentation.
OpenGL core profile can improve clarity and remove unspecified or ambiguous behaviour to get rid of implementation problems.
All without impacting legacy applications and drivers on earlier OpenGL core and compatibility profile versions negatively.
The neat thing about the core profile is that each version kinda forms it's own API. In some ways independent from earlier and later versions.
Providing flexibility without harming compatibility for old applications on new drivers.
Newer drivers can implement multiple newer, later core profile versions without impacting applications that use older, earlier versions.
Applications only interact with the core profile path they request and use.
Using core profile versions, newer applications could be made using newer well-specified behaviour and drivers could then also implement unambiguously specified behaviour.
Solving driver and application behaviour problems without any downsides for legacy applications.
Also improving the ability to interoperate with other applications/API's through
clearly specified, unambiguous behaviour (not performance) of the API.
Less game problems and less misusing tuning options to make things work.
Goal should be for the specification to not need tuning options to avoid bugs, crashes and problems caused by driver implementation differences.
OpenGL specification should be improved to handle this instead of having to resort to tuning parameters:
Mesa Preparing To Support Gallium Driver Specific DRIRC Tuning Options
https://www.phoronix.com/scan.php?page=news_item&px=Gallium-Driver-Specific-Tuning



See Also:
Phoronix: Bindless Textures Land In Mesa Git For RadeonSI

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/957402-bindless-textures-land-in-mesa-git-for-radeonsi

[plonoma]

Whenever an extension has questionable purpose, lookup the extension. The overview is generally very human-readable: https://www.khronos.org/registry/Ope...al_objects.txt

memory allocation and binding are two separate operations in Vulkan.

That is really good API design. Vulkan is a well designed API in that respect.

[artivision]

It doesn't help at all because those new extensions will only be available to newer Vulkan friendly GPU's. The best would be to port a basic Vulkan support to HD5-6 series and Fermi, externally from those legacy drivers.

[smitty3268]

Improve texture compression formats:
Make S3TC support optional and recommend supporting ASTC as preferred texture storage format.
ASTC is technically better and also not patented.

S3TC is already optional in GL. It's only defacto required because all the actual applications choose to use it (because Direct3D). Also, the patents expire in a few months.

ASTC is unlikely to be required in GL 4.6 because 99% of desktop hardware doesn't implement it. 4.2 already added BPTC which will be much more widespread on the desktop (also used by Direct3D).

[plonoma]

S3TC is already optional in GL. It's only defacto required because all the actual applications choose to use it (because Direct3D). Also, the patents expire in a few months.

ASTC is unlikely to be required in GL 4.6 because 99% of desktop hardware doesn't implement it. 4.2 already added BPTC which will be much more widespread on the desktop (also used by Direct3D).

How does BPTC compare to ASTC in terms of features, efficiency (decode and encode, region coding/decoding and compression?

[smitty3268]

How does BPTC compare to ASTC in terms of features, efficiency (decode and encode, region coding/decoding and compression?

ASTC is far more flexible and allows much higher levels of compression (with a corresponding quality tradeoff) which is why it's so important for mobile/embedded hardware.

BPTC is focused on providing high quality assets with a reasonable level of compression, and in that role I think it's supposed to be a bit better than ASTC, it just doesn't scale down.

I think the flexibility of ASTC makes it a bit expensive to add to hardware, so the desktop GPU manufacturers haven't been rushing to add it. Intel added it with Skylake/Kaby Lake, but AMD only has it in their Stoney Ridge APUs (very low power), and NVidia has only added it to Tegra. (Actually some of the desktop drivers do "support" ASTC, but just by always decoding it in software and then running the app as if there was no texture compression. That works because ASTC is only used in mobile apps so far that expect far fewer resources, but it wouldn't fly in general for all applications and therefore it's unlikely to be a required part of desktop GL. But who knows, maybe the GLES3.2 superset is important enough that they'd be happy to just allow the software solution, it just seems doubtful to me).

BPTC was introduced as part of DX11 so it's pretty widespread on the desktop side at this point. We're probably getting to the point soon where requiring DX11 hardware to run a game is going to fly with developers.