On Mon, 2010-09-06 at 10:22 -0700, Marek Olšák wrote: > On Mon, Sep 6, 2010 at 3:57 PM, José Fonseca <jfons...@vmware.com> > 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 ------------------------------------------------------------------------------ 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
