Hello, Mareko and me had a small discussion about this on IRC.
Basically with GLES (1.0, 2.0 at least) the application has no way to control the exact internal format [1]. This is intentional give the hardware more leeway. See http://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml : "Internalformat specifies the internal format of the texture. Must be one of the following symbolic constants: GL_ALPHA, GL_LUMINANCE,GL_LUMINANCE_ALPHA, GL_RGB, GL_RGBA." The driver is free to choose the internal format based on these general categories. However, with the current implementation mesa doesn't do any special choosing for GLES. For one, GL_RGB is always converted to RGB8. This can result in needless format conversion. I was helping to optimize an application that makes a texture: glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGB, width = 256, height = 256, border = 0, format = GL_RGB, type = GL_UNSIGNED_SHORT_5_6_5, pixels = [binary data, size = 128 kb]) One of these textures is updated every frame. Every time, the image data is blown up to RGB8 because that's what the internal format became. This seems wasteful both of CPU/GPU time and memory. I proposed a crude patch that refines the internal format depending on the input data type (this happens after GLES input checking that format==internalFormat) https://github.com/laanwj/mesa/commit/0c71bcf1c5cc06e26bfed7a72507555fe7e7ad97however it doesn't take into account that the hardware may not support the specific formats. Mareko said it would be better to move the code to st_choose_matching_format inside the state tracker. This makes sense because the state tracker knows what formats are supported. Any other opinions on this? [1] there is an extension OES_required_internalformat which does give the application more control, but I'm describing behavior without this extension Wladimir
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
