[Mesa-dev] Help! CopyImageSubData is defeating me

[Jason Ekstrand]

On June 25, 2017 1:21:33 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.)

Yes.  Chances are that you're also doing texture views wrong.  Are there 
any 4444 formats supported on nvidia hardware?  One thing we do in Vulkan 
is to fake certain formats with others that have the same bit layout but a 
different channel order and then just swizzle behind the client's back.

--Jason