Bug 98480 - Support R8 image texture in ES 3.1
Summary: Support R8 image texture in ES 3.1
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: 12.0
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Lionel Landwerlin
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-28 18:34 UTC by Dongseong Hwang
Modified: 2016-11-29 05:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dongseong Hwang 2016-10-28 18:34:51 UTC
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'
Comment 1 Lionel Landwerlin 2016-10-28 18:48:49 UTC
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.
Comment 2 Dongseong Hwang 2016-10-28 19:03:07 UTC
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?
Comment 3 Lionel Landwerlin 2016-10-28 19:06:32 UTC
It's not in the 3.20 spec. I don't know beyond that.
Comment 4 Ilia Mirkin 2016-11-02 00:01:51 UTC
There's a GL_NV_image_formats but it's not implemented by Mesa. Should be easy enough to add though.
Comment 5 Dongseong Hwang 2016-11-02 12:49:26 UTC
That's right. GL_NV_image_formats is sufficient to speed up ChromeOS. Could someone take a ownership this issue?
Comment 6 Lionel Landwerlin 2016-11-03 15:59:07 UTC
FYI, I'm looking at adding the extension.
Will post a link to the patches here.
Comment 7 Ian Romanick 2016-11-04 14:54:47 UTC
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.
Comment 8 Dongseong Hwang 2016-11-04 15:21:27 UTC
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
Comment 9 Annie 2016-11-09 18:48:58 UTC
Hi Lionel-Any update here? Thanks.
Comment 10 Lionel Landwerlin 2016-11-10 10:32:49 UTC
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
Comment 12 Annie 2016-11-17 19:44:37 UTC
Lionel-Are you awaiting more feedback with these new patches?
Comment 13 Lionel Landwerlin 2016-11-18 11:47:09 UTC
(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.
Comment 14 Annie 2016-11-22 21:11:53 UTC
Hi Lionel,
Any update on this?
Thanks!
Comment 15 Lionel Landwerlin 2016-11-23 11:36:37 UTC
All done!
Comment 16 Annie 2016-11-29 05:25:48 UTC
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.