[Mesa-dev] [PATCH] gallium/radeon: add a new HUD query for the number of mapped buffers

[Samuel Pitoiset]

On 01/27/2017 03:21 AM, Michel Dänzer wrote:
> 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).

si_shader_binary_upload() already unmaps these buffers (ie. it calls the 
buffer_unmap() winsys function).

>
> Longer term, maybe we should consider doing this without writing to VRAM
> with the CPU.
>
>