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:
I was about to propose something like this. How about a much more powerful change though, that would make any pair of non-blocked format of the same bit depth compatible? This way you could copy z24s8 to r8g8b8a8, for instance. In addition to this, how about explicitly allowing sampler views to use a compatible format, and add the ability for surfaces to use a compatible format too? (with a new parameter to get_tex_surface) This would allow for instance to implement glBlitFramebuffer on stencil buffers by reinterpreting the buffer as r8g8b8a8, and allow the blitter module to copy depth/stencil buffers by simply treating them as color buffers. The only issue is that some drivers might hold depth/stencil surfaces in compressed formats that cannot be interpreted as a color format, and not have any mechanism for keeping temporaries or doing conversions internally. DirectX seems to have something like this with the _TYPELESS formats. ------------------------------------------------------------------------------ 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
