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

[Michel Dänzer]

On 24/01/17 07:38 PM, 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.

Some caveats:

While what you're describing should certainly be possible, I'm not sure
it's what currently happens with the amdgpu kernel driver. It's possible
that BOs are evicted from CPU visible VRAM to GTT instead of to CPU
invisible VRAM. Also, if a BO is currently in CPU invisible VRAM when
the CPU tries accessing it, and it can't be moved into CPU visible VRAM
(e.g. due to fragmentation caused by BOs which are pinned, either
permanently for scanout or temporarily for command stream execution),
it's migrated to GTT instead.

Anyway, the point is that the existence or absence of mappings per se
shouldn't affect the BO migration; only actual CPU access does.


Also note that BOs can currently only be migrated into CPU visible VRAM
as a whole for CPU access, i.e. the whole BO has to fit into a single
physically contiguous range of VRAM.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer