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

[Samuel Pitoiset]

On 01/24/2017 11:38 AM, Nicolai Hähnle wrote:
> On 24.01.2017 11:34, Samuel Pitoiset wrote:
>>
>>
>> On 01/24/2017 11:31 AM, Nicolai Hähnle wrote:
>>> On 24.01.2017 11:25, Samuel Pitoiset wrote:
>>>> On 01/24/2017 07:39 AM, Michel Dänzer wrote:
>>>>> On 24/01/17 05:44 AM, Samuel Pitoiset wrote:
>>>>>> Useful when debugging applications which map too much VRAM.
>>>>>
>>>>> Is the number of mapped buffers really useful, as opposed to the total
>>>>> size of buffer mappings? Even if it was the latter though, it doesn't
>>>>> show which mappings are for BOs in VRAM vs GTT, does it? Also, even
>>>>> the
>>>>> total size of mappings of BOs currently in VRAM doesn't directly
>>>>> reflect
>>>>> the pressure on the CPU visible part of VRAM — only the BOs which are
>>>>> actively being accessed by the CPU contribute to that.
>>>>
>>>> It's actually useful to know the number of mapped buffers, but maybe it
>>>> would be better to have two separate counters for GTT and VRAM.
>>>> Although
>>>> the number of mapped buffers in VRAM is most of the time very high
>>>> compared to GTT AFAIK.
>>>>
>>>> I will submit in a follow-up patch, something which reduces the number
>>>> of mapped buffers in VRAM (when a BO has been mapped only once). And
>>>> this new counter helped me.
>>>
>>> Michel's point probably means that reducing the number/size of mapped
>>> VRAM buffers isn't actually that important though.
>>
>> It seems useful for apps which map more than 256MB of VRAM.
>
> True, if all of that range is actually used by the CPU (which may well
> happen, of course). If I understand Michel correctly (and this was news
> to me as well), if 1GB of VRAM is mapped, but only 64MB of that are
> regularly accessed by the CPU, then the kernel will migrate all of the
> rest into non-visible VRAM.

And this can hurt us, for example DXMD maps over 500MB of VRAM. And a 
bunch of BOs are only mapped once.

>
> Nicolai