00:35 esdrastarsis[d]: Interesting: https://patchwork.freedesktop.org/patch/598445/
02:25 rinlovesyou[d]: hmm. got rid of my nvidia stuff like usual to check in on nouveau/nvk and now it's not working anymore
02:26 rinlovesyou[d]: seeing
02:26 rinlovesyou[d]: [ 3.423844] nvidia-gpu 0000:0b:00.3: i2c timeout error e0000000
02:26 rinlovesyou[d]: but that's about it, not seeing any errors from nouveau
02:27 rinlovesyou[d]: `sudo dmesg | grep nouveau` :
02:27 rinlovesyou[d]: [ 2.726443] nouveau 0000:0b:00.0: vgaarb: deactivate vga console
02:27 rinlovesyou[d]: [ 2.726494] nouveau 0000:0b:00.0: NVIDIA TU104 (164000a1)
02:27 rinlovesyou[d]: [ 2.898735] nouveau 0000:0b:00.0: bios: version
02:27 rinlovesyou[d]: [ 4.260239] nouveau 0000:0b:00.0: DRM: VRAM: 8192 MiB
02:27 rinlovesyou[d]: [ 4.260245] nouveau 0000:0b:00.0: DRM: GART: 536870912 MiB
02:27 rinlovesyou[d]: [ 4.302650] nouveau 0000:0b:00.0: DRM: MM: using COPY for buffer copies
02:27 rinlovesyou[d]: [ 4.330271] snd_hda_intel 0000:0b:00.1: bound 0000:0b:00.0 (ops nv50_audio_component_bind_ops [nouveau])
02:27 rinlovesyou[d]: [ 4.335613] [drm] Initialized nouveau 1.4.0 20120801 for 0000:0b:00.0 on minor 0
02:27 rinlovesyou[d]: [ 4.378519] fbcon: nouveaudrmfb (fb0) is primary device
02:27 rinlovesyou[d]: [ 4.527428] nouveau 0000:0b:00.0: [drm] fb0: nouveaudrmfb frame buffer device
02:31 rinlovesyou[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1250638555135479818/image.png?ex=666bab6b&is=666a59eb&hm=7e73510b82c14abb9d4a7a1f14cf853f2e22ada18a2af6489a64d6e589c21c71&
02:31 rinlovesyou[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1250638555441795173/image.png?ex=666bab6b&is=666a59eb&hm=82ec99dadb086d0bf661017d9db82f3274cdc27f22c23dbf4f41961d096c1e40&
02:31 rinlovesyou[d]: GPU viewer certainly claims it's NVK, but then why is my desktop session running over llvmpipe?
02:34 tiredchiku[d]: desktop session needs a gallium driver
02:36 rinlovesyou[d]: uh huh, and the mesa package i use builds with zink on
02:36 rinlovesyou[d]: it used to work just fine
02:36 rinlovesyou[d]: but for some reason it's using llvmpipe
02:37 redsheep[d]: What kernel?
02:37 rinlovesyou[d]: the same kernel i've been using for a while, linux-gfxstrand
02:39 tiredchiku[d]: I should update that pkgbuild and publish it somewhere properly
02:48 rinlovesyou[d]: has it still not made it into the kernel proper?
02:50 tiredchiku[d]: nope
02:50 rinlovesyou[d]: >sudo is not accepting my password
02:50 rinlovesyou[d]: what is happening
02:50 tiredchiku[d]: those patches are still not in
02:57 rinlovesyou[d]: anyways i saw that the package i'm using changed how it installs these things so i tried to just build with zink & nouveau enabled myself but it's still not working
02:59 rinlovesyou[d]: incredible zink skill issue i guess, nouveau gallium driver works just fine..
03:19 rinlovesyou[d]: an issue with the `NOUVEAU_USE_ZINK` env var maybe
03:22 redsheep[d]: rinlovesyou[d]: With wayland, or with x11? That sounds like what I see either on default kernels or wayland
03:30 rinlovesyou[d]: x11
03:30 rinlovesyou[d]: I know that Wayland doesn't work yet
03:31 tiredchiku[d]: isn't kwin's explicit sync buggy
04:03 airlied[d]: karolherbst[d]: skeggsb9778[d] the m2mf class headers never made it out did they? any reason we still use m2mf instead of copy engine in nouveau?
04:05 skeggsb9778[d]: airlied[d]: i'm not sure on the headers, but i can answer the rest
04:06 skeggsb9778[d]: most of the answer, i believe, is "because no-one started using it" (though, the kernel does for ttm buffer moves)
04:06 skeggsb9778[d]: but i'm also *glad* no-one did, because prior to gk104, the method interface is defined by falcon ucode
04:07 skeggsb9778[d]: and what i implemented way back then isn't compatible with the official DmaCopy class
04:08 skeggsb9778[d]: i wanted to fix that so gt2xx/gf1xx could share code with >=gk104
04:09 airlied[d]: might write a fake class header for it so the pushbuf dumper from nvk can dump it
04:09 airlied[d]: makes sense, probably not going to get around to porting nvc0 to use in on kepler+
04:10 skeggsb9778[d]: nvkm/engine/ce/fuc/com.fuc line 72, is the dispatch table
04:17 skeggsb9778[d]: airlied[d]: what m2mf headers are missing?
04:17 skeggsb9778[d]: i see them in classes/memory-to-memory-format/ in open-gpu-doc
04:18 airlied[d]: a040 and a140?
04:18 skeggsb9778[d]: oh
04:18 airlied[d]: sorry p2mf then
04:18 airlied[d]: forgot there was a divergence there
04:19 skeggsb9778[d]: oh right, yeah that's InlineToMemory
04:19 skeggsb9778[d]: userspace's naming never caught up there 😛
04:20 skeggsb9778[d]: i'll see what i can find out there
04:32 tiredchiku[d]: rinlovesyou[d]: redsheep[d] @whoever else was using it: https://codeberg.org/Sid127/linux-gfxstrand
04:32 tiredchiku[d]: ~~because being on 6.8.7 was unfun and hopping between that and -rc was breaking my bcachefs pool~~
05:11 tiredchiku[d]: TIL
05:11 tiredchiku[d]: kwin explicit sync isn't buggy
05:12 tiredchiku[d]: you just need kwin 6.1 for it
05:12 tiredchiku[d]: which hasn't released yet
05:14 redsheep[d]: Yeah I've kind of paused bothering with more testing until 6.1
05:27 tiredchiku[d]: you can already install 6.1
05:28 tiredchiku[d]: on arch
05:28 tiredchiku[d]: https://wiki.archlinux.org/title/Official_repositories#kde-unstable
05:28 tiredchiku[d]: also requires testing repos to be enabled
06:55 karolherbst[d]: airlied[d]: we do use the copy engine
06:57 karolherbst[d]: though I thin we have 2 or 3 uses for p2mf on kepler+
07:12 karolherbst[d]: anyway.. I think p2mf is just m2mf with a lot of things removed
07:23 ahuillet[d]: p2mf doesn't ring a bell, do you know the NV internal name?
08:12 marysaka[d]: ahuillet[d]: From the little digging on envytools I made it's class_id 0xa040 or 0xa140
08:23 airlied[d]: ahuillet[d]: inline to memory I think, Ben mentioned it earlier
08:35 ahuillet[d]: ah yes, "I2M"
08:36 ahuillet[d]: as for M2MF, it disappears in Kepler, so I wouldn't worry about it (unless I misunderstood your original question)
08:45 karolherbst[d]: yeah, but the GL driver uses I2M in 2 or 3 places
08:45 karolherbst[d]: on kepler that is
08:45 karolherbst[d]: e.g. in `nve4_p2mf_push_linear`
08:46 karolherbst[d]: and `nvc0_clear_buffer_push_nve4`
08:49 ahuillet[d]: I don't know what is optimal here, I'll take a look some day
08:52 karolherbst[d]: I think the main question is just if we can get the proper class headers, so we can at least use them in our generated code, e.g. the push buffer dumper
08:52 karolherbst[d]: but yeah.. the GL driver could also be ported, but that also means touching the gl driver 😄
08:53 karolherbst[d]: and at this point I'd rather not risk regressions if it's not for bug fixes
08:55 airlied[d]: Yeah I just want to track the wierd fencing thing down, maybe it'll be i2m related 🙂
08:59 ahuillet[d]: sorry, what class headers? I2M?
09:00 ahuillet[d]: airlied[d]: I don
09:01 airlied[d]: Yeah i2m
09:01 airlied[d]: A040, a140
09:02 karolherbst[d]: I think nvgpu or something had some more proper ones or so....
09:02 karolherbst[d]: I might misremember
09:03 karolherbst[d]: anyway, the mian difference with I2M is, that the source data has to be inside the push buffer
09:03 karolherbst[d]: and everything else was nuked
09:06 karolherbst[d]: well.. not finding anything useful :ferrisUpsideDown:
09:10 karolherbst[d]: but I doubt it would be hard to get nvidia to publish those
10:23 godvino[d]: Why would `/sys/kernel/debug/vgaswitcheroo/switch` not exist on a laptop with a nvidia dgpu ?
10:23 karolherbst: because it relies on the drivers to be loaded afaik
10:24 godvino[d]: ```Jun 13 21:09:13 fedora kernel: VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.GPP0.PEGP handle
10:24 godvino[d]: Jun 13 21:09:14 fedora kernel: amdgpu: vga_switcheroo: detected switching method \_SB_.PCI0.GP17.VGA_.ATPX handle
10:24 godvino[d]: Jun 13 21:09:13 fedora kernel: VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.GPP0.PEGP handle
10:24 godvino[d]: Jun 13 21:09:14 fedora kernel: amdgpu: vga_switcheroo: detected switching method \_SB_.PCI0.GP17.VGA_.ATPX handle
10:24 godvino[d]: Jun 13 15:39:17 fedora kernel: snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client```
10:24 godvino[d]: I have this in my dmesg
10:24 karolherbst: ohh wait
10:24 karolherbst: it has a new path now
10:25 godvino[d]: it changed ?
10:26 karolherbst: mhh, maybe it hasn't... weird
10:27 karolherbst: not like yiou can do anything useful with it on your system anyway
10:27 karolherbst: maybe it stoped to show when there is no value in having it
10:28 karolherbst: godvino[d]: what would you want to use it for with anyway?
10:28 magic_rb[d]: godvino[d]: No because not all laptops have a mux switch, in fact most modern ones do not
10:28 godvino[d]: karolherbst: I used it to check if the gpu is turned on
10:28 karolherbst: yeah.. but I think it used to show regardless in the past
10:28 karolherbst: godvino[d]: you can do that via sysfs as well
10:28 godvino[d]: how ?
10:29 karolherbst: `cat /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_status`
10:29 karolherbst: or whatever is the pci address
10:30 godvino[d]: hmm so for some reason it keeps getting turned on and then getting suspended
10:30 godvino[d]: And I think that's the reason for the constant micro stutters I am experiencing
10:31 karolherbst: ahh yeah..
10:31 godvino[d]: How can I check what's causing the gpu to turn on ?
10:32 karolherbst: lsof on the render node inside /dev/dri/ maybe?
10:32 godvino[d]: A decade ago I found that TLP was causing the hdmi audio thingy of the gpu to get turned on thereby increasing the power consumption
10:32 godvino[d]: vga_switcheroo was helpfull for that
10:32 karolherbst: yeah.. so the way to use TLP is to tell them that AC is battery and not make it enable anything on AC
10:33 karolherbst: but yeah.. if userspace is using those devices, then yeah.. it shouldn't
10:34 godvino[d]: So lsof isn't showing anything but my dmesg is filled with `nouveau 0000:01:00.0: Enabling HDA controller`
10:34 karolherbst: that just happens when the device turns on
10:35 godvino[d]: And everytime `nouveau 0000:01:00.0: Enabling HDA controller` gets printed I experience a stutter
10:35 godvino[d]: karolherbst: The question is why is it turning on
10:35 karolherbst: some daemon polling the GPU for something?
10:35 karolherbst: something calling lspci all the time?
10:36 godvino[d]: No idea
10:37 godvino[d]: Firefox wouldn't be causing this right ?
10:38 karolherbst: it shouldn't
10:38 godvino[d]: Is vga_switcheroo absent on every modern devices ?
10:38 karolherbst: yeah
10:39 karolherbst: it's not a great interface to begin with
10:39 godvino[d]: but then why leave it on for oldern ones ?
10:39 karolherbst: because older hardware worked differently
10:39 godvino[d]: yeah it sucks since it doesn't work with secure boot
10:39 karolherbst: the interface exists mainly for devices where you can only have one GPU active at the same time
10:39 karolherbst: and you switch your entire system
10:40 godvino[d]: But I have it on my old laptop with a fermi gpu where I can use PRIME offloading
10:41 godvino[d]: both GPUS are active simultaneously
10:41 godvino[d]: ofc the performance sucks
10:41 karolherbst: yeah.. anyway, you need to figure out what's polling the GPU and it might as well be TLP
10:42 godvino[d]: `org.mozilla.firefox.desktop[4763]: [GFX1-]: Managed to allocate after flush.` does thing ring any bell ?
10:42 karolherbst: mhh
10:42 karolherbst: I mean
10:42 karolherbst: if lsof doesn't show anything, then firefox won't be using it
10:42 godvino[d]: karolherbst: I haven't used TLP in a long time heh
10:42 karolherbst: ahh..
10:43 godvino[d]: Would enabling GSP have caused this
10:43 godvino[d]: ?
10:43 karolherbst: no
10:43 karolherbst: it's userspace
10:43 godvino[d]: then I am out of ideas
10:43 godvino[d]: nouveau and PRIME have always been a pain in the ass..
10:43 karolherbst: does it keep happening if you stop your desktop completely?
10:44 karolherbst: well
10:44 karolherbst: but that's not a nouveau bug here...
10:44 godvino[d]: karolherbst: what do you mean "stop" ?
10:44 godvino[d]: like in a tty ?
10:44 karolherbst: stop gdm/lightdm/whatever and just have your tty without anything else
10:44 karolherbst: at least that will clean up running processes and maybe you can spot something suspicious
10:45 tiredchiku[d]: isn't HDA controller the audio controller?
10:45 karolherbst: but I suspect it's some application just polling hardware state through lspci or something silly
10:45 karolherbst: sure
10:45 karolherbst: but the GPU wakes up
10:45 karolherbst: or maybe it's some audio daemon doing weird things
10:45 karolherbst: but... using pulse or pipewire wouldn't cause this
10:46 karolherbst: so unless you use something like OSS or anything weird...
10:46 tiredchiku[d]: and on a laptop the gpu audio controller is only used for hdmi audio
10:46 tiredchiku[d]: so....
10:46 tiredchiku[d]: :wolfFIRE:
10:47 karolherbst[d]: I still bet it's lspci
10:47 karolherbst[d]: and maybe uninstalling it fixes it :ferrisUpsideDown:
10:47 tiredchiku[d]: can't relate
10:48 karolherbst[d]: the PCI interfaces are just a bit silly and require the devices to be all resumed
10:48 karolherbst[d]: it's really bad
10:48 karolherbst[d]: nothing should use lspci anywhere except the user in front of the screen directly
10:50 godvino[d]: So even without gdm running it keeps getting turned on
10:50 karolherbst: do you have lspci installed? Might try to uninstall it?
10:51 karolherbst: if that doesn't help, you should probably check what's running on your system through top or htop
10:52 karolherbst: mhh.. maybe journalctl might even show if whatever that is prints something regularly
10:52 godvino[d]: karolherbst: It's just a cli tool right ? How would it run without me explicitly running it ?
10:53 karolherbst[d]: some other daemon/service/whatever just calling it regularly
10:53 karolherbst[d]: though `libpciaccess` might also trigger it...
10:53 karolherbst[d]: though I doubt it
10:54 godvino[d]: This is on a default fedora sb installation
10:54 karolherbst[d]: huh...
10:54 karolherbst[d]: nothing installed on top or anything?
10:54 godvino[d]: My other one with a fermi gpu doesn't have this problem
10:54 godvino[d]: Nothing
10:54 karolherbst[d]: then I'd say it's a fedora sb bug
10:54 godvino[d]: This is silverblue. Cant even install anything 😂
10:55 karolherbst[d]: but yeah.. maybe check `journalctl --follow` if it prints anything
10:55 karolherbst[d]: but yeah.. dunno
10:55 karolherbst[d]: rogue userspace doing bad things is like... not our bug :ferrisUpsideDown:
10:56 godvino[d]: karolherbst[d]: It's just full of `nouveau 0000:01:00.0: Enabling HDA controller`
10:56 godvino[d]: Does nouveau not report temperature for laptop gpus nowadays ?
10:57 karolherbst[d]: it's not wired up with GSP
10:57 godvino[d]: ah
10:57 karolherbst[d]: and it's a bit weird to wire up as well, so somebody needs to come up with a good idea anyway
10:58 karolherbst[d]: mhh
10:58 karolherbst[d]: anyway
10:58 karolherbst[d]: godvino[d]: could also paste the output of `ps aux` maybe I spot something weird
10:58 karolherbst[d]: but please from a plain tty without the desktop running
10:58 karolherbst[d]: 😄
10:58 notthatclippy[d]: karolherbst[d]: A later gsp.bin should be exposing that nicely, so it'll come whenever the firmware update and everything else comes.
10:58 karolherbst[d]: notthatclippy[d]: ahh, nice
10:59 notthatclippy[d]: Basically a page in (system?) memory that is continuously updated with the values and a seqlock to read it. Can map it directly to userspace if you want, or just expose via sysfs/procfs/whatever
11:00 karolherbst[d]: yeah.. so the thing about `hwmon` is, that it polls from userspace
11:00 karolherbst[d]: so we'd just have to read from that mapped memory in a synchronized manner
11:00 godvino[d]: Anyone remember the kernel parameter to tell systemd to not start the DE ?
11:01 godvino[d]: I think its called rescue shell or something
11:01 notthatclippy[d]: It's what all NV owned userspace (NVML, X driver, OGL, etc) is switching to too
11:01 karolherbst[d]: godvino[d]: just do `systemctl stop gdm.service` to stop it
11:01 karolherbst[d]: (if you are on gnome)
11:01 karolherbst[d]: cool
11:02 karolherbst[d]: but yeah.. in nouveau we'd just make hwmon using it
11:02 karolherbst[d]: (which nvidia should also do 😛 )
11:02 karolherbst[d]: though I guess it contains a few more things, like GPU engine loads and stuff?
11:03 karolherbst[d]: or is that a different interface?
11:03 godvino[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1250767549545582633/ps2.txt?ex=666c238d&is=666ad20d&hm=cf81471a3ff79927c0077fc3cf031f6d12aacbc9b625846f1d4b23293eb2eb39&
11:03 godvino[d]: karolherbst[d]:
11:05 notthatclippy[d]: karolherbst[d]: The goal for the thing is to put any "changes a lot" data in there, and avoid trips down to GSP to fetch that data for monitoring. We're initially just putting some of the bits that MangoHud and a few other popular tools poll, plus a few things specific datacenter customers requested.
11:06 karolherbst[d]: godvino[d]: might stopping `uresourced`?
11:06 notthatclippy[d]: This is the latest: <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/555/src/common/sdk/nvidia/inc/class/cl00de.h#L214-L266>
11:06 notthatclippy[d]: but it is the most unstable of ABIs for now as we're still working out the kinks.
11:06 godvino[d]: karolherbst[d]: let's see
11:07 godvino[d]: Nope. Still happens
11:07 karolherbst[d]: notthatclippy[d]: where are the fan speeds 😄
11:08 karolherbst[d]: mhhh
11:08 godvino[d]: another question, should `MESA_VK_DEVICE_SELECT` be used together with `DRI_PRIME` ?
11:09 karolherbst[d]: I doubt that DRI_PRIME does anything for vulkan
11:10 karolherbst[d]: it's just there because GL has no real interface for device selection
11:10 karolherbst[d]: godvino[d]: mhh.. that's quite annoying then... could also be some timer thing starting regularly
11:10 karolherbst[d]: anyway
11:10 karolherbst[d]: maybe just file a bug against fedora sb or something, because I seriously have no idea what's wrong there
11:11 godvino[d]: np
11:11 godvino[d]: thanks for the help
11:14 godvino[d]: I now booted without `nouveau.config=NvGspRm=1` and it doesn't happen anymore
11:14 godvino[d]: weird
11:16 karolherbst[d]: strange...
11:17 karolherbst[d]: maybe some weird interrupt stuff is going on...
11:18 karolherbst[d]: we really should at some flip to be able to pinpoint who is causing the wake ups, but that's like core infra in the kernel and I wouldn't have a good idea on how to do it anyway
11:19 karolherbst[d]: my main concern is, that enabling GSP could also make userspace behave differently, and we don't really enable the GPU for kernel internal reasons
11:19 karolherbst[d]: mostly just if the HDMI audio stuff is getting used, it would also power up the GPU
11:19 godvino[d]: okay false alarm. I now booted with `nouveau.config=NvGspRm=1` and it still doesn't happen
11:20 karolherbst[d]: :ferrisUpsideDown:
11:20 karolherbst[d]: I smell something funny going on
11:20 karolherbst[d]: and your desktop is running and everything?
11:20 godvino[d]: yep
11:20 karolherbst[d]: weird...
11:21 godvino[d]: ahh so got it
11:21 karolherbst[d]: I know that some applications have broken device selection stuff
11:21 godvino[d]: I ran `MESA_VK_DEVICE_SELECT=10de:25ec! DRI_PRIME=10de:25ec! MESA_LOADER_DRIVER_OVERRIDE=zink GSK_RENDERER=vulkan org.gnome.Calculator` and then it happens
11:21 godvino[d]: even after quititng it
11:21 karolherbst[d]: like electron based apps are known for selecting the wrong GPU
11:21 karolherbst[d]: godvino[d]: ....
11:21 karolherbst[d]: why..
11:22 karolherbst[d]: stopping the user session should stop doing that
11:22 godvino[d]: just wanted to check out the shiny new nvk driver
11:23 godvino[d]: I guess the gpu has trouble staying off after getting turned on
11:23 karolherbst[d]: yeah no, I meant, why is it causing this issue :ferrisUpsideDown:
11:23 karolherbst[d]: mhhh
11:23 karolherbst[d]: yeah.. could be
11:23 karolherbst[d]: mind just trying with `lspci` on next reboot?
11:23 godvino[d]: all right
11:23 karolherbst[d]: lspci also wakes up the gpu, and if it keeps waking up, it might actually be some funky kernel bug afterall
11:26 godvino[d]: yep lscpi causes it as well
11:26 godvino[d]: and this its without `nouveau.config=NvGspRm=1`
11:27 godvino[d]: `runtime_status` is stuck in a loop of active suspending suspended resuming
11:28 karolherbst[d]: mind executing this a few times: `grep . /sys/bus/pci/devices/0000\:01\:00.0/power/*` and check if anything else changes?
11:29 godvino[d]: ```Jun 13 16:57:58 fedora kernel: nouveau 0000:01:00.0: gsp: mmu fault queued
11:29 godvino[d]: Jun 13 16:57:58 fedora kernel: nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:56 type:31 scope:1 part:233
11:29 godvino[d]: Jun 13 16:57:58 fedora kernel: nouveau 0000:01:00.0: fifo:c00000:0007:0038:[gnome-calculato[4741]] errored - disabling channel
11:29 godvino[d]: Jun 13 16:57:58 fedora kernel: nouveau 0000:01:00.0: gnome-calculato[4741]: channel 56 killed!
11:29 godvino[d]: ``` got this after closing gnome-calculator
11:29 karolherbst[d]: mhhhhh
11:29 karolherbst[d]: but not after running lspci, right?
11:29 godvino[d]: let me check
11:30 godvino[d]: karolherbst[d]: still the same
11:30 godvino[d]: karolherbst[d]: no errors after running lspci
11:31 godvino[d]: godvino[d]: sometimes this error comes up while gnome-calculator is running and it freezes it with an error about vk_no_device or something in the console
11:32 godvino[d]: ```(gnome-calculator:2): Gdk-CRITICAL **: 17:01:56.678: Vulkan: ../src/nouveau/vulkan/nvk_queue_drm_nouveau.c:486: DRM_NOUVEAU_EXEC failed: No such device (VK_ERROR_DEVICE_LOST)
11:32 godvino[d]: (gnome-calculator:2): Gdk-CRITICAL **: 17:01:56.678: Vulkan: ../src/nouveau/vulkan/nvk_queue.c:285: Submit failed (VK_ERROR_DEVICE_LOST)```
11:32 godvino[d]: this is that error
11:36 karolherbst[d]: yeah.. that's just a mesa bug
11:36 karolherbst[d]: like invalid memory access
11:36 karolherbst[d]: but lspci doesn't use gl or vk or anything, and if you see the GPU to keep getting powered on, then those errors shouldn't cause this behavior anyway
11:39 godvino[d]: even lspci causes the gpu to get powered on
11:39 godvino[d]: just tested after a reboot
11:40 godvino[d]: any idea why is the gpu getting turned on causing a microstutter in gnome ?
11:41 godvino[d]: is that expected ?
11:42 karolherbst[d]: well.. that part isn't expected
11:42 karolherbst[d]: and I have no idea why that happens
11:43 karolherbst[d]: maybe something running wild on the kernel side
11:44 godvino[d]: its annoying af though
11:45 karolherbst[d]: I can imagine
11:45 godvino[d]: atleast it caused me to go down this rabbit hole
11:56 dadschoorse[d]: gfxstrand[d]: do you prefer fne or fneo for an order version of nir_op_fneu?
12:01 karolherbst[d]: let's use `fneo` and then people make weird matrix references
12:02 tiredchiku[d]: Hold your horses Neo
12:04 dadschoorse[d]: fne is more consistent with the other comparison opcodes, fneo might be clearer because most people should use fneu unless they know what they are doing
12:06 asdqueerfromeu[d]: karolherbst[d]: `grnpill.ftz`
14:19 triang3l[d]: dadschoorse[d]: where is it even used :blobcatnotlikethis:
14:19 karolherbst[d]: ~~OpenCL~~
14:19 triang3l[d]: (aside from an optimization pass if the application has decided to do it and there's a hardware instruction)
14:20 karolherbst[d]: though actually I have no idea if CL has it
14:20 karolherbst[d]: 😄
14:20 dadschoorse[d]: spirv has ordered fne, hw has ordered fne
14:20 karolherbst[d]: yeah, a lot of hw has them natively
14:21 dadschoorse[d]: spirv has all the comparisons you could possibly think of
14:34 gfxstrand[d]: dadschoorse[d]: IDK. Probably fneo just to make it clear
14:36 dadschoorse[d]: okay, since idr also prefers fneo I will change my MR then
14:36 gfxstrand[d]: 👍🏻
14:37 gfxstrand[d]: Yeah, I think it's better if we're going to have both to not treat one of them preferentially by dropping the suffix. Make them equals
14:37 gfxstrand[d]: That way people are forced to think about it
14:56 dadschoorse[d]: as long as it's not named fone like in LLVM 🐸
14:57 karolherbst[d]: missed opportunity to name it fneo if you ask me
14:57 asdqueerfromeu[d]: karolherbst[d]: It could also be a nouveau reference (because `neo` means `new` which translates to `nouveau` in French)
15:01 dadschoorse[d]: >LLVMRealONE
15:01 dadschoorse[d]: who thinks of a comparison when seeing that?
15:24 rinlovesyou[d]: tiredchiku[d]: Yeah i ain't doing that
15:24 rinlovesyou[d]: I'll become a Wayland user when plasma 6.1 is out properly
15:25 rinlovesyou[d]: Then it'll work with Nvidia prop 555+ and my global xwayland mouse button keybinds should work
15:28 tiredchiku[d]: so... next week-ish 😅
15:30 rinlovesyou[d]: Yee
15:30 rinlovesyou[d]: Can't wait
16:16 gfxstrand[d]: redsheep[d]: I've got a branch for you to play with. 😁
16:16 gfxstrand[d]: https://gitlab.freedesktop.org/gfxstrand/mesa/-/commits/nvk/cbuf0-rebase
16:17 redsheep[d]: All your rebase are belong to me
16:17 gfxstrand[d]: That one's got all the new toys
16:18 redsheep[d]: Ahem. Yeah looks fun, I'll give it a try
16:18 gfxstrand[d]: I need to do more testing before landing.
16:18 gfxstrand[d]: The Witness is at 130 FPS on my tiny laptop GPU now
16:18 gfxstrand[d]: As opposed to 100
16:18 redsheep[d]: Woah, nice
16:18 rinlovesyou[d]: and i just switched back to prop
16:18 rinlovesyou[d]: kek
16:18 gfxstrand[d]: the cb0 stuff doesn't seem to help much here but I'm only on a 4060. I expect it to help a lot more on your 4090
16:21 redsheep[d]: Does this latest branch still need or would be expected to benefit from any environment variables like no_cbuf?
16:21 gfxstrand[d]: Let me throw one more patch on top
16:32 gfxstrand[d]: Okay, now you don't
16:33 rinlovesyou[d]: alright let's have a lookie
16:45 rinlovesyou[d]: Minecraft shaders, i.e. zink + nvk seems to have regressed in perf, situations that would easily hit 60+ are now around 40-50, although i think on average the FPS are higher, leaves don't seem to take that much away anymore.
16:45 rinlovesyou[d]: Just Cause 4 is still an enigma on what is going on with it, but it at least manages to keep around 30 fps now, 45 in a good situation, and ~75 when you look up into the sky
16:46 gfxstrand[d]: Can you try minecraft without the last patch?
16:51 rinlovesyou[d]: you made two commits uh
16:52 rinlovesyou[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1250855168111546418/image.png?ex=666c7527&is=666b23a7&hm=c0345d7b8277b2f6f8e304ef54d7d5c62b5a7655cca03b5b98e6c0f82e901c59&
16:52 rinlovesyou[d]: which one do you want me to revert to
16:52 rinlovesyou[d]: rinlovesyou[d]: (the minecraft thing is a little better running a zink session, i really don't know why zink refused to work yesterday)
16:55 acedogblast: Hello I have just started using NVK+GSP. VKcube does not work. I have created a bug report on Mesa #11334.
16:56 acedogblast: Additionally I am unable to select the full refresh rate of my monitor.
16:56 redsheep[d]: Yeah unfortunately 24.1.1 and 6.9.3 don't work together correctly
16:57 rinlovesyou[d]: yeah with NVK, at the moment building from source is the best way to use it lol
16:57 redsheep[d]: Or use an rc kernel
16:58 redsheep[d]: Did the patch to fix that make it I to 24.1.2?
16:58 rinlovesyou[d]: <a:shrug:780945071557705758>
16:59 redsheep[d]: acedogblast: What resolution and refresh rate, and what kind of connector?
17:00 acedogblast: 3440x1440 at 165Hz on Displayport
17:01 acedogblast: What is the recomended kernel and mesa version then to use NVK?
17:01 redsheep[d]: I am starting to wonder if that bug is in plasma. I should probably try gnome with my setup one of these days. I also can't use full refresh on one of my 4k displays which should be supported
17:02 redsheep[d]: You should be best off with latest mesa main and gfxstrand nvk branch of Linux, or latest mesa release if you hit issues
17:03 magic_rb[d]: I can confirm that random checkout of mesa and faiths kernel branch works like a charm :)
17:05 redsheep[d]: https://gitlab.freedesktop.org/gfxstrand/linux/-/tree/nvk?ref_type=heads
17:07 tiredchiku[d]: honestly though, I think we're at the point where we should try and avoid breaking $release
17:08 redsheep[d]: For sure. I won't speak for the real developers here, but things seem like they will be much more mature in 6.10 and 24.2
17:10 DodoGTA: acedogblast: The vulkan-nouveau-git package works okay for me with a 6.9.4 kernel
17:12 redsheep[d]: Yeah with the latest mesa it's not broken anymore with kernels that don't have the vm bind stuff for modifiers, but if you want modifiers to work an rc kernel or Faith's branch is best
17:12 Sid127: DodoGTA: they're on KDE Neon
17:31 friendlyinvader[d]: redsheep[d]: Given the issues we were having in Discord channel #tech-talk, would you like to do the whole dance of cross-referencing EDID, /sys/class/drm/, and the kwin configs?
17:34 redsheep[d]: It would be good to, though right this moment my whole session is super messed up for some reason so I won't have time until probably 5 hours from now
17:37 redsheep[d]: Seems like there's some novel issue with 555 open driver that breaks blacklisting it to use nouveau properly, going to have to just uninstall it and figure it out later so I can get in some NVK performance testing
17:39 redsheep[d]: Hmm I probably just messed up my config there, might not be a bug or anything new
17:40 gfxstrand[d]: redsheep[d]: Yeah, 24.1.2 should be good, I think.
17:41 gfxstrand[d]: tiredchiku[d]: Oh, it wasn't for lack of trying. 😅
17:41 tiredchiku[d]: yeah, I know, I'm always watching 😅
17:41 tiredchiku[d]: :watching:
17:42 redsheep[d]: https://tenor.com/view/monsterinc-monsters-inc-gif-5616105356996190790
17:43 tiredchiku[d]: just working on getting myself back on my feet before diving back in full time
17:53 gfxstrand[d]: rinlovesyou[d]: The "don't use bound CBufs" one. That's the only one that I would expect to regress anything.
17:54 redsheep[d]: I just skimmed the patches on that branch, it's huge
17:55 redsheep[d]: You've been busy
17:59 acedogblast: Just built and installed mesa 24.2.0-devel and the problem with vkcube chrashing is gone.
18:06 redsheep[d]: gfxstrand[d]: Ok The Witness results time:
18:06 redsheep[d]: Mesa main baseline: 54 fps
18:06 redsheep[d]: Main with no_cbuf: 96 fps
18:06 redsheep[d]: This branch: 108 fps, nice doubling of current default main performance
18:09 redsheep[d]: Really looking forward to that new gsp support so I can have at least some basic data on utilization, but I fully expect this is still a gpu bind
18:15 redsheep[d]: I just went ahead and installed the branch and I can confirm it is at least stable enough to not immediately and obvious break my zink session
18:17 redsheep[d]: Also, at least on my system the mincraft performance with zink is almost certainly much better, like it's probably averaging nearly 40% higher
18:17 redsheep[d]: That is with vanilla 1.20.2 though, which is going to be a pretty different workload from shaders
18:23 redsheep[d]: It might only be like 20%, but yeah I think it is pretty unlikely this is a regression for vanilla on my machine. Hard to be entirely certain because the game is so inconsistent, but it used to be I would see 500ish as peak, and now peak is over 700
18:36 karolherbst: asdqueerfromeu[d]: yeah, makes sense. NVK is still in heavy development so testing with main or something very new is generally the best idea
18:48 karolherbst: ehh.. wrong ping 🙃
18:53 DodoGTA: karolherbst: The Discord-IRC interop is definitely working (you actually pinged me)
18:54 karolherbst: perfect time to try out another one 👆
18:54 karolherbst: ...
18:54 karolherbst: 🙃
19:12 acedogblast: Where would I post a bug report on not getting all refreshrate/no VRR/no HDR options when using nouveau+GSP+KDE6+Wayland?
19:19 acedogblast: Is the DRM-nouveau a good place for this bug?
19:34 gfxstrand[d]: redsheep[d]: You must be running different settings. I'm gettint 130 on my laptop
19:38 redsheep[d]: gfxstrand[d]: I am running high settings with 8x msaa at 4k
19:41 redsheep[d]: My standard scene is pretty challenging as well, one of the much heavier spots, though not the absolute worst case. Th worst spots are hard to replicate the positioning
19:43 redsheep[d]: I test from the corner of the edge of the stairs up to the top of the mountain, pointed kind of center mass out at the rest of the map at a particularly dark tree in the far distance, if you want to try to replicate
19:44 redsheep[d]: I can screenshot it later if that is too vague
19:48 redsheep[d]: Anyway, combine those conditions with it being much harder to get high occupancy on a big GPU and I'm not all that surprised at higher fps on a smaller one if you have a lighter configuration and/or scene
19:49 gfxstrand[d]: redsheep[d]: Ah, that'll do it. I don't think I have MSAA enabled.
19:50 redsheep[d]: Yeah, what you look at also varies the fps on prop by like 3x best to worst case
19:53 redsheep[d]: There's also that whole thing I ran into before where exactly how you build mesa has a huge and intuitive impact on performance, I don't remember if my current configuration is good or bad for that
19:57 gfxstrand[d]: karolherbst[d]: care to review a NIR patch quick?
19:57 gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591/diffs?commit_id=2e50d0512ade611ae83b5a0af69ed6555e1e4b28
19:58 karolherbst[d]: "quick"
19:58 karolherbst[d]: I trust you enough to just add my r-by tag, but my inner morals say "look..... you gotta review it properly"
19:58 karolherbst[d]: maybe tomorrow when I'm having less of a headache 😄
20:00 karolherbst[d]: ohh wait
20:00 karolherbst[d]: just one patch
20:00 karolherbst[d]: I thought the entire series :ferrisUpsideDown:
20:01 gfxstrand[d]: rinlovesyou[d]: I've got a theory as to why some stuff is regressing. Using bindless cbufs eats a descriptor load and we're still using `ld.global.constant` for that. I've got an idea or two, I just need to figure out which way to go.
20:01 gfxstrand[d]: karolherbst[d]: Oh, goodness no. I don't expect anyone to review 85 out of those 87 patches.
20:01 gfxstrand[d]: Maybe ex post facto if someone really wants to but that series goes DEEP
20:02 gfxstrand[d]: I just want my NIR iterators acked because they're in common NIR.
20:02 karolherbst[d]: yeah, already done :ferrisUpsideDown:
20:02 acedogblast: This is strange. I disabled GSP which gets me back full 165Hz refreshrate.
20:02 karolherbst[d]: acedogblast: yes, this isn't weird, because nouveau hacks around that
20:02 karolherbst[d]: and GSP probably doesn't
20:03 acedogblast: karolherbst[d] are there any plans to fix this in GSP?
20:04 karolherbst[d]: soo the key thing is `Bits per primary color channel: 10`
20:04 karolherbst[d]: and nouveau tries with 8 and 6 as well if 10 needs too much bandwidth
20:04 skeggsb9778[d]: i think that part at least should be the same when running on GSP
20:04 karolherbst[d]: there are two ways to fix it via gsp: maybe we can specify a bits per colors? I have no idea. The other solution is to wire up DSC.. probably
20:04 karolherbst[d]: skeggsb9778[d]: mhh also possible
20:04 skeggsb9778[d]: the KMS driver does it, and doesn't do anything differently on HW vs GSP
20:05 karolherbst[d]: mhhhh
20:05 karolherbst[d]: then it's weird
20:05 karolherbst[d]: maybe GSP reports some different limits or so?
20:05 skeggsb9778[d]: yeah, i'm not sure at all
20:06 skeggsb9778[d]: HDMI or DP?
20:06 karolherbst[d]: who is filtering out modes when using GSP anyway?
20:06 karolherbst[d]: or rather
20:06 karolherbst[d]: what's giving nouveau the list of modes
20:06 skeggsb9778[d]: well, that's why i asked what connector
20:06 acedogblast: This is on DisplayPort
20:07 skeggsb9778[d]: for DP we're fetching the EDID ourselves, but on HDMI we're asking RM
20:07 karolherbst[d]: skeggsb9778[d]: ohh btw, if you have some time, wiring up HDMI 2.1 would be a huge thing. I have some prototype code but it kinda never worked and I never got the time to really fix it: https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/eba81849b9310e6bb06c3543a9d562ff6548d235
20:07 karolherbst[d]: probably the wrong order
20:08 karolherbst[d]: probably `NV0073_CTRL_CMD_SPECIFIC_SET_HDMI_FRL_CONFIG` is just at the wrong place
20:09 skeggsb9778[d]: Is there more to implementing it than just that?
20:09 skeggsb9778[d]:thought it'd be harder :P
20:09 karolherbst[d]: I don't think so
20:09 karolherbst[d]: I haven't found anything
20:09 karolherbst[d]: and I read some nvidia code for it
20:09 karolherbst[d]: that was the only thing standing out we aren't doing related to HDMI 2.1/FRL
20:10 skeggsb9778[d]: Oh. Hm, I'll take a look at it then. I'd thought implementing some of the newer display stuff would've required bigger reworks, that'd be better suited for new rust kms code
20:10 skeggsb9778[d]: If there's low-hanging fruit though, that'd be good to do!
20:12 karolherbst[d]: yeah... but I've got told that HDMI 2.1 support was added in such a way, that you don't need approval from the HDMI folks, who denied it for AMD already :ferrisUpsideDown:
20:12 karolherbst[d]: sooo, it should really only be telling GSP what to do and all the magic happens in closed source code
20:13 karolherbst[d]: anyway, I probably just picked the wrong spot. I can test any patches as I have the hardware requiring HDMI 2.1 😄
20:16 karolherbst[d]: ohh.. I hardcoded the `.data = NV0073_CTRL_HDMI_FRL_DATA_SET_FRL_RATE_3LANES_6G,` part, because that matched my setup and was for testing
20:16 karolherbst[d]: disp complained, maybe I have the error somewhere
20:16 skeggsb9778[d]: yeah, ok, so what i was thinking of is something called "2 heads 1 OR", and would be necessary for certain higher rate modes
20:17 skeggsb9778[d]: (ones where the pixel clock is more than a single head can drive)
20:17 karolherbst[d]: skeggsb9778[d]: https://gist.github.com/karolherbst/baded64645b9fdedb126e252798ecf49 I think?
20:17 karolherbst[d]: ahh
20:17 karolherbst[d]: I mean.. we can also just support certain FRL modes just to give users a few higher rated modes for now
20:17 skeggsb9778[d]: there seems to be a bunch of other miscellaneous things in OpenRM around FRL in nvkms-hdmi.c too, which could be worth a look
20:18 skeggsb9778[d]: yeah, that'd be fine too 🙂
20:20 karolherbst[d]: my 4K@120 TV needs FRL and without it I only get @60, so if we don't need that 2 heads 1 OR thing for @120 that would be great
20:20 karolherbst[d]: I think NVK reaches the level where 4@120 gaming isn't impossible anymore
20:21 redsheep[d]: Oh certainly not impossible with lighter games, or titles that happen to work well
20:21 redsheep[d]: Even just in the desktop it's a real drag to be stuck at 60
20:21 karolherbst[d]: 😄
20:21 karolherbst[d]: yeah
20:21 karolherbst[d]: I really can't choose between high refresh rate and high resolution gaming
20:21 karolherbst[d]: :blobcatnotlikethis:
20:22 karolherbst[d]: high resolution looks soooo good sometimes
20:22 redsheep[d]: Get one of the new 32" 4k240 OLED panels and get the best of all worlds
20:22 karolherbst[d]: look.. that would mean I need to spend 5k on GPUs :ferrisUpsideDown:
20:23 karolherbst[d]: but yeah.. I'm thinking of getting a 4K144 OLED one or something
20:23 karolherbst[d]: at least higher than 60
20:24 redsheep[d]: You can always just upscale games that don't run fast enough, more native pixels with higher refresh is never worse
20:24 redsheep[d]: And really 240hz OLED isn't much more than regular high refresh 4k
20:25 redsheep[d]: At least not in the US with the $950 MSI model
20:25 karolherbst[d]: I mostly want VRR though
20:26 karolherbst[d]: the weird stuttering is what annoys me the most
20:26 karolherbst[d]: with anything really
20:26 karolherbst[d]: not just gaming
20:26 redsheep[d]: Mmm yeah get an LCD then. I find that with enough native refresh rate having it off is better, especially on an OLED where very will cause flicker and flashing
20:27 karolherbst[d]: sounds like low quality OLED if it flickers/flashes
20:27 karolherbst[d]: but is VRR on OLED really that bad?
20:27 redsheep[d]: No, it really is a complicated problem
20:29 redsheep[d]: My lg c2 isn't low quality or anything, it works okay on amd, but only because they did a load of engineering to make it so the mechanism controlling luminance is super well tuned
20:29 redsheep[d]: Working OLED VRR is essentially freesync premium exclusive
20:30 karolherbst[d]: sounds like it depends on the display a lot
20:33 redsheep[d]: Kinda? I don't think anybody has it really cracked, except maybe Asus on their OLED zephyrus laptops where they do something funky with specific intervals at 8x the refresh rate where it's allowed to start scanning out
20:34 redsheep[d]: Which isn't a truly variable refresh rate IMO, but it is close
20:35 redsheep[d]: Here's hoping Blackwell will bring a massive upgrade to the display engine on Nvidia and we can stop having only the AMD gpus implementing these things well
21:19 gfxstrand[d]: Maybe I want to use bound cbufs fir the first 64k of the first 8 or so descriptor sets
21:25 asdqueerfromeu[d]: gfxstrand[d]: *for
21:28 gfxstrand[d]: rinlovesyou[d]: If you want to try minecraft again, I pushed another patch. If that fixes the regression, that'll at least tell me what's going on so I can come up with a proper plan.
21:29 redsheep[d]: Hey that's cool, sleep mode works on nouveau now, that was broken last time I tried
21:32 gfxstrand[d]: Yeah, airlied[d] fixed that a few weeks ago
21:32 gfxstrand[d]: My laptop GPU is usable for debugging now.
21:38 redsheep[d]: If that improved The Witness it was by less than 3%, as for minecraft it might be better but not by enough to cut through the enormous amount of noise from chunk loading and garbage collection
21:39 redsheep[d]: Of course I can't speak to the more difficult performance case, improving on 700 fps isn't worth a ton
21:41 rinlovesyou[d]: Yeah without shaders Minecraft runs great
21:41 rinlovesyou[d]: My tests are with shaders on the highest settings as a benchmark
21:41 rinlovesyou[d]: I'll give it a try when I'm back at my pc
21:42 redsheep[d]: gfxstrand[d]: What I can comment on is that while this regresses Talos by less than the other previous branches, it is still overall a regression of about 5% versus main
21:50 redsheep[d]: It's weird, talos in particular must be doing something really slow but that is surprising to me considering its vulkan usage should be really basic by modern standards. I don't have msaa on, and my test location puts me at 76 fps. Prop gets 3-4x the performance
21:51 redsheep[d]: At this point NVK is probably above half of prop in The Witness now
21:51 rinlovesyou[d]: yeah i'd say the same thing
21:51 rinlovesyou[d]: it's definitely less of a regression, but still a bit slower than upstream
21:54 redsheep[d]: Have you tested main with NVK_DEBUG=no_cbuf? I wonder if that would be better or worse than default
21:54 rinlovesyou[d]: worse
21:54 rinlovesyou[d]: i tried no_cbuf on main a while ago, it would push the scene that's normally around 70fps to 45
21:54 redsheep[d]: Hmm okay, that's pretty drastic
21:55 rinlovesyou[d]: from the way i understand it this branch acts as if no_cbuf was on, so it's basically having to offset whatever perf penalty is incurred from that
21:55 rinlovesyou[d]: certainly doing a good job, that same scene is now around 65fps on this branch
21:56 redsheep[d]: Afaict with the latest commit there is a little more nuance than that, but yeah
22:01 rinlovesyou[d]: redsheep[d]: just cause 4 can't even keep a stable 60fps at 720p on lowerst settings, but that's on main too, that's the most curious game in my library
22:02 rinlovesyou[d]: along with Yakuza 0/Kiwami, which run great now but freeze (graphically) in combat, even though they're pretty old and run on dxvk
22:04 redsheep[d]: Yeah there are still some nasty performance edge cases, it seems doom eternal still runs slow, getting 22 fps
22:09 friendlyinvader[d]: I'm still needing to figure out a better solution for running and updating multiple kernels <a:think360fast:436713965129695233>
22:13 redsheep[d]: Oh yeah I should probably grab that display stuff you were curious about
22:22 redsheep[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1250938273530908752/kdoc.txt?ex=666cc28d&is=666b710d&hm=adb0dda349a0c4ec29482c7397c474637553225b14dde88bfd21770c81f33859&
22:22 redsheep[d]: friendlyinvader[d]: Here's the output of `kscreen-doctor -o`
22:22 redsheep[d]: The correct 3840x2160@119 or 120 doesn't exist here
22:23 redsheep[d]: It would be on the displayport display, DP-3
22:24 redsheep[d]: Also xrandr doesn't have it, but I can force the mode with xrandr and it works
22:28 redsheep[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1250939769312116856/edid.txt?ex=666cc3f2&is=666b7272&hm=d7b664eac8a3dcf8e0fc2658a9a52024048ad63e8662f8f0eae78b178909f891&
22:28 redsheep[d]: Here's the edid too
22:28 friendlyinvader[d]: Are you using xorg?
22:28 redsheep[d]: I am, yeah. It doesn't work on wayland either
22:29 friendlyinvader[d]: I'm noticing one of the blocks failed decode there <a:SCLOADING:715824432450633749>
22:29 redsheep[d]: And yeah according to this decoded edid there's no 120hz mode, guess it is in that other block?
22:30 friendlyinvader[d]: I'm used to seeing a lot of timing information in block 2, but that doesn't mean much
22:30 friendlyinvader[d]: As in I'm used to seeing block 2 just be modes for the native resolution of the panel
22:31 friendlyinvader[d]: 3840x2160x30
22:31 friendlyinvader[d]: 3840x2160x60
22:31 friendlyinvader[d]: 3840x2160x120
22:31 friendlyinvader[d]: etc.
22:32 redsheep[d]: Yeah when I have looked at the edid on windows there's definitely a 4k120 mode, but I do think it is in a separate block. So that is the issue I guess? Parsing edid somewhere?
22:33 redsheep[d]: I don't really understand the layering well enough to know what is broken
22:33 friendlyinvader[d]: Which I find to be interesting, because block 1 has an extra byte in it that it's complaining about
22:36 friendlyinvader[d]: It looks like it's just a duplicate of block 0 though
22:37 friendlyinvader[d]: <a:SCLOADING:715824432450633749>
22:40 redsheep[d]: I mean... is the edid corrupt and windows is overriding? That doesn't seem like it could possibly be true, this worked fine on amdgpu
22:47 gfxstrand[d]: rinlovesyou[d]: Is that with the new patch?
22:54 rinlovesyou[d]: yes
23:12 gfxstrand[d]: Cool. That tells me that it probably isn't bindless CBufs that are the problem but getting the descriptors for them.