Support OpenGL ES

[amyspark]

Hi,

Again here from the v2 porting effort from Krita. I noticed that OCIO v2 uses 1D textures throughout the OpenGL helpers and GPU shader utilities, which renders OCIO's new GPU pipeline incompatible with OpenGL ES.

Since our HDR support depends on ANGLE, which in turn provides OpenGL ES, is there any way to drop this optimization?

(In the meanwhile, I'll hardcode the legacy pipeline and add some #defines to patch them.)

[remia]

Hi @amyspark,

Interesting point, easy to forget these limitations. Given that the OpenGL helper code is not part of the core library and only meant as a tool to show how to implement the general use case, can't you just roll your own code to achieve the same without using 1D Texture ? Is it a matter of updating the code to allocate a 2D Texture with a Height of 1 instead of a 1D Texture as done currently or is there caveats to that ?

Edit: realised the generated GLSL might contain sampler1D uniforms or texture1D calls which would be harder to handle cleanly without manual patching of the code.

[amyspark]

Edit: realised the generated GLSL might contain sampler1D uniforms or texture1D calls which would be harder to handle cleanly without manual patching of the code.

While I can save the 1D texture into 2D in app code, actually accessing it (due to vector conversion rules) will require a NxN 2D texture of which only its diagonal will be occupied. (not good!)

[hodoulp]

@amyspark Based on the discussion it seems that the only difference between OpenGL GLSL and OpenGL ES is the lack of 1D LUT support. That seems quite small!

I have few more questions concerning the Krita integration:

• What is ANGLE?
• Could you help a little bit more Since our HDR support depends on ANGLE, which in turn provides OpenGL ES?

With the OpenColorIO perspective in mind, another option would be to natively implement the OpenGL ES translation support in the OpenColorIO library (like GLSL, HLSL, etc.).

[amyspark]

@hodoulp Angle is a library of Google's that implements OpenGL ES on top of DirectX 9. Qt 5 uses it to provide an alternative implementation to Windows's native OpenGL drivers, which are often buggy and otherwise unstable. Here is the Qt wiki page.

Could you help a little bit more Since our HDR support depends on ANGLE, which in turn provides OpenGL ES?

Using ANGLE is the only way to support HDR in Windows without having to port Krita's canvas to DirectX. Our lead dev is giving a talk at the W3C Workshop on Wide Color Gamut and High Dynamic Range for the Web about this, and our HDR support in general: WCG & HDR: Color creation and manipulation.

With the OpenColorIO perspective in mind, another option would be to natively implement the OpenGL ES translation support in the OpenColorIO library (like GLSL, HLSL, etc.).

This would be awesome. In fact, for v1, apps supporting OpenGL ES or macOS's OpenGL Core Profile need to apply extra defines to make OCIO work, e.g. Blender and Krita. Thankfully, these are simple, but with the new GPU pipeline, it becomes impossible to patch that downstream.

The expected changes should be pretty simple, and should help OCIO be fully compatible with both OpenGL ES and OpenGL Core profile without needing a separate language entry:

• replace all calls to texture3D with texture
  • texture3D is an extension
• replace all calls to texture2D with texture
  • texture2D is deprecated as of GLSL 3.30, and doesn't even exist in OpenGL ES
• replace all instancing of unidimensional textures and vectors with at least a 2D equivalent
  • 1D isn't supported at all according to the GLSL ES standard, section 1.16

[hodoulp]

Note 1: OpenColorIO version 2 already supports OpenGL Core Profile by using OCIO::GPU_LANGUAGE_GLSL_4_0 which covers most of the needed changes.

Note 2: I did not say that I will do it 😄. I only have questions to understand the Krita context/needs and 'feel' the scope of the work. If the changes are so minimal (because Core Profile is already supported) that could be a good work for external contributors having the need & able to test 😄.

[amyspark]

Note 1: OpenColorIO version 2 already supports OpenGL Core Profile by using OCIO::GPU_LANGUAGE_GLSL_4_0 which covers most of the needed changes.

This just made me notice we've been restricting ourselves to 3.2 for ages. I'll ping our Mac dev and ask him if we can upgrade versions.

If the changes are so minimal (because Core Profile is already supported) that could be a good work for external contributors having the need & able to test smile.

It's very much doable, but the 1D texture changes make me wonder if those are admissible without adding a whole new GpuLanguage?

[hodoulp]

If the changes are so minimal (because Core Profile is already supported) that could be a good work for external contributors having the need & able to test smile.

It's very much doable, but the 1D texture changes make me wonder if those are admissible without adding a whole new GpuLanguage?

That would be the approach. And the new enum will act exactly as the OCIO::GPU_LANGUAGE_GLSL_4_0 one except for the 1D LUT. The latter seems only to 'adjust' the method GetLut1DGPUShaderProgram() to always request 2D Textures.