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
diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst
index 8250c30..5342fc2 100644
--- a/src/gallium/docs/source/context.rst
+++ b/src/gallium/docs/source/context.rst
@@ -263,9 +263,11 @@ apart from any 3D state in the context. Blitting functionality may be
moved to a separate abstraction at some point in the future.
``resource_copy_region`` blits a region of a subresource of a resource to a
-region of another subresource of a resource, provided that both resources have the
-same format. The source and destination may be the same resource, but overlapping
-blits are not permitted.
+region of another subresource of a resource, provided that both resources have
+the same format, or compatible formats, i.e., 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. The source and destination
+may be the same resource, but overlapping blits are not permitted.
``resource_resolve`` resolves a multisampled resource into a non-multisampled
one. Formats and dimensions must match. This function must be present if a driver
------------------------------------------------------------------------------
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
