[Mesa-dev] 7 questions and proposals about changes in the Gallium interface

[Keith Whitwell]

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