00:36 fdobridge: <m​aba_kalox> Hallo, I would like to contribute into NVK dev, where could I start?
00:36 fdobridge: <m​aba_kalox> PS. not sure if it is right place to ask, so feel free to show me the way 8)
00:47 Fijxu: fdobridge: Go into the #dri-level channel
00:47 Fijxu: oh it's a bridge, right
00:48 Fijxu: maba_kalox: Join to the #dri-devel room
00:56 fdobridge: <g​fxstrand> dakr: that sounds more complicated than just splitting into multiple jobs but I also don't care. 🤷🏻‍♀️
00:56 fdobridge: <g​fxstrand> This is a fine place. First question: what GPUs do you have?
02:05 fdobridge: <m​aba_kalox> I have RTX 3070ti.
02:05 fdobridge: <g​fxstrand> Okay, then you should be set to work on about anything.
02:06 fdobridge: <m​aba_kalox> And something between 1-2 years of embedded C dev, so - close to none driver dev experience 8)
02:06 fdobridge: <g​fxstrand> First step is to build yourself a Kernel. You'll need to pull from drm-misc-next
02:06 fdobridge: <m​aba_kalox> And something between 1-2 years of embedded C dev (embedded Linux), so - close to none driver dev experience 8) (edited)
02:07 fdobridge: <m​aba_kalox> Sure. I will follow up when it is done.
02:08 fdobridge: <g​fxstrand> https://cgit.freedesktop.org/drm-misc/log/
03:01 fdobridge: <a​irlied> found the wierd memory config
03:01 fdobridge: <a​irlied> we are allocating 2MB for 8k buffer
03:16 fdobridge: <a​irlied> https://patchwork.freedesktop.org/patch/552332/
03:38 fdobridge: <g​fxstrand> Oops...
03:38 fdobridge: <a​irlied> it seems to trip up the dma-buf tests in userspace, gonna track down where
03:49 fdobridge: <a​irlied> uggh WS_BO_LOCAL not being a flag strikes again
03:52 fdobridge: <a​irlied> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24625 needs to land first
04:03 fdobridge: <g​fxstrand> @airlied you seem as likely as anyone to be able to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24619
04:23 fdobridge: <a​irlied> halfway through a run, seems less flaky Pass: 198197, Fail: 678, Crash: 7, Skip: 817610, Flake: 8, Duration: 30:39, Remaining: 30:07
04:25 fdobridge: <a​irlied> one flake per crash seems to line up with side swiping
04:32 fdobridge: <a​irlied> also setting MESA_VK_IGNORE_CONFORMANCE_WARNING makes things a lot nicer to read
04:54 fdobridge: <a​irlied> Pass: 393328, Fail: 1303, Crash: 11, Skip: 1620590, Flake: 11, Duration: 1:01:44, Remaining: 0
04:54 fdobridge: <a​irlied> that is with danilo's fence fix and the memory alloc fix
04:55 fdobridge: <a​irlied> ampere has some geometry shader + descriptors bug
05:56 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Where can I those kernel fixes?
05:56 fdobridge: <a​irlied> on the dri-devel mailing list
05:56 fdobridge: <a​irlied> I think we've posted patchwork links in here
05:57 fdobridge: <a​irlied> https://patchwork.freedesktop.org/patch/552311/ is the fence once
05:58 fdobridge: <a​irlied> and I posted the memory one just up there
05:58 fdobridge: <a​irlied> the memory one needs the mesa fix applied to not regress
06:07 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> So that Mesa change will explode unpatched kernels? 💥
06:09 fdobridge: <a​irlied> no vice-versa
06:57 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://aur.archlinux.org/packages/nouveau-fw-gsp 🚀
07:27 fdobridge: <y​oumukonpaku1337> Poggers
10:59 doras: Any opinions from nouveauWinSys/GBM experts about this issue? https://github.com/flathub/org.chromium.Chromium/pull/309#issuecomment-1674457260
11:05 doras: The context is that hardware acceleration in Chromium with nouveau is broken, and some Electon apps are completely broken, and neither will work until this matter is concluded.
11:40 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> How good is this warning? :triangle_nvk:
11:40 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1139523768595783741/image.png
11:46 fdobridge: <y​oumukonpaku1337> how does nvk perform nowadays?
11:46 fdobridge: <y​oumukonpaku1337> like
11:46 fdobridge: <y​oumukonpaku1337> is it comparable to prop speeds
11:48 fdobridge: <y​oumukonpaku1337> or is it still talos principle at 13fps speeds
11:48 karolherbst: doras: 1. what do you mean by "completely broken"? They don't run at all or what? 2. If somebody sends patches to improve the situation we'll gladly take them unless it's a regression and I'm confused, because using electron apps was never an issue
11:49 fdobridge: <y​oumukonpaku1337> i suppose they might depend on hardware acceleration to work?
11:49 fdobridge: <y​oumukonpaku1337> or try to use hardware acceleration regardless of whether its broken and break
11:49 doras: karolherbst: it seems that Electon apps don't fall back to software rendering when the Chromium GPU process exits due to a fatal error, or something like that.
11:50 doras: I haven't dug into the Electon internals to figure out how it's different than Chromium itself in this regard.
11:50 karolherbst: so is this with any random electron app or some specific? Or does it need a newer electron version or anything?
11:51 karolherbst: or is it really just the case when there is no hw acceleration available?
11:51 fdobridge: <y​oumukonpaku1337> so my guess was right
11:54 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Definitely not yet
11:55 doras: karolherbst: it's Element in my case. The issue stems from a change in Chromium upstream (https://chromium-review.googlesource.com/c/chromium/src/+/4380766)
11:57 doras: The issue is mostly that it's not entirely clear if this is a nouveau or a Chromium issue, since the intended nature of the GEM handle that GBM returns is not clearly defined. This is what's discussed in the Flathub Chromium PR that I linked.
11:58 doras: I feel that additional opinions may help establish a path forward.
11:59 karolherbst: nouveua should behave like all the other drivers I'd say
13:29 fdobridge: <e​sdrastarsis> 40 FPS on my setup with reclocking on low settings
13:30 fdobridge: <y​oumukonpaku1337> what about xonotic on zink on nvk
13:32 fdobridge: <e​sdrastarsis> idk, I haven't tested the new uAPI yet
13:32 fdobridge: <e​sdrastarsis> but looks like zink has rendering issues on supertuxkart
13:32 fdobridge: <y​oumukonpaku1337> ioa
13:33 fdobridge: <e​sdrastarsis> https://discord.com/channels/1033216351990456371/1034184951790305330/1138025811040018512
13:40 fdobridge: <y​oumukonpaku1337> PFFT
13:40 fdobridge: <y​oumukonpaku1337> SJWIWNENSKWJEN
13:40 fdobridge: <y​oumukonpaku1337> that is goofy
13:43 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I can test Xonotic too
13:44 fdobridge: <y​oumukonpaku1337> sure
17:08 fdobridge: <g​eorgeouzou> I get some weird MESA: error: ../src/nouveau/vulkan/nvk_queue_drm_nouveau.c:365: DRM_NOUVEAU_EXEC failed: No such device (VK_ERROR_DEVICE_LOST)
17:08 fdobridge: <g​eorgeouzou> when running the clear/multisample tests (grep -r clear vk-default/pipeline/monolithic.txt | grep multisample)
17:19 fdobridge: <a​irlied> That's not wierd, that is device lost
17:19 fdobridge: <a​irlied> You crashed the channel by sending a bad pushbuf
17:21 fdobridge: <g​eorgeouzou> I build the main branch
17:21 fdobridge: <g​eorgeouzou> I did not make any further changes
17:22 fdobridge: <g​eorgeouzou> When i remove the *r8g8b8a8_unorm_r16g16b16a16_sfloat_r32g32b32a32_uint_d24_unorm_s8_uint* tests it all works smoothly,
17:22 fdobridge: <g​eorgeouzou> I need to further analyze it
17:27 fdobridge: <g​eorgeouzou> Hmm it only happens when all tests are run together. If i run only some of those it works ok
17:27 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> How about D24S8?
17:28 fdobridge: <g​eorgeouzou> If i run only the d24_unorm_s8_uint group it works ok
17:29 fdobridge: <g​eorgeouzou> If i remove it from the others they work ok,
17:29 fdobridge: <g​eorgeouzou> but all together they explode 🙂
17:32 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> And how about RGBA32?
17:35 fdobridge: <g​eorgeouzou> If i remove or run only the rgba32 it works ok
17:35 fdobridge: <g​eorgeouzou> If i remove or run only the rgba32 group it works ok (edited)
17:36 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Have you checked dmesg?
17:47 fdobridge: <g​eorgeouzou> I will check it further again later
17:47 fdobridge: <g​eorgeouzou> It consistently fails at least
17:51 fdobridge: <g​eorgeouzou> So it should be easier to fix
18:01 fdobridge: <a​irlied> Probably a vmfault what GPU is it?
18:06 fdobridge: <g​eorgeouzou> Rtx 2070
18:32 fdobridge: <g​eorgeouzou> Do you think it's related to turing only?
18:36 fdobridge: <a​irlied> Not sure if we seen it in CTS runs, but maybe it needs a certain order
19:48 doras: karolherbst: I presume having to expose a new libdrm API to fix the issue with Chromium would not be optimal, would it? The problem is nouveau keeps its "global" GEM handle list in libdrm, while most drivers keep theirs in Mesa. The list is used to track exported GEM handles to allow managing a single reference count for such handles across multiple buffer objects.
19:51 karolherbst: doras: there are plans to ditch libdrm for nouveau
19:52 karolherbst: but anyway, I'm still not sure what's requested here. Anyway, others know way more about this area than I do, so either somebody just makes that change or describes what needs to be changed
19:52 doras: karolherbst: I see. The bug is that nouveau doesn't consider a GEM handle exported (doesn't add it to its "global" list) when a user queries for the handle. It simply returns it.
19:53 doras: I can make the change, but wouldn't it be difficult/impossible to backport to stable versions if it depends on a new libdrm API?
19:54 karolherbst: kinda depends. If you can make that change inside mesa that's good enough
19:57 doras: karolherbst: I may be able call an existing libdrm API to get the handle into the exported list, but it would call an unnecessary ioctl. It's a bit of a ugly hack, but maybe not too bad for stable versions?
19:58 doras: Basically, it would call drmPrimeHandleToFD unnecessarily and then we'll close the fd we get to avoid any side-effects. Not a pretty solution, but may work.
19:59 doras: This can be a Mesa-only change.
19:59 karolherbst: I think it's eaiser to discuss a proper solution once I can get my head around what needs to be changed here. If the solution is to move libdrm into the tree and fix it there, so be it, but I'd rather just rewrite the entire layer anyway :D
20:00 karolherbst: but whatever fixes it
20:01 doras: karolherbst: when you have a few minutes, I summarized it briefly here: https://github.com/flathub/org.chromium.Chromium/pull/309#issuecomment-1667457051
20:03 fdobridge: <a​irlied> Oh no we've been phoronixed, im too scared to look
20:03 fdobridge: <k​arolherbst🐧🦀> don't
20:03 fdobridge: <k​arolherbst🐧🦀> oh wow 😄
20:03 fdobridge: <k​arolherbst🐧🦀> it's bad
20:04 fdobridge: <k​arolherbst🐧🦀> we get like 5% perf
20:04 fdobridge: <k​arolherbst🐧🦀> maybe 1%
20:04 fdobridge: <k​arolherbst🐧🦀> depends on the test 😄
20:04 fdobridge: <k​arolherbst🐧🦀> anyway
20:04 fdobridge: <k​arolherbst🐧🦀> without GSP it's no surprise
20:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> There's no GSP firmware for RTX 4000 series yet
20:05 karolherbst: doras: couldn't we just call nouveau_bo_set_prime in both cases or something?
20:06 doras: karolherbst: this is my hacky suggestion. It would call `drmPrimeHandleToFD` and provide us with a fd that we'll need to close.
20:07 doras: Because the return value in the case of WINSYS_HANDLE_TYPE_KMS is the handle itself, not a fd.
20:08 doras: So yes, we could.
20:08 karolherbst: I literally have no idea about any of this
20:08 doras: :)
20:08 fdobridge: <a​irlied> Is there a mesa.issue?
20:09 fdobridge: <a​irlied> I can maybe take a closer look if you someone pokes me next week
20:10 doras: airlied: are you asking about the nouveau thing? I can open a proper issue.
20:11 fdobridge: <a​irlied> Yes, I think your hack is probably good enough
20:12 doras: Sure. I'll check if it works and open a MR too.
20:12 karolherbst: anybody with proper knowledge about that dma-buf/gbm/whatever stuff should feel free to merge and cc stable whatever fix is suiteable here :P
20:25 fdobridge: <g​fxstrand> I almost didn't notice the we were even on the graphs. 🤣
20:48 fdobridge: <g​fxstrand> I will not get a phoronix account and troll the forums. I will not get a phoronix account and troll the forums....
20:51 fdobridge: <k​arolherbst🐧🦀> 😄
20:51 fdobridge: <k​arolherbst🐧🦀> depends entirely on if the usual shitheads join the fun or not
20:51 fdobridge: <a​irlied> Don't get one under youur real name 🙂
20:52 fdobridge: <k​arolherbst🐧🦀> that was my real mistake
20:52 fdobridge: <a​irlied> They will get there, I won't read comments after another hour :-p
20:52 fdobridge: <k​arolherbst🐧🦀> they are already there
20:53 fdobridge: <a​irlied> Ah only one so far
20:53 fdobridge: <k​arolherbst🐧🦀> still
20:54 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1139663056855634042/Screenshot_20230811-155338.png
20:55 fdobridge: <k​arolherbst🐧🦀> yeah... it's only going downhill from now on
20:56 fdobridge: <k​arolherbst🐧🦀> give or take, but page 3+ is where it's just nonsense
21:03 fdobridge: <g​fxstrand> @airlied You keep saying "new compiler"... I should probably get back to that. 😅
21:04 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Hopefully the vkcube milestone can be reached fairly soon :ferris:
21:07 fdobridge: <g​fxstrand> :triangle_nvk:
21:08 fdobridge: <g​fxstrand> Yeah, I'll probably decide to care about 3D stages after I get spilling working.
21:47 fdobridge: <a​irlied> Or not 🙂 seems like we can get quite far with no spilling!
21:55 fdobridge: <k​arolherbst🐧🦀> we do have a couple of registers available
21:59 fdobridge: <g​eorgeouzou> I get the following:
21:59 fdobridge: <g​eorgeouzou> [ 349.114985] nouveau 0000:01:00.0: fifo: fault 01 [VIRT_WRITE] at 0000007fffd92000 engine 40 [gr] client 1d [HUB/SKED] reason 02 [PTE] on channel 2 [01ffe43000 deqp-vk[4490]]
21:59 fdobridge: <g​eorgeouzou> [ 349.114992] nouveau 0000:01:00.0: fifo:000000:0002:[deqp-vk[4490]] rc scheduled
21:59 fdobridge: <g​eorgeouzou> [ 349.114993] nouveau 0000:01:00.0: fifo:000000: rc scheduled
21:59 fdobridge: <g​eorgeouzou> [ 349.115000] nouveau 0000:01:00.0: fifo:000000:0002:0002:[deqp-vk[4490]] errored - disabling channel
21:59 fdobridge: <g​eorgeouzou> [ 349.115002] nouveau 0000:01:00.0: deqp-vk[4490]: channel 2 killed!
22:00 fdobridge: <a​irlied> yeah that's a write fault
22:09 HdkR: 256 encoded registers is a pretty good amount before needing to spill :D
22:11 fdobridge: <g​eorgeouzou> i managed to consistently reproduce this by linearly running a list of 67 tests, but i cannot pinpoint the issue yet.
22:12 fdobridge: <g​eorgeouzou> i managed to consistently reproduce this by linearly running a list of 67 tests, but i cannot pinpoint the cause yet. (edited)
22:26 fdobridge: <g​eorgeouzou> and the push dump: https://pastebin.com/eupuDfpu