<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 27, 2017 9:35 AM, "Michel Dänzer" <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On 25/03/17 01:33 AM, Marek Olšák wrote:<br>
> Hi,<br>
><br>
> I'm sharing this idea here, because it's something that has been<br>
> decreasing our performance a lot recently, for example:<br>
> <a href="http://openbenchmarking.org/prospect/1703011-RI-RADEONDIR06/7b7668cfc109d1c3dc27e871c8aea71ca13f23fa" rel="noreferrer" target="_blank">http://openbenchmarking.org/<wbr>prospect/1703011-RI-<wbr>RADEONDIR06/<wbr>7b7668cfc109d1c3dc27e871c8aea7<wbr>1ca13f23fa</a><br>
><br>
> I think the problem there is that Mesa git started uploading<br>
> descriptors and uniforms to VRAM, which helps when TC L2 has a low<br>
> hit/miss ratio, but the performance can randomly drop by an order of<br>
> magnitude. I've heard rumours that kernel 4.11 has an improved<br>
> allocator that should perform better, but the situation is still far<br>
> from ideal.<br>
><br>
> AMD CPUs and APUs will hopefully suffer less, because we can resize<br>
> the visible VRAM with the help of our CPU hw specs, but Intel CPUs<br>
> will remain limited to 256 MB. The following plan describes how to do<br>
> throttling for visible VRAM evictions.<br>
><br>
><br>
> 1) Theory<br>
><br>
> Initially, the driver doesn't care about where buffers are in VRAM,<br>
> because VRAM buffers are only moved to visible VRAM on CPU page faults<br>
> (when the CPU touches the buffer memory but the memory is in the<br>
> invisible part of VRAM). When it happens,<br>
> amdgpu_bo_fault_reserve_notify is called, which moves the buffer to<br>
> visible VRAM, and the app continues. amdgpu_bo_fault_reserve_notify<br>
> also marks the buffer as contiguous, which makes memory fragmentation<br>
> worse.<br>
><br>
> I verified this with DiRT Rally where amdgpu_bo_fault_reserve_notify<br>
> was much higher in a CPU profiler than anything else in the kernel.<br>
><br>
><br>
> 2) Monitoring via Gallium HUD<br>
><br>
> We need to expose 2 kernel counters via the INFO ioctl and display<br>
> those via Gallium HUD:<br>
> - The number of VRAM CPU page faults. (the number of calls to<br>
> amdgpu_bo_fault_reserve_<wbr>notify).<br>
> - The number of bytes moved by ttm_bo_validate inside<br>
> amdgpu_bo_fault_reserve_<wbr>notify.<br>
><br>
> This will help us observe what exactly is happening and fine-tune the<br>
> throttling when it's done.<br>
><br>
><br>
> 3) Solution<br>
><br>
> a) When amdgpu_bo_fault_reserve_notify is called, record the fact.<br>
> (amdgpu_bo::had_cpu_page_fault = true)<br>
><br>
> b) Monitor the MB/s rate at which buffers are moved by<br>
> amdgpu_bo_fault_reserve_<wbr>notify. If we get above a specific threshold,<br>
> don't move the buffer to visible VRAM. Move it to GTT instead. Note<br>
> that moving to GTT can be cheaper, because moving to visible VRAM is<br>
> likely to evict a lot of buffers there and unmap them from the CPU,<br>
<br>
</div>FWIW, this can be avoided by only setting GTT in busy_placement. Then<br>
TTM will only move the BO to visible VRAM if that can be done without<br>
evicting anything from there.<br>
<div class="quoted-text"><br>
<br>
> but moving to GTT shouldn't evict or unmap anything.<br>
><br>
> c) When we get into the CS ioctl and a buffer has had_cpu_page_fault,<br>
> it can be moved to VRAM if:<br>
> - the GTT->VRAM move rate is low enough to allow it (this is the<br>
> existing throttling mechanism)<br>
> - the visible VRAM move rate is low enough that we will be OK with<br>
> another CPU page fault if it happens.<br>
<br>
</div>Some other ideas that might be worth trying:<br>
<br>
Evicting BOs to GTT instead of moving them to CPU accessible VRAM in<br>
principle in some cases (e.g. for all BOs except those with<br>
AMDGPU_GEM_CREATE_CPU_ACCESS_<wbr>REQUIRED) or even always.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I've tried this and it made things even worse.</div><div dir="auto"><br></div><div dir="auto">Marek</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Implementing eviction from CPU visible to CPU invisible VRAM, similar to<br>
how it's done in radeon. Note that there's potential for userspace<br>
triggering an infinite loop in the kernel in cases where BOs are moved<br>
back from invisible to visible VRAM on page faults.<br>
<font color="#888888"><br>
<br>
--<br>
Earthling Michel Dänzer               |               <a href="http://www.amd.com" rel="noreferrer" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
<br>
</font></blockquote></div><br></div></div></div>