[Mesa-dev] [PATCH] gallium/radeon: add a new HUD query for the number of mapped buffers
Michel Dänzer
michel at daenzer.net
Fri Jan 27 02:21:49 UTC 2017
On 26/01/17 08:07 PM, Christian König wrote:
> Am 26.01.2017 um 12:01 schrieb Samuel Pitoiset:
>> On 01/26/2017 03:45 AM, Michel Dänzer wrote:
>>> On 25/01/17 11:19 PM, Samuel Pitoiset wrote:
>>>
>>>> I would like to approach the problem by reducing the amount of vram
>>>> needed by the userspace in order to prevent TTM to move lot of data...
>>>
>>> One thing that might help there is not trying to put any buffers in VRAM
>>> which will (likely) be accessed by the CPU and which are larger than say
>>> 1/4 the size of CPU visible VRAM. And maybe also keeping track of the
>>> total size of such buffers we're trying to put in VRAM, and stop when it
>>> exceeds say 3/4.
>>
>> That could be a solution yes. But maybe, we should also try to reduce
>> the number of mapped VRAM (for buffers mapped only once).
>
> For buffers mapped only once I suggest to just use a bouncing buffer in
> GART.
>
> BTW: What kind of allocations are we talking about here? From the
> application or driver internal allocations (e.g. shader code for example)?
That's a good point about shader code, actually — we do upload the
shader machine code by writing with the CPU directly to VRAM. This could
account for at least some of the large number of mappings Sam is seeing.
It should be relatively easy to unmap these buffers immediately after
the code is written (in si_shader_binary_upload).
Longer term, maybe we should consider doing this without writing to VRAM
with the CPU.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the mesa-dev
mailing list