Mesa 12.1.0 on ChromeOS (Chromebook Pixel 2015, Broadwell GT2) doesn't support R8 image texture. GL version is OpenGL ES 3.1 Mesa 12.1.9-devel (git-b010fa8) Following chromium code requires R8 image texture binding. https://cs.chromium.org/chromium/src/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc?sq=package:chromium&rcl=1477653611&l=96 In detail, 1. image texture binding > GLuint r8_texture = 0; glGenTextures(1, &r8_texture); glBindTexture(GL_TEXTURE_2D, r8_texture); glTexStorage2DEXT(GL_TEXTURE_2D, 1, GL_R8, 4, 4); glBindTexture(GL_TEXTURE_2D, 0); glBindImageTextureEXT(0, r8_texture, 0, GL_FALSE, 0, GL_WRITE_ONLY, GL_R8); glGetError(); // emit INVALID_ENUM 2. r8 in GLSL const char shader_source[] = SHADER(#version 310 es layout(binding = 0, r8) restrict writeonly uniform highp image2D g_r8Image; void main() { imageStore(g_r8Image, ivec2(0, 0), vec4(1.0, 0.0, 0.0, 0.0)); }); GLuint shader = glCreateShader(GL_FRAGMENT_SHADER); glCompileShader(shader); glShaderSource(shader, 1, &shader_source, NULL); // compile fails with following error // error: unrecognized layout identifier `r8'
According to the OpenGL ES Shading Language spec 3.10, section 4.4, the layout qualifier r8 doesn't seem to be supported. I'm afraid you'll have to bump the profile.
Ah, I didn't know that. You are right. glBindImageTexture in ES 3.1 doesn't support R8 https://www.khronos.org/opengles/sdk/docs/man31/html/glBindImageTexture.xhtml glBindImageTexture in GL 4.2 support R8 tho https://www.opengl.org/sdk/docs/man4/html/glBindImageTexture.xhtml Will ES support R8 image texture in the future as extensions or upper version?
It's not in the 3.20 spec. I don't know beyond that.
There's a GL_NV_image_formats but it's not implemented by Mesa. Should be easy enough to add though.
That's right. GL_NV_image_formats is sufficient to speed up ChromeOS. Could someone take a ownership this issue?
FYI, I'm looking at adding the extension. Will post a link to the patches here.
We should take some care with this. The set of required image formats selected for OpenGL ES 3.1 were picked specifically because they matched the set required by DX. This set should be natively supported by all hardware. This avoids the need for state-based recompiles. A number of the formats required by desktop OpenGL involve a significant amount of pain in shaders and state-based recompiles. I'd be reluctant to expose those formats on OpenGL ES unless there is clear and significant need for those formats. That said, R8 is not one of the painful formats. Aside from possibly R11F_G11F_B10F, I'm pretty sure none of the added formats are on the pain list either. Before committing to adding this specific extension, we should double check the list of added formats against the list of pain-free formats.
ChromeOS uses GL ES 3.1 and needs R8 and RG8 support, because 1. Chromium has its own CMAA implementation and R8 support is critical. https://www.opengl.org/registry/specs/INTEL/framebuffer_CMAA.txt 2. Chromium uses R8 and RG8 to draw YUV video by itself. NV_image_formats supports too many formats, although it's GLES extension. If some formats cause lots of pain, I hope new extension which is subset of NV_image_formats, is added. https://www.khronos.org/registry/gles/extensions/NV/NV_image_formats.txt
Hi Lionel-Any update here? Thanks.
Just got some review feedback on the piglit tests : https://patchwork.freedesktop.org/series/15026/ Also have a couple of Mesa patches that don't seem to break our CI : https://github.com/djdeath/mesa/commits/NV_image_formats
Mesa patches: https://patchwork.freedesktop.org/series/15174/ Piglit: https://patchwork.freedesktop.org/series/15173/
Lionel-Are you awaiting more feedback with these new patches?
(In reply to Annie from comment #12) > Lionel-Are you awaiting more feedback with these new patches? I just got the reviewed-by for the Mesa patch, I'll land this today. Still waiting for the additional piglit one.
Hi Lionel, Any update on this? Thanks!
All done!
Nice! Thank you!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.