On 06.09.2010 22:03, Luca Barbieri wrote: >>> This way you could copy z24s8 to r8g8b8a8, for instance. > >> I am not sure this makes a lot of sense. There's no guarantee the bit >> layout of these is even remotely similar (and it likely won't be on any >> decent hardware). I think the dx10 restriction makes sense here. > > Yes, it depends on the flexibility of the hardware and the driver. > Due to depth textures, I think it is actually likely that you can > easily treat depth as color. > > The worst issue right now is that stencil cannot be accessed in a > sensible way at all, which makes implementing glBlitFramebuffer of > STENCIL_BIT with NEAREST and different rect sizes impossible. > Some cards (r600+ at least) can write stencil in shaders, but on some > you must reinterpret the surface. > And resource_copy_region does not support stretching, so it can't be used. > > Since not all cards can write stencil in shaders, one either needs to > be able to bind depth/stencil as a color buffer, or extend > resource_copy_region to support stretching with nearest filtering, or > both (possibly in addition to having the option of using stencil > export in shaders). Yes, accessing stencil is a problem - other apis just disallow that... There are other problems with accessing stencil, like for instance WritePixels with multisampled depth/stencil buffer (which you can't really map hence cpu fallbacks don't even work). Plus you really don't want any cpu fallbacks anyway. Using stencil export (ARB_shader_stencil_export) seems like a clean solution, but as you said not all cards support it. Plus you can't actually get the stencil values with texture sampling neither, so this doesn't help that much (well you can't get them with GL though hardware may support it I guess). When I said it won't work with decent hardware, I really meant it won't work due to compression. Now, it's quite possible this can be disabled on any chip, but you don't know that before hence you need to jump through hoops to get an uncompressed version of your compressed buffer later. Do applications actually really ever use blitframebuffer with stencil bit (with different sizes, otherwise resource_copy_region could be used)? It just seems to me that casts to completely different formats (well still with same total bitwidth, but still) are very unclean, but I don't have any good solution of how to solve this - if noone ever uses this in practice cpu fallback is just fine, but as said won't work for multisampled buffers for instance neither.
> > Other things would likely benefit, such as GL_NV_copy_depth_to_color. 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
