[Mesa-dev] Status update of XvMC on R600

[Jerome Glisse]

2010/11/12 Younes Manton <younes.m at gmail.com>:
> 2010/11/12 Christian König <deathsimple at vodafone.de>:
>> 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.
>
> This is what PIPE_TRANSFER_DISCARD and PIPE_USAGE_DYNAMIC or
> PIPE_USAGE_STREAM were supposed to accomplish. DYNAMIC/STREAM for
> placing the texture in GPU-accessible system memory and DISCARD for
> allowing the driver to allocate and return new buffers if the one's
> being accessed are busy. Once upon a time they did that in nvfx, but I
> don't think it's been reimplemented since Nouveau went to TTM and
> gallium went to transfer objects.
>
>> What I need for the surface and ycrcb intermediate textures is a buffer
>> directly allocated in vram and never touched by the cpu.
>
> And this was the default placement for textures that were marked static.
>
>> So we can't just differentiate by vertex/texture buffer, but need to
>> look at the usage flags of those.
>
> From what I recall both helped a lot, especially for large videos
> where the CPU had a lot of data to generate per frame and buffers
> would be busy for longer. I haven't kept up with mesa lately so I
> don't know if there are new ways to deal with this, but I did run into
> both problems before on nvfx and there is value in dealing with them.
>

I think the flexibility we offer through relocation lead to fuzzy
placement which are less predictable thus doesn't allow userspace to
optimize properly bo placement. I don't have good answer on how to fix
that. To me it seems closed driver allow userspace to pick where
buffer is placed (GTT or VRAM) and also always honor those placement
(ie if driver is told bo is in vram bo will always be in vram) of
course this lead to more frequent vram bo allocation failure but hey
we can't pretend we have Gigs of vram when we only have few hundred
megs.

Cheers,
Jerome Glisse