| Priority | medium |
|---|---|
| Bug ID | 82050 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | R9270X pyrit benchmark perf regressions with latest kernel/llvm |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | adf.lists@gmail.com |
| Hardware | Other |
| Status | NEW |
| Version | git |
| Component | Drivers/Gallium/radeonsi |
| Product | Mesa |
Don't really have time to bisect this but posting FYI. Maybe pyrit benchmark is the glxgears of benchmarks - if so please say so and I'll ignore it :-) Status Que for my R9 270X pyrit 0.3.0 since I got it in May has been around - Computed 75761.96 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 73256.9 PMKs/s (RTT 0.8) #2: 'CPU-Core (SSE2)': 743.3 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 741.3 PMKs/s (RTT 2.8) #4: 'CPU-Core (SSE2)': 740.2 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) This was kernel agd5f drm-fixes-3.16-wip I noticed yesterday after trying agd5f drm-next-3.17-rebased-on-fixes that I lost around 10,000 PMKs/s with the newer kernel. Both were with yesterdays mesa but llvm was older say a couple of weeks. Updated llvm and mesa today and it's regressed more on both kernels - drm-fixes-3.16-wip Computed 58233.89 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 56076.6 PMKs/s (RTT 1.1) #2: 'CPU-Core (SSE2)': 753.6 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 754.5 PMKs/s (RTT 2.9) #4: 'CPU-Core (SSE2)': 753.0 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) drm-next-3.17-rebased-on-fixes Computed 52379.38 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 48822.1 PMKs/s (RTT 1.2) #2: 'CPU-Core (SSE2)': 753.8 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 754.9 PMKs/s (RTT 3.0) #4: 'CPU-Core (SSE2)': 754.8 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0)
There was a recent change to LLVM which increased conformance = with OpenCL floating point semantics at some performance cost. That might explain at le= ast some of the difference.
(In reply to comment #2) > There was a recent change to LLVM which increased conformance with OpenCL > floating point semantics at some performance cost. That might explain at > least some of the difference. Pyrit doesn't use any floating-point operations, so this shouldn't be an issue.
I bisected LLVM and it came up with - ph4[llvm]$ git bisect good ee17bf3fd4189d1981a6e908b4519e600ec7b002 is the first bad commit commit ee17bf3fd4189d1981a6e908b4519e600ec7b002 Author: Matt Arsenault <Matthew.Arsenault@amd.com> Date: Fri Jul 25 23:02:42 2014 +0000 R600/SI: Allow partial unrolling and increase thresholds. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213985 91177308-0d34-0410-b5e6-96231b3b80d8 I don't know when I'll get to do kernel yet.
Can you post the output of R600_DEBUG=cs from both the "good" and "bad" commits?
kernel - fb240a2534802a86742db51b7334138675bc435e is the first bad commit commit fb240a2534802a86742db51b7334138675bc435e Author: Michel D=C3=A4nzer <michel.daenzer@amd.com> Date: Thu Jul 31 18:43:49 2014 +0900 drm/radeon: Always flush the HDP cache before submitting a CS to the GPU This ensures the GPU sees all previous CPU writes to VRAM, which makes = it safe: * For userspace to stream data from CPU to GPU via VRAM instead of GTT * For IBs to be stored in VRAM instead of GTT * For ring buffers to be stored in VRAM instead of GTT, if the HPD flush is performed via MMIO Signed-off-by: Michel D=C3=A4nzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Created attac= hment 104475 [details] [revi= ew] Flush HDP cache via the ring on SI Does this patch help for the kernel regression? Though this seems to make some piglit test results unstable...
(In reply to comment #9) > Created attachment 104475 [details] [review] [review] > Flush HDP cache via the ring on SI > > Does this patch help for the kernel regression? > > Though this seems to make some piglit test results unstable... There is no difference with this. FWIW I found another regression with this kernel that is caused by the same commit. Maybe regression is the wrong word, as there was already an issue, just it's worse now. I will file a separate bug in time (was planning to do new xorg and retest first) but in summary - Unigine Valley always did have some 1/2 to 1 sec pauses ever since I could run it, first on HD4890 and now radeonsi R9 270X. Since this kernel commit they are 2 to 4 times longer - also unchanged by patch. Strangely, if I use ffmpegs x11 grab to make a recording @ 30fps they become short again.
| What | Removed | Added |
|---|---|---|
| Attachment #104475 is obsolete | 1 |
Created attachment 104549 [details]
Only flush HDP cache for indirect buffers from userspace
Does this patch help?
(In reply to comment #11) > Created attachment 104549 [details] > Only flush HDP cache for indirect buffers from userspace > > Does this patch help? No, I'm afraid that doesn't help either. Valley is the same - pyrit only slightly different, probably within random variation. I am testing with "bad" llvm so the numbers are all low. As I recorded them here's a paste of pyrit good (kernel), head, patch 1 and patch 2 On good - Running benchmark (57982.3 PMKs/s)... / Computed 58917.21 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 55101.4 PMKs/s (RTT 1.1) #2: 'CPU-Core (SSE2)': 757.2 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 756.0 PMKs/s (RTT 3.0) #4: 'CPU-Core (SSE2)': 755.5 PMKs/s (RTT 2.8) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) On head Running benchmark (50267.7 PMKs/s)... \ Computed 50096.30 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 48501.1 PMKs/s (RTT 1.2) #2: 'CPU-Core (SSE2)': 757.5 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 757.1 PMKs/s (RTT 2.9) #4: 'CPU-Core (SSE2)': 757.0 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) Head + patch one Running benchmark (50883.7 PMKs/s)... - Computed 51220.59 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 48583.5 PMKs/s (RTT 1.2) #2: 'CPU-Core (SSE2)': 756.5 PMKs/s (RTT 3.0) #3: 'CPU-Core (SSE2)': 756.0 PMKs/s (RTT 2.9) #4: 'CPU-Core (SSE2)': 754.2 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) Head + patch two Running benchmark (51348.9 PMKs/s)... | Computed 50781.53 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 48676.9 PMKs/s (RTT 1.2) #2: 'CPU-Core (SSE2)': 752.4 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 755.4 PMKs/s (RTT 2.9) #4: 'CPU-Core (SSE2)': 752.8 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0)
Does reverting Mesa commit 150ac07b855b5c5f879bf6ce9ca421ccd1a= 6c938 help for Valley or pyrit with the latest kernel?
(In reply to comment #13) > Does reverting Mesa commit 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 help for > Valley or pyrit with the latest kernel? Yes, with that reverted perf is roughly back to "good" kernel for both.
Does pyrit transfer much data from the GPU to the CPU? If so, my patch "gallium/radeon: Do not use u_upload_mgr for buffer downloads" that I have just sent to the mesa-dev mailing list might help...
(In reply to comment #15) > Does pyrit transfer much data from the GPU to the CPU? If so, my patch > "gallium/radeon: Do not use u_upload_mgr for buffer downloads" that I have > just sent to the mesa-dev mailing list might help... It does help pyrit, but as expected I guess, not valley.
(In reply to comment #= 14) > Yes, with that reverted perf is roughly back to = "good" kernel for both. Can you try restoring the old behaviour for only PIPE_USAGE_DYNAMIC or PIPE_USAGE_STREAM respectively, to see if one of them alone fixes the probl= em in Valley?
Does the pyrit benchmark include compile time when calculating PMKs/s ? The patch you've bisected unrolls a loop that makes the pyrit kernel really big, so it will take longer to compile. Is it possible to run the benchmark for longer? If so, does the gap between good and bad shrink?
(In reply to comment #17) > (In reply to comment #14) > > Yes, with that reverted perf is roughly back to "good" kernel for both. > > Can you try restoring the old behaviour for only PIPE_USAGE_DYNAMIC or > PIPE_USAGE_STREAM respectively, to see if one of them alone fixes the > problem in Valley? Stream as below gets the old behavior, doing below with dynamic makes no difference AFAICT. Testing this is subjective as the pauses stop the clock in benchmark mode, so don't show and of course "working" is still somewhat broken :-). diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c b/src/gallium/drivers/radeon/r600_buffer_common.c index 22bc97e..9262823 100644 --- a/src/gallium/drivers/radeon/r600_buffer_common.c +++ b/src/gallium/drivers/radeon/r600_buffer_common.c @@ -110,11 +110,12 @@ bool r600_init_resource(struct r600_common_screen *rscreen, enum radeon_bo_flag flags = 0; switch (res->b.b.usage) { + case PIPE_USAGE_STREAM: + flags = RADEON_FLAG_GTT_WC; case PIPE_USAGE_STAGING: /* Transfers are likely to occur more often with these resources. */ res->domains = RADEON_DOMAIN_GTT; break; - case PIPE_USAGE_STREAM: case PIPE_USAGE_DYNAMIC: /* Older kernels didn't always flush the HDP cache before * CS execution
(In reply to comment #18) > Does the pyrit benchmark include compile time when calculating PMKs/s ? The > patch you've bisected unrolls a loop that makes the pyrit kernel really big, > so it will take longer to compile. > > Is it possible to run the benchmark for longer? If so, does the gap between > good and bad shrink? It runs for 1min 16s as is, TBH I don't use/know pyrit - the only reason I have it is when I got my radeonsi and was reading how to get opencl there was a link to it as an example of a working app in the wiki. It does seem to build up speed as time progresses, but now it's slower it seems to plateau slightly longer before the end than it used to. Maybe it's just not a representative test - hence my query about glxgears, I haven't found any "real" opencl use to benchmark yet - x264 would be nice, but it seems it needs things not yet implemented.
Created attachment 105316 [deta= ils] [review] drm/ttm: move fpfn and lpfn into each placement