On 06.09.2010 15:57, José Fonseca 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 > 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
José, this looks good to me. Note that the analogous function in d3d10, ResourceCopyRegion, only requires formats to be in the same typeless group (hence same number of bits for all components), which is certainly a broader set of compatible formats to what util_is_format_compatible() is outputting. As far as I can tell, no conversion is happening at all in d3d10, this is just like memcpy. I think we might want to support that in the future as well, but for now extending this to the formats you listed certainly sounds ok. Roland ------------------------------------------------------------------------------ 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
