[Mesa-dev] Status update of XvMC on R600

[Christian König]

Am Donnerstag, den 11.11.2010, 17:59 -0500 schrieb Jerome Glisse:
> 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.
At least for the video decoding case this sound like a bit to much
overhead. The XvMC implementation uses three kind of buffers:
1. surfaces, which are the render targets of the shaders and never
touched by the cpu altogether.
2. ycrcb textures, are one hit wonders, just used to move the colour
data from the cpu to the gpu and thrown away after one draw operation.
3. vertex buffers, also one hit wonders, tells the gpu what to render
where.

When we finally get the iDCT stage there would also be one or two more
intermediate buffers of ycrcb, but also not touched by the cpu
altogether.

What I need for both the ycrcb texture and vertex uploads is a buffer in
system memory, where the cpu access is fast and a function to tell the
gpu to upload this buffer to vram, so the cpu doesn't need to pump the
data over the system bus, wait for an "in use" buffer to get idle etc.

What I need for the surface and ycrcb intermediate textures is a buffer
directly allocated in vram and never touched by the cpu.

So we can't just differentiate by vertex/texture buffer, but need to
look at the usage flags of those. 

Am Freitag, den 12.11.2010, 11:48 +0000 schrieb Keith Whitwell:
> Doing these updates with DMAs means we don't have to wait for buffer
> idle before the update, which seems to be the most obvious current
> bottleneck in r600g for a lot of apps.
Totally agree with that, but after a quick overview of r600g I think its
a bit more complicated than I thought it would be and I won't be the guy
implementing this. But if you have anything to test or try out just let
me note.

Christian.