[Mesa-dev] Status update of XvMC on R600

[Jerome Glisse]

2010/11/11 Keith Whitwell <keithw at vmware.com>:
> There is still more to do there.  Currently r600g treats buffer and texture uploads separately, and I've only attempted to improve texture uploads.  Buffer is just as important however.
>
> The change needed is likely to be one of two:
> a) Allow newly created vertex buffers to be in the GTT domain, where they can be mapped cached.
> b) Provide a staging resource upload path (with the staging buffer in GTT domain).
>
> The latter will catch more cases and doesn't suffer from waits for the engine to go idle when accessing an in-use buffer.  The former is probably fastest for the cases where it works.
>
> Right now staged texture uploads use a 3d blit to copy from the staging resource to the final destination.  That probably won't work (directly at least) for buffer uploads as buffer dimensions (eg 64k by 1) mean they usually can't be bound as render targets.  So we need to jump through some hoops to get a hardware upload path in the absence of a DMA engine or 1d-blit.
>
> Keith

I am not sure on how gallium texture upload was ever supposed to be or
done, but from memory management point of view the idea i had was to
create all bo in GTT and let migrate them to VRAM once they are use,
eliminating any need for staging buffer. So it would be allocate bo,
memcpy to bo the content of the texture, use bo and set it as vram bo
so kernel migrate it to vram, that way you take advantage of kernel bo
move which should be faster than any blit helped move.

Anyway this was my initial thinking when doing the code.

Cheers,
Jerome Glisse