20:30 gekret005: agd5f: 6.1.12 do I need 6.1.13 or 6.2 for this to work smoothly? Also S/G display meaning what exactly?
20:32 agd5f: S/G = Scatter/Gather display = display from non-contiguous system memory
20:35 gekret005: is this set in bios or in the kernel config, I'm using opensuse, and this is what they have for their config https://0x0.st/HsfJ.12-1-def
20:37 agd5f: driver change
20:41 agd5f: gekret005, looks like the fix has not made it make to 6.1.x yet. Need to revert this change for 6.1.x (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?h=linux-6.1.y&id=3ad10fc4ad37be5adfb02f6d493d092dec9b4c55) or use 6.2
20:50 gekret005: actually I think the problem was in my testing I had monitors attached to both gpus
20:50 gekret005: unplugging the monitor from my dgpu makes everything responsive on the idpu with DRI_PRIME=1
20:54 gekret005: I'll retest this on 6.2, but I didn't plan on having outputs driven from the 7900xtx
21:30 gekret005: Ok so on 6.2 just like 6.1.12 applications run with DRI_PRIME=1 can become latent when outputs are driven from both the dgpu and igpu
21:31 gekret005: but when not doing this there's no issue, so for my use case this is fine I was only testing
21:58 Venemo: agd5f: can you please move this bug from the mesa bug tracker to the amdgpu drm one? https://gitlab.freedesktop.org/mesa/mesa/-/issues/8274 it appears the problem doesn't happen if the user switches to "linux-neptune", so I assume it's a regression in the upstream kernel
22:36 agd5f: Venemo, ok. I moved it, but it looks like a UMD issue. Is it possible "linux-neptune" has some other changes in it?
22:37 Venemo: agd5f: why does it look like a UMD issue if it's fixed by changing the kernel?
22:38 agd5f: the page faults from shaders to invalid addresses
22:38 Venemo: so how does an older kernel fixes that?
22:38 Venemo: fix* that
22:40 agd5f: not sure. maybe some hacks in linux-neptune?
22:42 Venemo: maybe Plagman would know what we have in there
22:43 Venemo: last I heard of it, it was stuck on an old kernel version due to amdgpu regressions preventing us from upgrading
22:44 Venemo: I thought you would know about that, agd5f
22:46 agd5f: maybe I don't have the context on this bug?
22:47 Venemo: all I know about this bug is that the works on one kernel version and doesn't on another
22:51 agd5f: could it be some feature that is dependent on a kernel version? E.g., mesh shaders?
22:51 Venemo: are you serious?
22:53 agd5f: I'm not familiar with that particular app. Just trying to understand what's going on
22:55 Venemo: We're not aware of any shipping game that uses mesh shaders. I'm also not familiar with that game other than what is in the bug report.
22:55 agd5f: ok
22:55 Venemo: What is the right way to address this? I guess we could test the game on 5.13 and if that works, bisect from there?
23:00 agd5f: yeah, a bisect would be great, I asked the reporter what kernel he was using where it didn't work. Looks like 6.0.0. So maybe something fixed in a newer 6.0.x stable release. Also he said it works on neptune 6.1 so maybe some issue in 6.0.0
23:01 Venemo: Thanks!
23:05 agd5f: if 6.1 fixes it, I would just suggest he updates to that since 6.0 is no longer being updated in the stable kernel
23:05 Venemo: Agreed.
23:06 Venemo: As far as I know neptune is 5.13 so I'm not exactly sure what he meant by 61 there. but let's see what he replies
23:09 agd5f: I was assuming that was an 6.1 kernel
23:09 Venemo: your guess is as good as mine