On Mon, 2011-03-07 at 18:52 +0100, Marek Olšák wrote: > > 6) Pixel buffer objects > > > > > > It woud be nice to have hardware-accelerated PBO copy in Gallium. > > > Would > > > resource_copy_region be a good candidate for this, where one of > the > > > arguments would be PIPE_BUFFER and the other one would be > > > PIPE_TEXTURE_*, or > > > am I missing something? > > > > Do you have a more concrete proposal? > > > > For me, it's always been a bit difficult to pin down what a PBO > really > > should map to either in hardware or gallium's abstraction of > hardware. > > Sometimes it's a long lived entity (eg. pipe_buffer), other times > it's > > just a transient object used for uploads - dma memory from a pool or > a > > pipe_transfer in gallium. > > > > But if there's a sensible addition to gallium that improves the > > situation, I'm all for it. > > > > A PBO to me is just a way to copy data between a buffer and a texture. > Two > cases may arise: > - The copy can be implemented using util_copy_rect (basically it's a > memcpy > with strides), in this case, resource_copy_region could be used to let > drivers do the copy in hardware. > - The copy cannot be implemented using util_copy_rect, in this case, > the > state tracker would use the current software implementation of PBOs. > > Again, another two cases may arise inside resource_copy_region: > - If the strides are well aligned, the copy can done in hardware. > (what is > "well aligned" is hardware-specific) > - If they are not, a util function similar to > util_resource_copy_region > could be used as a fallback. > > But then resource_copy_region needs to know the stride for the buffer > being > copied. New entrypoint maybe?
I don't have a problem with that if it's helpful. Maybe code something up to get a better idea of what works & what doesn't and post a patch? Unless anyone else has objections? Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev