search

KhronosGroup / OpenGL-Registry

OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
679 stars 274 forks source link

Registering EXT_texture_sRGB_RG8 for desktop OpenGL #450

Closed Cyphall closed 3 years ago

Cyphall commented 3 years ago

Extensions EXT_texture_sRGB_R8 and EXT_texture_sRGB_RG8 were initially created for OpenGL ES to add respectively 1-component and 2-components sRGB formats.

In 2018, EXT_texture_sRGB_R8 was registered for desktop OpenGL. However, up to this day, EXT_texture_sRGB_RG8 is still not available on desktop OpenGL, which means we have 1, 3 and 4 components sRGB formats, but not 2 components.

Could someone register EXT_texture_sRGB_RG8 on desktop OpenGL to fill this hole?

(I'm still a student so I'm a bit afraid of editing myself something as official as an OpenGL extension specification)

Perksey commented 3 years ago

Ah don't let being a student stop you with any of this, I was a student when starting to contribute to the OpenGL spec!

We'll likely need evidence of a desktop OpenGL driver implementing this extension before marking it as supported on OpenGL, so if you have that to hand that'd be great. If one of the big three supports it then it should be a pretty easy change.

dgkoch commented 3 years ago

Could someone register EXT_texture_sRGB_RG8 on desktop OpenGL to fill this hole?

As @Perksey notes, there is no point in doing this unless someone is planning to support it. It would also need to have interactions with the desktop specs added.

For NVIDIA we can't support it, otherwise we probably would have already done so.

Cyphall commented 3 years ago

We'll likely need evidence of a desktop OpenGL driver implementing this extension before marking it as supported on OpenGL

Wait, aren't the extension specifications coming first and only then the GPU manufacturers implement them in their driver?

Also, I checked the support of the Vulkan equivalents (VK_FORMAT_R8_SRGB and VK_FORMAT_R8G8_SRGB) on gpuinfo.org and only the first is supported by Nvidia, while AMD support both of them. Could there be hardware constraints on Nvidia GPUs?

Perksey commented 3 years ago

EXT extensions are only registered once a vendor or two supports them. The textual specifications may be added beforehand as a draft but generally the XML isn't modified until a vendor supports, or is actively working to support the extension.

Cyphall commented 3 years ago

According to gpuinfo.com, the extension EXT_texture_sRGB_RG8 is supported by a lot of AMD GPUs on OpenGL Core (4.6).

pdaniell-nv commented 3 years ago

NVIDIA can't support this, but considering AMD does, and potentially others could, it seems reasonable to me to register this in the OpenGL registry. AMD should have registered this before exposing it, but late is better than never. Someone will need to update the existing EXT_texture_sRGB_RG8 spec to add OpenGL interactions, similar to what was done in revision 4 of https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_sRGB_R8.txt.

Cyphall commented 3 years ago

@pdaniell-nv Do you know by any chance the reason why Nvidia cannot support this extension? Linear RG and sRGB are both supported, and sRGB Red is too, so I'm very curious on why sRGB RG would not work.

dgkoch commented 3 years ago

@Cyphall NVIDIA hardware doesn't support sRGB conversion on the second component for 2-component formats, so any support would need to be emulated.

I think the better question is - do you have a specific use-case for it?

nwnk commented 3 years ago

Mesa doesn't expose this extension at all at the moment, but Mesa's software format code supports sRGB R8G8 sources, so we could certainly at least support it in softpipe. Adding it to llvmpipe and the meta drivers (virgl, zink, d3d12) is probably straightforward as well, and from a quick scan of the source it looks like we could wire it up for the panfrost, freedreno, and radeonsi drivers as well.

iris and nouveau look like they support L8A8 sRGB, presumably only the L channel is sRGB-encoded there.

Nothing else looks to (obviously) have sRGB sampling support from two-channel textures, so emulating it would involve expanding the texture to 24 or 32 bit internally, bit of a waste. Assuming that's even a legal move, I know you're allowed to use more bits internally but I don't know about more channels.

Cyphall commented 3 years ago

@dgkoch It was more for convenience of supporting any sRGB texture without wasting space (if I happen to come across greyscale-alpha textures, like a metal color texture that happen to be 100% gray).

As 1, 3 and 4 components are supported, I thought the 2 components sRGB format would already be supported by the hardware and the extension was simply forgotten when the 1 component sRGB one was added to desktop OpenGL.

dgkoch commented 3 years ago

(if I happen to come across greyscale-alpha textures, like a metal color texture that happen to be 100% gray).

You'd want an L8A8_sRGB format for that (which NVIDIA could support, if we don't already), because you don't want sRGB conversion on the Alpha channel.

Cyphall commented 3 years ago

You'd want an L8A8_sRGB format for that (which NVIDIA could support, if we don't already), because you don't want sRGB conversion on the Alpha channel.

As I'm using swizzle for this case, I was hoping the swizzle would happen before the sRGB conversion (I didn't tested it yet).

There is a GL_SLUMINANCE8_ALPHA8_EXT in EXT_texture_sRGB which would perfectly suit my need but sadly, the term "luminance" being deprecated, this format is not available on OpenGL 4.6 Core (on my GTX 1070, atleast).

Perksey commented 3 years ago

NVIDIA can't support this, but considering AMD does, and potentially others could, it seems reasonable to me to register this in the OpenGL registry. AMD should have registered this before exposing it, but late is better than never. Someone will need to update the existing EXT_texture_sRGB_RG8 spec to add OpenGL interactions, similar to what was done in revision 4 of https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_sRGB_R8.txt.

I suppose it's probably worth pinging someone from AMD in here as I'm not sure if there are any specific gotchas to be aware of. If it's pretty much the same as the R8 one, however, I think that's something I'll be able to get around to.

nwnk commented 3 years ago

Went ahead and wrote this up for Mesa, should anyone be interested.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8060

Perksey commented 3 years ago

Awesome! I will propose changes to the spec then, seeing as it has confirmed support by a vendor. If you could look over it that'd be great.

nwnk commented 3 years ago

Awesome! I will propose changes to the spec then, seeing as it has confirmed support by a vendor. If you could look over it that'd be great.

Nice! The mesa MR needs a bit more work to actually pass CI and get merged, once I have that working I’ll give the spec changes a once over, should be sometime this week if all goes well.