[Mesa-dev] Choosing texture internal format in GLES
Wladimir
laanwj at gmail.com
Fri Sep 27 23:45:04 PDT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130928/43196899/attachment.html>
More information about the mesa-dev
mailing list