What is the rationale behind the gallium-resources changes? I couldn't find any and I see several points that could be improved: 1. How does one do texture_blanket with the gallium-resources API? That is, how does one bind a buffer as a texture with a specific format? 2. Why is there a transfer_inline_write and not a transfer_inline_read? 3. How about adding a transfer_update_region that would copy data from the resource to the transfer, just like transfer_inline_write copies from the transfer to the resource? 4. How about making transfers be always mapped when alive and removing transfer_map and transfer_unmap?
In addition to these micro-level issues, is the bigger picture unification of buffers and textures as resources a good idea? It will burden all buffer operations with redundant notions of 3D boxes, strides, formats and texture targets. How about instead layering textures over buffers, and exposing the underlying buffer of a texture, maybe also allowing to dynamically change it? Then you could create a texture, asking the driver to create a buffer too, for the normal texture creation case. You could create a texture with a specified format and layout over an existing buffer to implement buffer-as-texture, or reinterpret the underyling buffer of an existing texture as another data format. You could also create a texture without an underlying buffer, to find out how large of a buffer you would need for that texture layout. (and whether it is supported). This could be useful for OpenGL texture proxies. For shared textures, you would call buffer_from_handle and then create a texture over it with the desired format/layout. Transfers can then be split in "texture transfers" and "buffer transfers". Note that they are often inherently different, since one often uses memcpy-like GPU functionality, and the other often uses 2D blitter or 3D engine functionality (and needs to worry about swizzling or tiling) Thus, they are probably better split and not unified. Furthermore, in the gallium-resource branch both r300g and nouveau drivers have different internal implementations for buffer and texture transfers (they actually look fundamentally different, not just duplicated code): why not just expose them directly as two separate, more efficient, interfaces, instead of going through a single fat interface, and then a further indirect branch in the driver? In addition transfers could be handled by an auxiliary module that would ask the driver to directly map the texture, and would otherwise create a temporary itself and use a driver-provided buffer_copy or surface_copy manually. Note that many drivers implement transfers this way and this would avoid duplicate code in drivers. transfer_inline_write can also be done by copies from user buffers, or textures layered over user buffers. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
