Am 21.09.2016 um 17:25 schrieb Brian Paul: > From reading the code, it's not obvious what is src/dest compatible. > The list of a->b copy-compatible formats comes from Jose's original > check-in message, with some format name updates. > --- > src/gallium/auxiliary/util/u_format.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/src/gallium/auxiliary/util/u_format.c > b/src/gallium/auxiliary/util/u_format.c > index cbdb5ce..8881618 100644 > --- a/src/gallium/auxiliary/util/u_format.c > +++ b/src/gallium/auxiliary/util/u_format.c > @@ -457,6 +457,30 @@ util_format_write_4i(enum pipe_format format, > format_desc->pack_rgba_sint(dst_row, dst_stride, src_row, src_stride, w, > h); > } > > +/** > + * Check if we can safely memcopy from the source format to the dest format. > + * This basically covers the cases of a "used" channel copied to a typeless > + * channel, plus some 1-channel cases. > + * Examples of compatiblie copy formats include: compatible
> + * b8g8r8a8_unorm -> b8g8r8x8_unorm > + * 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_uint -> z24x8_unorm > + * s8_uint_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 > + */ > boolean > util_is_format_compatible(const struct util_format_description *src_desc, > const struct util_format_description *dst_desc) > Otherwise looks good to me. (Though I'm always thinking this doesn't really do the right thing, since you can't determine if formats are compatible with resource_copy_region as the unorm/uint/float etc. foramts aren't compatible here. But this is how it has to work for now...) Reviewed-by: Roland Scheidegger <srol...@vmware.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
