Re: [Mesa3d-dev] RFC: allow resource_copy_region between different (yet compatabile) formats

[José F. <jfo...@vm...>]

On Mon, 2010-09-06 at 10:22 -0700, Marek Olšák wrote:
> On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca <jfo...@vm...>
> wrote:
>         I'd like to know if there's any objection to change the
>         resource_copy_region semantics to allow copies between
>         different yet
>         compatible formats, where the definition of compatible formats
>         is:
>         
>          "formats for which copying the bytes from the source resource
>         unmodified to the destination resource will achieve the same
>         effect of a
>         textured quad blitter"
>         
>         There is an helper function util_is_format_compatible() to
>         help making
>         this decision, and these are the non-trivial conversions that
>         this
>         function currently recognizes, (which was produced by
>         u_format_compatible_test.c):
>         
>          b8g8r8a8_unorm -> b8g8r8x8_unorm
> 
> This specific case (and others) might not work, because there are no
> 0/1 swizzles when blending pixels with the framebuffer, e.g. see this
> sequence of operations:
> - Blit from b8g8r8a8 to b8g8r8x8.
> - x8 now contains a8.
> - Bind b8g8r8x8 as a colorbuffer.
> - Use blending with the destination alpha channel.
> - The original a8 is read instead of 1 (x8) because of lack of
> swizzles.

This is not correct. Or at least not my interpretation.

The x in b8g8r8x8 means padding (potentially with with unitialized
data). There is no implicit guarantee that it will contain 0xff or
anything.

When blending to b8g8r8x8, destination alpha is by definition 1.0. It is
an implicit swizzle (see e.g., u_format.csv).

If the hardware's fixed function blending doesn't understand bgrx
formats natively, then the pipe driver should internally replace the
destination alpha factor factor with one. It's really simple. See for
example llvmpipe (which needs to do that because the swizzled tile
format is always bgra, so it needs to ignore destination alpha when bgrx
surface is bound).

I'm not sure what OpenGL defines, but DirectX/DCT definetely
prescribes/enforces this behavior.

> The blitter and other util functions just need to be extended to
> explicitly write 1 instead of copying the alpha channel. Something
> likes this is already done in st/mesa, see the function
> compatible_src_dst_formats.

There is no alpha channel in b8g8r8x8 for anybody to write. The problem
here is not what's written in the padding bits -- it is instead in
making sure the padding bits are not interpreted as alpha.

If the hardware *really* works better with 0xff in the padding bits,
then that needs to be enforced not only in surface copy, but in
transfers (i.e., when the transfer is unmapped, the pipe driver would
need to fill padding bits with 0xff for every pixel.

Jose