No, I said it would be better to use st_choose_matching_format in st_ChooseTextureFormat, because st_choose_matching_format does exactly what you're trying to do.
I have gone ahead and implemented what I had in mind. See the attached patch. Marek On Sat, Sep 28, 2013 at 8:45 AM, Wladimir <laa...@gmail.com> wrote: > 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/0c71bcf1c5cc06e26bfed7a72507555fe7e7ad97 > however 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 >
0001-st-mesa-improve-format-selection-for-GLES.patch
Description: Binary data
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
