On Monday, June 23, 2014 07:02:59 PM Neil Roberts wrote: > Previously the blorp blitter would only be used if the format is identical or > there is only a difference between whether there is an alpha component or not. > This patch makes it also allow the blorp blitter if the only difference is the > ordering of the RGB components (ie, RGB or BGR). > > This is particularly useful since commit 61e264f4fcdba3623 because Mesa now > prefers RGB ordering for textures but the window system buffers are still > created as BGR. That means that the blorp blitter won't be used for the > (probably) common case of blitting from a texture to the window system buffer. > > This doesn't cause any regressions in the FBO piglit tests on Haswell. On > Sandybridge it causes the fbo-blit-stretch test to fail but that is only > because it was failing anyway before the above commit and that commit hid the > problem. > > https://bugs.freedesktop.org/show_bug.cgi?id=68365
FWIW, I relaxed the format restrictions in brw_blorp_copytexsubimage, so it can handle general format conversions as well (i.e. RGBA_FLOAT16 -> RGBA8888_UNORM). There's no reason we couldn't do that for BlitFramebuffer as well, I just forgot to do it (and then we decided to make it a newbie task, and then the newbie didn't do said task, and...oops.) A couple of games do BlitFramebuffer with format conversions, IIRC. I think DOTA 2 does 1010102 -> 8888 blits. --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
