[Mesa-dev] Help! CopyImageSubData is defeating me

Marek Olšák maraeo at gmail.com
Mon Jun 26 20:36:13 UTC 2017


There are 2 solutions:
1) Don't support RGBA4.
2) Don't promote GL_RGBA4 to GL_RGBA8.

Marek

On Sun, Jun 25, 2017 at 10:20 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> I was hoping I could solicit some ideas from the group.
>
> As you're likely aware, CopyImageSubData supports copying between a
> texture and a renderbuffer that were created with sized formats.
>
> NVIDIA hardware supports texturing from BGRA4 but not rendering to it.
> So when a renderbuffer is created, st/mesa automatically chooses BGRA8
> as the TexFormat, while maintaining the "official" internal format of
> GL_RGBA4. However a texture created with that internal format would
> get a BGRA4 TexFormat (and then fail to render to if attached to a
> framebuffer).
>
> The issue I'm running into is when someone tries to do a
> CopyImageSubData between two such items -- while the GL-level internal
> format matches, which means that the copy must be supported, the
> "real" internal format differs by more than just component order.
> (There's a CTS test for this, probably dEQP too.)
>
> So, assuming I don't want to drop BGRA4 texturing support from
> nouveau, what are my options? I basically have to do a blit between
> the two, while preserving component order. (I can't see any other
> way.) st/mesa would be the natural place to have something like this.
> However handling the full set of possibilities is pretty daunting. I'm
> thinking that it should be easier to deal with a reduced set of
> possibilities that one is likely to run into in real life.
>
> Anyone have thoughts on this? Am I being foolish for trying to hold
> onto GL_RGBA4 texturing? (Any decision here also affects st/nine.)
>
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list