08:49 zzag: amdgpu limits cursor fb pitches to power of 2, i.e. 64, 128, and 256. is it a hardware restriction?
08:52 MrCooper: likely
08:52 MrCooper: the HW cursor supports some fixed PoT size(s) only
08:56 zzag: that's kind of inconvenient
12:48 haasn: Hmm, I have a nasty GPU hang that requires full system reboot to resolve
12:48 haasn: When running the test framework of my project (libplacebo)
12:54 haasn: actually it soft recovers now (after updating to latest mesa)
12:54 haasn: [Jan 4 13:52] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring comp_1.1.0 timeout, signaled seq=442, emitted seq=444
12:55 haasn: https://0x1.st/Ai.txt
12:55 haasn: this is the test that fails
12:57 haasn: Hmm it doesn’t always successfully recover
13:02 haasn: libvulkan_radeon 22.3.2-335.1
13:02 haasn: kernel 6.1.2-1-preempt
13:07 haasn: Issue still happens with mesa git master
13:19 haasn: Hmm, I tried bisecting it but even as far back as kernel 6.0.8, mesa 22.1.0 and libplacebo v4.208.0 it still happens :(
13:19 haasn: so it must be something else
13:19 haasn: oh, interesting
13:19 haasn: it's a regression in the vulkan validation layers
13:19 haasn: turning them off fixes it
13:19 haasn: ... huh
13:22 haasn: time to bisect them, I guess
13:46 haasn: I also sometimes get "[Jan 4 14:44] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but soft recovered" even on versions of vulkan-validationlayers that don't cause a hard crash
13:46 haasn: so strange
13:47 haasn: how do validation layers even cause a GPU hang
13:47 haasn: maybe because of shader debugging?
13:47 haasn: (they modify the spir-v)
14:13 haasn: Yeah turning off GPU-assisted validation fixes it
14:13 haasn: So bizarre
14:18 bnieuwenhuizen: is the bisected regression them enabling it, or something new?
14:18 bnieuwenhuizen: (or just stuff being so slow that we hit the timeout maybe?)
14:19 haasn: I couldn't bisect it because the commit that introduced the issue was hidden by another bug that prevents me from testing
14:20 haasn: bnieuwenhuizen: it's not inconceivable, what is the timeout?
14:20 bnieuwenhuizen: 10 sec or so?
14:20 haasn: actually it is quite inconceivable, because slower shaders execute fine
14:20 haasn: nah the normal execution time should be a few ms
14:20 haasn: at most
14:20 bnieuwenhuizen: ok
14:22 haasn: this is some sort of regression for sure because going back to vulkan validation layers sdk-1.3.224 fixes it
14:22 MrCooper: doesn't seem inconceivable that modifying spir-v could trigger issues
16:28 FireBurn: Hi, is there a way to increate the memory allocated to an APU when there's no option in the bios to do so. My renoir says: memory_size = 1 GB (512 MB) which is why I think it's going so slowly on Gravitymark
16:34 agd5f: FireBurn, it's all just system ram. The driver will use carve out and system ram interchangeably
16:44 FireBurn: Any idea why I get 0.6fps on Renoir when I get much faster on an old Raven machine. The whole system becomes really unresponsive too. It's a 5900HX with 64GB ram
16:45 FireBurn: Obviously everythign runs smoothly when I use the 6800M
16:45 FireBurn: But it's just strange it performs so dismally on the APU
19:58 gekret005: https://gitlab.freedesktop.org/drm/amd/-/issues/2310#note_1708437 how do I use cvt to do this I'm trying to run cvr -r 2880 1660 144 but it just says "ERROR: Multiple of 60Hz refresh rate required for reduced blanking."
20:00 gekret005: but overall is this really a hardware problem or an inadequate kernel message?
20:01 gekret005: You can't advertise 8K gaming like this!
20:25 agd5f: gekret005, looks like the bandwidth requirements are higher than the GPU can support
20:28 gekret005: agd5f: right so Aurabindo Pillai suggested that I should try adding a mode in reduced blanking which the cvt tool doesn't seem to support
20:32 agd5f: gekret005, I guess vesa only specifies reduced blanking modes in multiple of 60. You could still use the algorithm to calculate reduced blanking mode with non-multiples of 60, but you'd probably need to hack the tool to remove the check
20:33 gekret005: ok let me patch it out
20:33 agd5f: gekret005, https://tomverbeure.github.io/video_timings_calculator
20:34 agd5f: Modeline "2880x1600_143.99" 750.25 2880 2928 2960 3040 1600 1603 1613 1714 +HSync -VSync
20:34 agd5f: Modeline "2880x1600_144" 730.575 2880 2888 2920 2960 1600 1700 1708 1714 +HSync -VSync
20:47 Venemo: agd5f: ping again on the clock issue - do you have the HW to reproduce that issue or do you need our help with it?
20:49 gekret005: agd5f: so I ran "xrandr --newmode "2880x1600_144" 730.575 2880 2888 2920 2960 1600 1700 1708 1714 +HSync -VSync" and then "xrandr --addmode DisplayPort-2 "2880x1600_144"" and lastly "xrandr --output DisplayPort-2 --mode 2880x1600_144" but I the headset just turns off
20:50 gekret005: I already set it as a desktop display and it does work on the original mode
20:51 gekret005: did I mess the command up or is this just adding to the problem deduction?
20:53 gekret005: I'm going to add this to the gitlab
21:51 agd5f: Venemo, I don't think we have any of the problematic boards in house
21:51 agd5f: but I can check with the hardware library and see if they have any of them we could check out
22:55 Venemo: agd5f: okay, if you don't have it how do we move forward with this?
22:56 agd5f: Venemo, I don't know. I don't have a good solution
22:57 Venemo: mhm