[Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Am 12.02.2019 03:22, schrieb Dieter Nützel:
> Am 12.02.2019 00:40, schrieb Dieter Nützel:
>> Sorry that I step in so late, but the whole family recover slowly from
>> a bad flu...
>> 
>> Tried your 'latest" three series altogether with my Polaris 20 (NIR!).
>> UH and UV hang after some seconds reliable. VM faults. Have to dig
>> deeper in (remote) to get some logs.
> 
> UH
> 
> [47001.185090] amdgpu 0000:01:00.0: GPU fault detected: 147 0x0b384801
> for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586
> [47001.185094] amdgpu 0000:01:00.0:
> VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0373EF67
> [47001.185096] amdgpu 0000:01:00.0:
> VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001
> [47001.185098] amdgpu 0000:01:00.0: VM fault (0x01, vmid 3, pasid
> 32786) at page 57929575, read from 'TC4' (0x54433400) (72)
> [47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
> timeout, signaled seq=11380701, emitted seq=11380703
> [47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process
> information: process  pid 0 thread  pid 0
> [47011.401787] amdgpu 0000:01:00.0: GPU reset begin!
> [47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR*
> [CRTC:49:crtc-0] hw_done or flip_done timed out

These GPU faults are SOLVED after reverting the SDMA (1-4) series.

>> But my reported Polaris triangle corruptions are solved, now.

These reported (last year) triangle corruptions are SOLVED _before_ all 
of these patches. GREAT!

>> W'll try to verify which patches fixed it.

If I have more time then I'll try to find the corresponding patch/fix.

Cheers,
Dieter

>> Look here:
>> https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1079319-running-the-radeonsi-nir-back-end-with-mesa-19-1-git?p=1079390#post1079390
>> 
>> Greetings,
>> Dieter
>> 
>> Am 07.02.2019 02:21, schrieb Marek Olšák:
>>> Hi,
>>> 
>>> This patch series increases radeonsi performance in some cases.
>>> glxgears performance decreases slightly.
>>> 
>>> Visible VRAM is usually congested due to CPU accesses, which cause
>>> buffers to be evicted from that part of VRAM. This removes
>>> the congestion for all data pushed into const_uploader.
>>> 
>>> We have had many problems with const_uploader slowing stuff down due
>>> to visible VRAM congestion. The most recent one is this Starcraft 2
>>> issue report on github:
>>> 
>>> https://github.com/iXit/Mesa-3D/issues/333
>>> 
>>> Since const_uploader reuses buffers from the winsys buffer cache,
>>> the odds are that the reused buffers are already evicted, so the 
>>> first
>>> use is usually slower due to higher shader load latencies.
>>> 
>>> This series uses SDMA to get constants into VRAM, so it doesn't have
>>> any of the above drawbacks.
>>> 
>>> SC2 numbers with various other methods (from the github issue 
>>> report):
>>> - originally: 50-55 fps
>>> - changing const_uploader to STREAM: 75-80 fps
>>> - use stream_uploader for constants in Nine: 90 fps
>>> - this series: 105-110 fps
>>> 
>>> Trivial benchmarks such as glxgears can expect 20% decrease
>>> in performance due to the added cost of the SDMA CS ioctl that wasn't
>>> there before.
>>> 
>>> CPU-bound apps with many IBs are almost unaffected thanks to winsys
>>> multithreading.
>>> 
>>> Feedback welcome,
>>> 
>>> Thanks,
>>> Marek
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev