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

Reply via email to