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

[Marek O. <ma...@gm...>]

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.

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.

Marek

 a8r8g8b8_unorm -> x8r8g8b8_unorm
>  b5g5r5a1_unorm -> b5g5r5x1_unorm
>  b4g4r4a4_unorm -> b4g4r4x4_unorm
>  l8_unorm -> r8_unorm
>  i8_unorm -> l8_unorm
>  i8_unorm -> a8_unorm
>  i8_unorm -> r8_unorm
>  l16_unorm -> r16_unorm
>  z24_unorm_s8_uscaled -> z24x8_unorm
>  s8_uscaled_z24_unorm -> x8z24_unorm
>  r8g8b8a8_unorm -> r8g8b8x8_unorm
>  a8b8g8r8_srgb -> x8b8g8r8_srgb
>  b8g8r8a8_srgb -> b8g8r8x8_srgb
>  a8r8g8b8_srgb -> x8r8g8b8_srgb
>  a8b8g8r8_unorm -> x8b8g8r8_unorm
>  r10g10b10a2_uscaled -> r10g10b10x2_uscaled
>  r10sg10sb10sa2u_norm -> r10g10b10x2_snorm
>
> Note that format compatibility is not commutative.
>
> For software drivers this means that memcpy/util_copy_rect() will
> achieve the correct result.
>
> For hardware drivers this means that a VRAM->VRAM 2D blit engine will
> also achieve the correct result.
>
> So I'd expect no implementation change of resource_copy_region() for any
> driver AFAICT. But I'd like to be sure.
>
> Jose
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
>