00:04 airlied[d]: _lyude[d]: I think a possible fix would be drop the vma from the list at the close time
00:06 airlied[d]: diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c
00:06 airlied[d]: index 82621ede42e1..f97ae83a0278 100644
00:06 airlied[d]: --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
00:06 airlied[d]: +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
00:06 airlied[d]: @@ -168,6 +168,7 @@ nouveau_gem_object_unmap(struct nouveau_bo *nvbo, struct nouveau_vma *vma)
00:06 airlied[d]: return;
00:06 airlied[d]: }
00:06 airlied[d]: + list_del_init(&vma->head);
00:06 airlied[d]: if (!(work = kmalloc_obj(*work))) {
00:06 airlied[d]: WARN_ON(dma_fence_wait_timeout(fence, false, 2 * HZ) <= 0);
00:06 airlied[d]: nouveau_gem_object_delete(vma);
00:21 phomes_[d]: karolherbst[d]: I rebased in on the baseline and tested. It helped a bit but not too much
00:22 karolherbst[d]: mhhh
00:22 karolherbst[d]: well thanks for testing anyway!
00:22 karolherbst[d]: I know it helps more with compute workloads tho.. but I _think_ it's gonna mitigate some of the regressions from the other MRs...
00:27 phomes_[d]: I can test it with some extra games/benchmarks tomorrow
00:27 karolherbst[d]: could be that I messed something up... I haven't checked stats with that work for quite some while
00:28 phomes_[d]: fun thing. If I revert !39679 on top of the baseline then Serious Sam 2017 gets 300 fps. Exactly the same as prop
00:30 karolherbst[d]: mhhhhhhhhhhhhhhhhhhhhhhh
00:30 karolherbst[d]: annoying 🙃
00:30 karolherbst[d]: does it help other games?
00:33 phomes_[d]: only Serious sam and Talos have the driconf vk_x11_ignore_suboptimal set, which is what that MR is about
00:33 karolherbst[d]: ahh
00:43 airlied[d]: okay spark channels are creating, now to see if I can display to init
00:46 mhenning[d]: phomes_[d]: I pushed a new version of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33613 that might fix The Surge 2 if you want to try it when you have a chance
07:04 phomes_[d]: mhenning[d]: yes that fixed it. +1 fps win for Lego Builder's journey too
07:13 marysaka[d]: Did anyone had some random invalid EDID at boot on Blackwell? I'm getting a 1080p resolution before handing over to nouveau but then I'm locked at 720p with `[drm] [CONNECTOR:45:HDMI-A-1] EDID invalid.`
07:16 marysaka[d]: I have a 5080 and I got that on the first boot yesterday with it and again today with a cold boot, if I reboot the issue disappear
08:01 airlied[d]: Does reloading nouveau fix it?
08:04 chikuwad[d]: are there any old abandoned MRs that would be nice to have fixed up and re-submitted?
08:06 chikuwad[d]: also re: VK_EXT_device_address_binding_report, do I continue working on mine or let the new MR take over
08:08 marysaka[d]: airlied[d]: no, also unplugging replugging doesn't work and it seems to not even detect the port changed state
08:09 marysaka[d]: I will try to swap cable just in case and see if it happens again at some point
08:32 phomes_[d]: chikuwad[d]: I did dlss, and is currently doing the same for the video MR. Maybe 36359 (nir_opt_varyings) would be a candidate if Mary agrees
08:32 marysaka[d]: Yeah it could be it had some weird regressions back then but it might be worth rebasing and retesting
08:41 chikuwad[d]: 🫡
09:26 chikuwad[d]: marysaka[d]: wait do I need to run a full CTS for it?
09:27 marysaka[d]: chikuwad[d]: yes
09:27 chikuwad[d]: ah oke
09:27 marysaka[d]: on what distro are you doing testing btw?
09:27 marysaka[d]: I have some fedora stuffs to automate building and help my testing if you want
09:28 chikuwad[d]: cachyos
09:28 chikuwad[d]: but you could share your stuff and I can adapt it to mine c:
09:28 chikuwad[d]: I should also probably get off my ass and set up deqp-runner
09:29 marysaka[d]: yeah install deqp-runner
09:29 marysaka[d]: https://codeberg.org/marysaka/cts_build_scripts
09:30 marysaka[d]: Those are basically mesa ci deqp build script and vkd3d-proton test ones but done locally and creating some archive
09:30 marysaka[d]: tho that mean it create /deqp-vk /deqp-gl ect on your rootfs so be aware of that
09:32 marysaka[d]: I basically have some release tarballs that I push on all my arm64/amd64 systems on my local network and I just reuse the deqp toml we have for mesa-ci directly
09:32 chikuwad[d]: I see
09:32 chikuwad[d]: I'll adapt these to use different paths, ty
09:33 chikuwad[d]: I'm also working on VK_EXT_shader_atomic_float/float2 btw
09:33 chikuwad[d]: the former is just enablement, the latter had some CTS fails that I need to investigate (but that's probably trivial)
09:34 jannau: I have https://gitlab.freedesktop.org/jannau/lamci/-/blob/main/lamci.sh?ref_type=heads which uses the mesa container images for testing (hardcoded for asahi/arm64)
09:36 chikuwad[d]: I wish there was an easier way to identify a cts caselist for a specific extension tbh
09:36 chikuwad[d]: as an "outsider"
09:38 chikuwad[d]: I know people with khronos access can basically go look at the branch that adds cases for new extensions and just get the list from there
09:57 esdrastarsis[d]: phomes_[d]: Would be great if someone could send the nvdec kernel part before the 7.1 merge window closes
10:46 marysaka[d]: airlied[d]: _lyude[d] We are missing CRTC_ID property on our DRM connectors on nouveau, any ideas why? (see https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15248)
11:17 airlied[d]: Maybe because we don't enable atomic?
11:40 marysaka[d]: so it must be that
11:42 marysaka[d]: and considering [the commit that introduced it years ago assume that atomic is the standard](https://gitlab.freedesktop.org/mesa/mesa/-/commit/513ffea1d366c82e50975fd430d012ff8e652a79) it must have been broken for a while.... vulkaninfo might have added something to query those details and that's why we are only seeing it now
11:52 karolherbst[d]: we should just enable atomic...
11:54 marysaka[d]: yeah 🙃
11:54 zmike[d]: chikuwad[d]: this has been requested by literally everyone for years
11:55 zmike[d]: finding the original CL from gerrit is not convenient because often there are many (many many many) CLs and having to sift through all of them to find test names is impractical
11:56 mohamexiety[d]: yeah, it only works for smaller stuff like e.g. maintenance exts or such
11:56 chikuwad[d]: there's a gerrit?
11:56 chikuwad[d]: [derproo](https://cdn.discordapp.com/emojis/487610926644592643.webp?size=48&name=derproo&lossless=true)
11:57 zmike[d]: cts goes through khronos gerrit
11:57 zmike[d]: which everyone hates
11:58 chikuwad[d]: right
11:58 mohamexiety[d]: yeah 🙃
11:58 chikuwad[d]: I imagine that's also just internal to khronos members
11:58 chikuwad[d]: I've used gerrit and am somewhat familiar with it but yeah, gerrit is a pain
11:58 zmike[d]: everything is internal
11:59 chikuwad[d]: I see
12:09 chikuwad[d]: but yeah
12:09 chikuwad[d]: as a non-khronos contributor it's ridiculously difficult to find out what tests to run
12:09 chikuwad[d]: I've genuinely just been going off of other MRs to identify test cases, and even then sometimes the other MRs don't mention them
12:10 chikuwad[d]: just "passes CTS"
12:15 zmike[d]: It's mostly not any easier for the rest of us
12:15 zmike[d]: I usually just run CTS with an extension disabled and the run again with it enabled
12:15 mohamexiety[d]: chikuwad[d]: this usually means the full suite, not a specific caselist :KEKW:
12:15 zmike[d]: Yup
12:16 chikuwad[d]: extra pain
12:16 chikuwad[d]: maybe I should also just do full CTS runs
12:20 karolherbst[d]: just move development to github 😛
12:22 mohamexiety[d]: honestly the issue with full CTS is just mainly time really
12:22 mohamexiety[d]: on my desktop it takes like 40 minutes, but on the laptop it's _3 hours_
12:23 mohamexiety[d]: and it hogs the entire thing so you basically can't do much with it running
13:15 karolherbst[d]: just have two machines 😛
14:04 zmike[d]: key aspect of driver development
14:42 chikuwad[d]: time to sell my 3070 and get 2x 3050 for the price
14:42 chikuwad[d]: just so I can have a dedicated CTS machine
15:02 chikuwad[d]: does NVK support VK_FORMAT_R32G32B32_SFLOAT?
15:03 mohamexiety[d]: karolherbst[d]: yeah that's what i did in the end :KEKW:
15:04 chikuwad[d]: wait I'm dumb vulkaninfo can probably tell me
15:05 mohamexiety[d]: chikuwad[d]: yes
15:09 mohamexiety[d]: oh hm
15:10 mhenning[d]: chikuwad[d]: tbh I mostly just add an assert for where the extension is used on the driver side and then kick off a cts run. Sometimes you'll see a failure in the first few minutes of running.
15:10 mhenning[d]: You can grep through cts sources but I don't normally find that's worth the effort
15:10 chikuwad[d]: I've been doing --deqp-terminate-on-fail=enable
15:12 mhenning[d]: Yeah, that can help too
15:17 karolherbst[d]: ohh right I wanted to verify that TEX ordering thing...
15:21 _lyude[d]: karolherbst[d]: Now that I've fixed the screen flashing bug I'm actually planning on sending a commit after to enable it 🙁
15:21 _lyude[d]: Oops, meant for that to be a 🙂
15:22 _lyude[d]: That was pretty much the only remaining bug I could find when using atomic
15:23 karolherbst[d]: nice
15:23 karolherbst[d]: finally 😄
15:23 _lyude[d]: Yep!
15:34 karolherbst[d]: okay.. we have to bump to rust 1.95 😄
15:34 karolherbst[d]: https://doc.rust-lang.org/nightly/core/macro.cfg_select.html
15:34 karolherbst[d]: I want this
15:35 karolherbst[d]: I think I need to play around with this a little, _but_ I think I can use it for compile time constants maybe...
15:58 chikuwad[d]: hm, if I wanted to implement RGB32 linear formats, will I have to emulate them with RGBA32?
15:58 chikuwad[d]: or would that be the wrong approach
16:18 asrivats: hey folks need some feedback, does anyone know why drawIndirectCount is in gl21_baseline_vk12? does zink actually use it interanlly or is it only needed when a GL app uses GL_ARB_indirect_parameters? i am looking at nvk+zink for pre-turing and this is the first roadblock that prevents zink from being loaded.....wondering if zink requirements can be relaxed
16:27 mhenning[d]: Might be better to implement DrawIndirectCount pre-turing
16:31 asrivats: @mhenning[d], NVK and panvk are the only 2 that gate it to newer hardware. most drivers advertise true and hence the requirement probably
16:33 asrivats: @mhenning[d], The old nouveau GL driver handles this on pre-turing by using IB entries to DMA the count and draw params into pushbuffer for MME. NVK has nvk_cmd_buffer_push_indirect() which does the same thing. will this be a good place to start?
16:39 GB206_User: hi
16:41 mhenning[d]: asrivats: Yes. Turing+ mme has the ability to read memory directly using mme_tu104_read_fifoed - you'll see that nvk_mme_draw_indirect_count uses this functionality. Before turing, this doesn't exist and we instead need to push indirect buffers to do the reads - see eg. nvk_mme_xfb_draw_indirect and nvk_CmdDrawIndirectByteCountEXT for an example of how to do this
16:41 mhenning[d]: nvk_mme_draw_indirect_count really just needs to be ported to pre-turing
16:43 asrivats: @mhenning[d], thanks :) i ll take a look at these
16:46 _lyude[d]: airlied[d]: oh hm. Now I'm not actually sure if there's a race with nouveau_gem_object_destroy - I didn't notice until just now that we do actually call `list_del_init` under lock to prevent it from leaving the dead vma on the list. more digging to do then 🙂
16:57 GB206_User: since researching didn't show anything remotely similar, I wonder if this is a known limitation? Running a 5060 TI (GB206), GSP 570.144 fails to load on two different suppliers (Gainward & PNY) with gsp: init failed, -22
16:59 karolherbst: GB206_User: _might_ need newer GSP firmware
16:59 karolherbst: do you know if the official nvidia driver 570.144 loads on those GPUs?
17:00 GB206_User: didnT go down that road yet, though on Windows 10 it works fine with the current driver
17:03 GB206_User: the wird thing is I could have sworn it worked on a GIGABYTE variant, though that one had vertical line defects even on Windows, so I returned it
17:03 GB206_User: is there anything newer than 570.144 I could try?
17:08 karolherbst: airlied[d] might have something somewhere I think
17:42 mohamexiety[d]: it shouldnt need a newer firmware. i am running fine on a 5060 and that came after the 5060ti
17:43 GB206_User: huh, intersting
17:43 karolherbst[d]: Let me tell you about how Nvidia released newer Pascal/Turing/Ampere GPUs, which all required updated firmwares pre GSP to orderly function 🙃
17:44 karolherbst[d]: No idea what's up there, but sometimes they do newer batches for existing chipsets that then need updated firmwares
17:44 mohamexiety[d]: utrace MR probably in a good enough shape for an initial review/look btw. i am still not entirely certain i got the sync between gpu timestamp write and then event processing right, but i'll look into it more and also try hooking up my perfetto skeleton and see where that takes me
17:46 GB206_User: if the serial number beginning from PNY is any indication, this card should have a production date of week 50 last year... but that might be just cooincidence in the number - any way to get production date?
19:16 airlied[d]: Can you boot with nouveau.debug=trace and pastebin the dmesg of nouveau
19:17 airlied[d]: If you have a very new kernel I think you can drop newer 570 gsp binary in and it should work
20:32 _lyude[d]: sigh. screen flashed :(. looks like I've still got more work to do
20:36 airlied[d]: nouveau/gsp: use rpc sequence numbers properly is the commit needed for newer 570 fw to just drop in
22:02 redsheep[d]: airlied[d]: Didn't you also get 595 booting?
22:03 airlied[d]: yeah but that's a lot more painful, I have 580 and 595 going
22:37 gfxstrand[d]: asrivats: Yeah, so we probably need to make it consume the max amount of data (because we have to push the max amount from the CPU) but discard everything after the count.
23:19 zmike[d]: asrivats: opengl requires certain features in order to advertise a given version; it isn't based on app usage, it's just that's how versions work