03:53fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> If Wine has the :josh_blue: patch of course 🐸
03:55fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Can you disable NAK with `NVK_USE_NAK=0`? Hopefully NAK doesn't cause a regression here
05:45fdobridge: <gfxstrand> You could also bisect if the crash is easy to reproduce. Sometimes knowing exactly what commit caused it is enough information to fix the bug.
05:51fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> That's what I've done for Wine quite a few times
05:51fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I've even done one micro-bisecting
05:51fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I've even done one micro-bisect (edited)
06:01fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> GTA 3 on NVK + winewayland (least stable gaming setup) :triangle_nvk:
06:01fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1174590094842282057/Screenshot_20231116_080034.png?ex=65682545&is=6555b045&hm=f17d650adef9a9966501752844ed94ff4bafe75cc54ed42457335782146ac5e8&
08:08fdobridge: <mupuf> Dang guys, congratulations on finally being able to run other games than starcraft 2 on nouveau!
08:16fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Do you like that strategy game?
10:08fdobridge: <mupuf> Oh, I *never* gamed on Nouveau. I was just working on the kernel side, that was my fun 😉
10:09fdobridge: <mupuf> but bskeggs and Christoph were the starcraft 2 heads
10:09fdobridge: <mupuf> and nouveau mostly stopped evolving on the mesa side once this was working reliably. After that, it was mostly keeping up with new gpus
10:10fdobridge: <karolherbst🐧🦀> https://nouveau.freedesktop.org/FeatureMatrix.html :3
10:10fdobridge: <karolherbst🐧🦀> I've updated the "power management" row today
10:10fdobridge: <karolherbst🐧🦀> :ferrisSmug:
10:10fdobridge: <karolherbst🐧🦀> it's so good to see that
10:10fdobridge: <karolherbst🐧🦀> not sure if I should choose `DONE`
10:10fdobridge: <karolherbst🐧🦀> but we should verify it all works properly first 😄
10:11fdobridge: <karolherbst🐧🦀> though I think it works...
10:11fdobridge: <karolherbst🐧🦀> but it still needs work I think
10:11fdobridge: <mupuf> @karolherbst : you need to update that one: https://nouveau.freedesktop.org/PowerManagement.html
10:11fdobridge: <karolherbst🐧🦀> yeah...
10:11fdobridge: <karolherbst🐧🦀> but it uses the old table
10:11fdobridge: <karolherbst🐧🦀> and I'm lazy
10:11fdobridge: <mupuf> lol
10:11fdobridge: <karolherbst🐧🦀> I wait for Skelly to wake up and do it for me 😄
10:12fdobridge: <mupuf> anyway, the main feature matrix table should be split in two
10:12fdobridge: <mupuf> the pre-maxwell 2, and the post maxwel2
10:12fdobridge: <karolherbst🐧🦀> probably
10:12fdobridge:<karolherbst🐧🦀> though
10:12fdobridge: <mupuf> and let's maybe stop using NV*** notation, it stopped making sense with Fermi
10:12fdobridge: <karolherbst🐧🦀> I think the actual split will the pre-GSP and post GSP
10:13fdobridge: <mupuf> that would be an acceptable split
10:13fdobridge: <karolherbst🐧🦀> ~~probably one which is gonna to happen anyway~~
10:13fdobridge: <karolherbst🐧🦀> like people do plan a GSP only driver going forward
10:14fdobridge: <karolherbst🐧🦀> and it makes perfect sense
10:14fdobridge: <mupuf> agreed
10:14fdobridge: <mupuf> I liked airlied's talk
10:14fdobridge: <karolherbst🐧🦀> same
10:15fdobridge: <mupuf> although he seems a little fuzzy on dates 😄
10:15fdobridge: <mohamexiety> sadly it's not really likely people will use pre GSP stuff anyway. no reclocking _hurts_
10:15fdobridge: <karolherbst🐧🦀> anyway, if somebody has enough motivation to pimp the wiki's content, that would be great 😄
10:16fdobridge: <mupuf> Tell me about it...
10:16fdobridge: <karolherbst🐧🦀> well.. people still use NV30
10:16fdobridge: <karolherbst🐧🦀> and we do have reclocking on kepler 😄
10:16fdobridge: <karolherbst🐧🦀> kinda
10:16fdobridge: <mupuf> you know what sucks? It took me 3 days to get reclocking on my laptop... in 2010
10:16fdobridge: <karolherbst🐧🦀> heh
10:16fdobridge: <mohamexiety> oof..
10:16fdobridge: <mupuf> yet... I never managed to make it work *everywhere*
10:16fdobridge: <karolherbst🐧🦀> but back then the stuff was pretty straightforward.. well besides VRAM
10:16fdobridge: <karolherbst🐧🦀> VRAM is always pain
10:17fdobridge: <mupuf> if anything, it became easier with newer gens
10:17fdobridge: <karolherbst🐧🦀> yeah.. well.. the vbios parsing became more complex in exchange
10:17fdobridge: <mupuf> more complex... but more uniform
10:17fdobridge: <karolherbst🐧🦀> right
10:17fdobridge: <mupuf> whereas it felt like older chips were always different, for no particular reason
10:17fdobridge: <karolherbst🐧🦀> luckily we won't have to RE those turing PM tables
10:18fdobridge: <karolherbst🐧🦀> I think...
10:18fdobridge: <mupuf> and honestly, in retrospect, someone should have REed the driver and documented that, rather than us working with traces
10:18fdobridge: <karolherbst🐧🦀> yeah.. maybe
10:18fdobridge: <mupuf> but that would have meant this person would not have been free to do anything else but that
10:18fdobridge: <karolherbst🐧🦀> I don't think that reing nvidias driver would have worked
10:19fdobridge: <karolherbst🐧🦀> they don't even have a stable UAPI internaly
10:19fdobridge: <karolherbst🐧🦀> and even GSP changes a lot
10:19fdobridge: <karolherbst🐧🦀> they really don't care about any API they have
10:19fdobridge: <karolherbst🐧🦀> so every driver version probably would mean a full new RE
10:19fdobridge: <mupuf> how is that relevant? What we needed was hardware documentation, not driver
10:19fdobridge: <mupuf> and knowing what to check, which bits, and what's different between gens
10:19fdobridge: <karolherbst🐧🦀> yeah.. but after every driver update you could throw away your RE work on the driver
10:20fdobridge: <karolherbst🐧🦀> and start from scratch every single time
10:20fdobridge: <mupuf> nah, pick one, document everything... Then maybe you could see how things evolve by diffing... but I doubt it would have been super helpful anyway
10:20fdobridge: <karolherbst🐧🦀> well.. I was thinking of new hardware bringup
10:21fdobridge: <karolherbst🐧🦀> but yeah...
10:21fdobridge: <karolherbst🐧🦀> now it's just one driver for the old hardware (more or less) but still
10:21fdobridge: <mupuf> but yeah, anyway, I for one welcome our GSP overlord
10:21fdobridge: <karolherbst🐧🦀> I wonder how long distributions can ignore the situation 😄
10:22fdobridge: <mupuf> I was hoping PDAEMON would become the power management UC...
10:22fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> How well does it work?
10:22fdobridge: <karolherbst🐧🦀> well.. all those things still exist
10:22fdobridge: <mupuf> Like everything: if the gpu was tested by a dev... it probably works well
10:22fdobridge: <karolherbst🐧🦀> GSP is just booting the other processors
10:22fdobridge: <karolherbst🐧🦀> and is doing RPC stuff
10:22fdobridge: <mupuf> but for all the other variants... it likely won't work
10:23fdobridge: <karolherbst🐧🦀> GSP is more like a SEC2 on steroids
10:23fdobridge: <mupuf> yeah, but that's irrelevant, isn't it?
10:23fdobridge: <mupuf> now, our interface is GSP
10:23fdobridge: <karolherbst🐧🦀> ohh sure, for us it doesn't matter
10:23fdobridge: <karolherbst🐧🦀> though
10:23fdobridge: <mupuf> and you can't do much with the rest
10:23fdobridge: <karolherbst🐧🦀> we still have to manage the engines
10:23fdobridge: <karolherbst🐧🦀> kinda
10:23fdobridge: <karolherbst🐧🦀> it's a bit weird
10:23fdobridge: <mupuf> Leaky interfaces...
10:24fdobridge: <karolherbst🐧🦀> it's more about enabling disabling them I think? not sure
10:24fdobridge: <karolherbst🐧🦀> we do have some code to even deal with nvdec/nvenc because $reasons
10:24fdobridge: <karolherbst🐧🦀> `drivers/gpu/drm/nouveau/nvkm/engine/nvenc/r535.c` e.g. 🥲
10:24fdobridge: <karolherbst🐧🦀> but that's mostly just the object level stuff
10:24fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Who will address the Darien Gap of nouveau though? 🐸
10:25fdobridge: <karolherbst🐧🦀> but yeah...
10:25fdobridge: <mupuf> Do you want one driver that is actually usable by a small portion of people, or do you want everyone to have the same shitty level of support?
10:26fdobridge: <mupuf> The former can grow from a niche to become more and more general; the latter is just a recipe for burnout
10:27fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I mean there's a gap of TODOs between NV110 and NV160 in the power management row
10:27fdobridge: <karolherbst🐧🦀> yeah...
10:27fdobridge: <mupuf> yep, I understood you 🙂
10:27fdobridge: <karolherbst🐧🦀> probably not happening
10:27fdobridge: <karolherbst🐧🦀> unless somebody with a lot of spare time is around
10:27fdobridge: <mupuf> and my take is: path of least resistance!
10:27fdobridge: <karolherbst🐧🦀> and by that I mean _a lot_ of spare time
10:27fdobridge: <mupuf> work on what's easy, make the driver useful for some gpus
10:28fdobridge: <mupuf> then, maybe, potentially, someone might be interested in porting that to older gpus
10:28fdobridge: <karolherbst🐧🦀> PM for that gap also includes legal problems
10:28fdobridge: <karolherbst🐧🦀> I mean.. sure.. we can leak the signing key and all that, but also...
10:29fdobridge: <mupuf> oh yeah, 100%. But the workaround isn't impossible either: just like we did for video decoding firmwares, we could use nvidia's firmware for these generations
10:29fdobridge: <karolherbst🐧🦀> well....
10:29fdobridge: <karolherbst🐧🦀> then you are in the distribution problem area
10:29fdobridge: <karolherbst🐧🦀> fedora and others probably won't ship it by default
10:29fdobridge: <karolherbst🐧🦀> and then it's kinda useless
10:30fdobridge: <mupuf> right, so instead people would have to download and install the blob... how is that harder?
10:30fdobridge: <karolherbst🐧🦀> `apt install nvidia-driver`
10:30fdobridge: <mupuf> not on fedora, nor debian 😉
10:30fdobridge: <karolherbst🐧🦀> okay.. you add a ppa/copr/repo first
10:30fdobridge: <mupuf> see, I can use your logic against yours :p
10:31fdobridge: <mupuf> so, you could add a ppa/copr/repo first, or just run a script that would download and extract the firmware for you
10:31fdobridge: <mupuf> done
10:31fdobridge: <mupuf> see, no functional difference
10:31fdobridge: <mupuf> it is shitty, but it isn't worse than the current solution
10:31fdobridge: <karolherbst🐧🦀> yeah, fair
10:31fdobridge: <mupuf> the real issue is: who would find it fun to do?
10:32fdobridge: <mupuf> I, for one, did not find it fun
10:32RSpliet: mupuf: well your three-day binge code worked on your laptop until you also plugged in a projector at demo-time, and realised that waiting until *both* screens are in their vblank period was a bad idea xD
10:32fdobridge: <mupuf> YES! That was hilarious
10:33fdobridge: <mupuf> but yeah, it proves my point
10:34fdobridge: <mupuf> in 3 days I got it working well-enough for my needs.... but then the scope keeps widening and it becomes too much
10:35fdobridge: <karolherbst🐧🦀> reminds me of some of the BSD devs who are like "let's write AMD GPU drivers from scratch, I just make it work on my GPU and how much work would it be to make it work everywhere else" and then the project dies a month later
10:35fdobridge: <karolherbst🐧🦀> *and microkernel ones
10:35fdobridge: <mupuf> yep, this extreme also sucks
10:36fdobridge: <karolherbst🐧🦀> but I like how they all refuse to port the linux drivers, $because_the_architecture_is_wrong
10:36fdobridge: <karolherbst🐧🦀> anyway...
10:37fdobridge: <mupuf> Yeah, the only sensible thing to do is forklifting DRM
10:37fdobridge: <karolherbst🐧🦀> which...
10:37fdobridge: <karolherbst🐧🦀> is hard
10:37fdobridge: <karolherbst🐧🦀> because that also pulls in Linux mm
10:37fdobridge: <mupuf> sure, but it isn't something that changes that fast
10:37fdobridge: <karolherbst🐧🦀> no, but it might conflict with their MM
10:37fdobridge: <mupuf> but it is also ... not fun
10:37fdobridge: <karolherbst🐧🦀> especially if they are like a microkernel 😄
10:37fdobridge: <mupuf> oh, right
10:37fdobridge: <mupuf> but freebsd did it
10:37fdobridge: <karolherbst🐧🦀> yeah
10:37RSpliet: mupuf: and the upstream kernel never felt like the place where we could improve iteratively. The milestones you had to hit to be able to check something in felt pretty big
10:37fdobridge: <karolherbst🐧🦀> only sane way of doing it
10:38fdobridge: <karolherbst🐧🦀> I've discuss it sometimes wiht microkernel devs and they are like "yeah, we do the GPU MM in userspace" - "what about DMA?" - "also that" - ".... okay....."
10:38mupuf: RSpliet: yeah... for power management, you really want to be conservative :s
10:39fdobridge: <mohamexiety> so what do you work on these days?
10:39fdobridge: <mupuf> to be fair, nvidia does memory management in userspace
10:39fdobridge: <karolherbst🐧🦀> yeah.. but they don't expose physical addresses do they?
10:39fdobridge: <karolherbst🐧🦀> mean.. configuring the DMA engine in userspace...
10:39RSpliet: mupuf: yes, but also when/while code is disabled by default and hidden behind a "enable it, I know what I'm doing" switch the balance can shift a bit towards progressive
10:40fdobridge: <karolherbst🐧🦀> I mean. we also kinda do VM management in userspace, just to a lesser extreme than nvidia now
10:40RSpliet: It's happened to me, I worked on Fermi until I ran out of steam, and because the code was like 50% of the way to get one card to reclock it's now collecting dust in a private repo for nobody to look at it and improve further
10:41fdobridge: <mupuf> I worked at Intel from 2015 to 2020, ended up the testing architect for the i915 driver. Nowadays, I work with Valve on automated testing and the occasional bug fix here and there.
10:41fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> And speaking of BSDs does NVK compile on FreeB(a)S(e)D? 😈
10:41fdobridge: <karolherbst🐧🦀> the issue isn't GL/VK placing their buffers in a VM, it's more like whacking the page tables with physical addresses
10:41fdobridge: <mupuf> for sparse, you mean?
10:41fdobridge: <karolherbst🐧🦀> generally
10:41RSpliet: The fermi code I did write could easily live upstream to either bit-rot or someone else to pick it up, as it's disabled, but it felt like a faux pas to bring it forward
10:41fdobridge: <karolherbst🐧🦀> we have a couple of drivers who manage their own VM in userspace
10:41fdobridge: <karolherbst🐧🦀> it's nothing special
10:42fdobridge: <karolherbst🐧🦀> the question is, who is responsible for filling the page tables
10:42fdobridge: <mupuf> Rspliet: indeed, I guess the culture wasn't to land things early and iterate. I partly blame the kernel's development workflow here
10:42RSpliet: mupuf: my words exactly ;-)
10:43fdobridge: <mohamexiety> \:o I see, that's quite nice
10:43fdobridge: <karolherbst🐧🦀> but yeah.. virtual addresses are in userspace control for quite a while (for nouveau just this year, but still)
10:44fdobridge: <mupuf> right, but the kernel still allocates the memory
10:45fdobridge: <karolherbst🐧🦀> yeah.. the kernel still adjusts the page tables
10:46RSpliet: as long as user-space can't go and say "yeah just map address 0x13370000 to this physical page right there... in some other application/context's buffer" I'm happy :D
10:46fdobridge: <karolherbst🐧🦀> sure
10:46fdobridge: <karolherbst🐧🦀> but that's what micro kernel devs want to do
10:46fdobridge: <karolherbst🐧🦀> even with DMA
10:46fdobridge: <karolherbst🐧🦀> apparently privileged processes whacking random system RAM isn't a threat model
10:47fdobridge: <karolherbst🐧🦀> or at least the ones I've spoken to
10:47fdobridge: <karolherbst🐧🦀> some even claimed linux root processes have access to all RAM, which isn't even true :ferrisUpsideDown:
10:48fdobridge: <karolherbst🐧🦀> though I guess root processes could abuse GPU's DMA for that.....
10:48fdobridge: <karolherbst🐧🦀> though I think the kernel prevents some of that fun stuff...
10:48fdobridge: <mupuf> Root can mmap /dev/mem... so yeah, pretty much has access to everything 😄
10:49fdobridge: <karolherbst🐧🦀> well
10:49fdobridge: <karolherbst🐧🦀> `/dev/mem` is just device memory
10:49fdobridge: <karolherbst🐧🦀> RAM access got removed
10:49fdobridge: <karolherbst🐧🦀> or is behind a flag or something
10:49fdobridge: <mupuf> indeed, just read that
10:49fdobridge: <mupuf> good good
10:49fdobridge: <karolherbst🐧🦀> yeah
10:49fdobridge: <karolherbst🐧🦀> but still.. can use devices to access RAM :ferrisUpsideDown: but we also have IOMMUs
10:50fdobridge: <karolherbst🐧🦀> sooo...
10:50fdobridge: <mupuf> Who is we? Only AMD enables it by default
10:50fdobridge: <karolherbst🐧🦀> yeah....
10:50fdobridge: <karolherbst🐧🦀> that's the sad part
10:51fdobridge: <karolherbst🐧🦀> one should check if the GSP stuff works with IOMMU enabled 😄
10:51fdobridge: <mupuf> kernel devs should always enable IOMMUs!
10:51fdobridge: <mupuf> they catch so many bug
10:51fdobridge: <mupuf> s
10:51fdobridge: <karolherbst🐧🦀> I think I have it enabled on my desktop at least
10:51fdobridge: <mupuf> and if you have a discrete GPU, the cost is tiny
10:52fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I think I had IOMMU enabled and GSP still works
10:52fdobridge: <mupuf> (for integrated, it is massive)
10:52fdobridge: <karolherbst🐧🦀> nouveau is pretty much iommu error free, there is just one bug with the strictest IOMMU mode
10:52fdobridge: <karolherbst🐧🦀> or something
10:52fdobridge: <karolherbst🐧🦀> yeah.. it's kinda odd
10:52fdobridge: <karolherbst🐧🦀> intel has various modes and most of them trigger nothing
10:52fdobridge: <karolherbst🐧🦀> so there is that
10:53fdobridge: <karolherbst🐧🦀> how did you enable it? 😄
10:53fdobridge: <karolherbst🐧🦀> there is this special value to make it more aggressive
10:54fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> `amd_iommu=on iommu=p`
10:54fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> `amd_iommu=on iommu=pt` (edited)
10:54fdobridge: <karolherbst🐧🦀> might need `iommu.strict=1`
10:55HdkR: Stick the card in an ARM machine, watch all your iommu accesses explode.
10:55HdkR: :)
10:55fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I can't stick a BGA GPU
10:58HdkR: Pluck the BGA GPU out of the device and glue it to the Raspberry Pi
10:59HdkR: But really, with how crap most ARM device's PCIe connections are, it's a good way to find out where you've done unaligned accesses in to uncached iommu memory
11:39fdobridge: <karolherbst🐧🦀> it is done
11:42fdobridge: <karolherbst🐧🦀> https://nouveau.pages.freedesktop.org/-/wiki/-/jobs/51654141/artifacts/public/PowerManagement.html :ferrisBongo:
11:43fdobridge: <karolherbst🐧🦀> ehh I should mark all as done
11:44fdobridge: <karolherbst🐧🦀> hwmon is something else :ferrisUpsideDown:
12:05fdobridge: <mupuf> You need to add new lines: Automatic reclocking
12:05fdobridge: <mupuf> You need to add a new line: Automatic reclocking (edited)
12:05fdobridge: <karolherbst🐧🦀> ohh good point
12:05fdobridge: <mupuf> well, you probably need to add new lines: Control about the reclocking policy
12:05fdobridge: <mupuf> and have it as TODO
12:07fdobridge: <karolherbst🐧🦀> meh 😄
12:07fdobridge: <karolherbst🐧🦀> don't spoil our green row
12:08fdobridge: <airlied> I'd say nouveau conservative policy was mostly driven by Ben, he really didn't like putting unfinished code out
12:08fdobridge: <karolherbst🐧🦀> I even have automatic reclocking WIP patches 🥲
12:08fdobridge: <karolherbst🐧🦀> in case somebody is very bored
12:08fdobridge: <karolherbst🐧🦀> worked great btw
12:08fdobridge: <karolherbst🐧🦀> managed to do 1000 reclocks a second for minutes without crashing my GPU
12:09fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> On Kepler?
12:09fdobridge: <karolherbst🐧🦀> yeah
12:09fdobridge: <karolherbst🐧🦀> all PMU assisted
12:09fdobridge: <karolherbst🐧🦀> so the PMU polls the engine idle counters and tells the kernel to reclock
12:09fdobridge: <karolherbst🐧🦀> had low/high thresholds and all that fun stuff
12:10fdobridge: <pac85> What is the pmu?
12:10fdobridge: <karolherbst🐧🦀> power management unit
12:10fdobridge: <karolherbst🐧🦀> so part of it was written in firmware
12:10fdobridge: <pac85> Uhm I see
12:10fdobridge: <pac85> Cool
12:11fdobridge: <karolherbst🐧🦀> touch pages
12:11fdobridge: <karolherbst🐧🦀> index: https://nouveau.pages.freedesktop.org/-/wiki/-/jobs/51656498/artifacts/public/index.html
12:11fdobridge: <karolherbst🐧🦀> features: https://nouveau.pages.freedesktop.org/-/wiki/-/jobs/51656498/artifacts/public/FeatureMatrix.html
12:11fdobridge: <karolherbst🐧🦀> pm: https://nouveau.pages.freedesktop.org/-/wiki/-/jobs/51656498/artifacts/public/PowerManagement.html
12:11fdobridge: <karolherbst🐧🦀> maybe I should move `Automatic Reclocking` a bit up
12:12fdobridge: <karolherbst🐧🦀> any comments? otherwise I'll merge
12:12fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I see some misinformation in here
12:12fdobridge: <karolherbst🐧🦀> yes
12:12fdobridge: <karolherbst🐧🦀> 😄
12:13fdobridge: <karolherbst🐧🦀> I don't want to fix everything
12:13fdobridge: <karolherbst🐧🦀> here is the MR: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/35
12:15fdobridge: <karolherbst🐧🦀> ohh wait.. one cell has the wrong color
12:15fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I mean add a GSP note for NV160+ in the thermal sensors row
12:16fdobridge: <karolherbst🐧🦀> mhhh
12:16fdobridge: <karolherbst🐧🦀> well
12:16fdobridge: <karolherbst🐧🦀> GSP is taking care of it
12:16fdobridge: <karolherbst🐧🦀> hwmon isn't part of power management
12:16fdobridge: <karolherbst🐧🦀> that should be its own entry in the feature matrix I think
12:16fdobridge: <karolherbst🐧🦀> or maybe its own row there
12:16fdobridge: <karolherbst🐧🦀> but it also doesn't matter
12:30RSpliet: karolherbst: iirc the show-stopper for having proper DVFS was configuring the pixel buffer feeding the scanout logic - at least up until Kepler (including some Kepler cards, not sure there)
12:30RSpliet: I think they called that thing the non-iso buffer
12:30karolherbst: right...
12:31RSpliet: And it would allow us to take DRAM offline and reclock memory without starving scanout logic - so that we wouldn't get flicker on multi-monitor set-ups during a reclock
12:31karolherbst: I'm not saying it was perfect, but it worked fine on my hybrid gpu laptops :D
12:31karolherbst: but yeah.. I think the ones trying it out on desktops had flickering and such
12:32RSpliet: yep. Don't think that buffer was that difficult to configure. It was just a fixed-size SRAM that you could choose how to split between the two active displays (before Kepler started allowing 4 displays that is)
12:32RSpliet: Probably a good split would be along the ratio of pixel clocks
12:32RSpliet: But... well, nobody looked at it, myself included :D
12:33fdobridge: <mupuf> I had forgotten about that. At Intel, I spent a lot of time discussing about this with the engineers so that I could use this knowledge for Nouveau
12:33karolherbst: it apparently also improves performance for reasons
12:33fdobridge: <mupuf> I never did... but mostly because Intel's design was obviously stupid and not matching what nvidia did
12:34RSpliet: oh I'm sure it does, if you can buffer DRAM bursts of data instead of trying to drip-feed from DRAM you'll get better DRAM throughput :-)
12:34fdobridge: <mupuf> I would assume the default behaviour is to have the watermarks set to the maximum value: AKA, always refilling the buffer when there is even a single byte available in the FIFO
12:34fdobridge: <mupuf> What Roy said 🙂
12:35fdobridge: <mupuf> what really is nice with nvidia's memory controler is that the display really has the higher priority. I once experimented with downclocking memory to 50MHz and display was still working
12:36fdobridge: <mupuf> (on a full-hd screen)
12:37RSpliet: mupuf: I've written a paper about how it is prioritised over context switches :-P Well, that wasn't the angle I took, but it's a conclusion you can draw from the data :D
12:37fdobridge: <mupuf> Yeah, definitely my favourite paper about nouveau!
12:38RSpliet: Out of... two? Three? :D
12:38fdobridge: <mupuf> at least two 😄
14:01fdobridge: <marysaka> @gfxstrand found the issue, it was load_frag_w not passing the offset and instead undef, causing it to reuse a register that contains undefined data in cause of IPA.OFFSET 😅
14:31fdobridge: <gfxstrand> Right... That'll do it. 😅
14:32fdobridge: <gfxstrand> Stick the fix in your barycentrics MR. I think it's time to pull that one in. (I do still need to review it a bit more.)
14:34fdobridge: <marysaka> Preparing that now
14:39fdobridge: <marysaka> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26224
14:45fdobridge: <marysaka> @gfxstrand found the issue, it was load_frag_w not passing the offset and instead undef, causing it to reuse a register that contains undefined data in case of IPA.OFFSET 😅 (edited)
15:57fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I guess I'm going to file bug reports for 2 of my RenderDoc'd issues soon :triangle_nvk:
16:07fdobridge: <gfxstrand> Please do! Now that we're passing the CTS, I think it's time to start looking at app traces. As long as they're on Turing or later, go ahead and file bugs.
16:23fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Hopefully my slightly modified NVK build is fine (otherwise I would be stuck with DXVK v1.5.1 (which is quite ancient and possibly has its own bugs) and no PCSX2)
16:30fdobridge: <gfxstrand> It's probably fine(ish). I think we have most of the features DXVK cares about, we just don't have 1.3
17:00fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Here's the first bug report: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10156 (feel free to report any issues with it)
17:18fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> And the second one: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10157
17:50fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Where should I report an issue that only happens with GSP enabled but exists on both NVK and nouveau OpenGL? :nouveau:
17:54fdobridge: <mhenning> probably https://gitlab.freedesktop.org/drm/nouveau/-/issues
17:55fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> There's a lot of zero comment issues there but I'll try reporting an issue there anyway
17:56fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> The issue is that I don't know if my issue only happens on my system (so someone needs to reproduce it I guess)
18:15fdobridge: <gfxstrand> Ooh, looks like the assert you're seeing might actually tell us what's going on with the bug. 😄
18:16fdobridge: <gfxstrand> Let me pull the trace and give it a try
18:16fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> It happens on both Overwatch 2 and GTA 3 traces
18:16fdobridge: <gfxstrand> Yeah, they're both clearly a blending bug and that assert failing is probably really useful informaiton
18:17fdobridge: <gfxstrand> Pulling renderdoc now...
18:36fdobridge: <gfxstrand> @asdqueerfromeu I might need your hacks to replay the trace. Mind pushing your branch somewhere?
18:38fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> All the patches that I used for my build can be found here: https://aur.archlinux.org/packages/vulkan-nouveau-git (I can make a branch with all of them applied if you want)
18:39fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I also have some `sed` stuff which is required too (so I guess making a branch might be more convenient)
18:48fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> @gfxstrand https://gitlab.freedesktop.org/DodoGTA/mesa-nvk/-/commits/nvk/aur-changes :triangle_nvk:
18:49fdobridge: <gfxstrand> Oh, right... I should do sync2 for real
18:50fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> This includes everything except the RenderDoc hack (so basically the same patches as in the AUR package)
18:52fdobridge: <gfxstrand> hrm... it's not asserting.
18:53fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> i wonder if the pipeline caching patch is causing the issue
18:54fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> It adds a lot of tests though
19:03fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I'm certain the pipeline caching patch isn't causing the Overwatch 2 glitches though (because they existed with the old uAPI and before NVK was merged to Mesa)
20:36fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I managed to crash NVK again :cursedgears:
20:36fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1174810146879328426/message.txt?ex=6568f235&is=65567d35&hm=a6b849163eff524d8a9dda19c54816252da0c5774a451dee8b7881f3dd5df17f&
20:43fdobridge: <karolherbst🐧🦀> nice
20:56fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> I replayed someone else's trace of LEGO Worlds in D3D11 mode to see if NVK has shader flickering issues too (but NVK hit the ground as well once the player hit the ground)
21:07fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> NVK can run a trace of GTA 4 fully :triangle_nvk:
21:07fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1174818076705960077/Screenshot_20231116_230605.png?ex=6568f998&is=65568498&hm=fa5b7092e8adc64e4300d49611e64441f9d1c66f7f12351e7fed38c1d71e17f6&
21:30fdobridge: <esdrastarsis> ```
21:30fdobridge: <esdrastarsis> thread '<unnamed>' panicked at ../mesa/src/nouveau/compiler/nak.rs:340:34:
21:30fdobridge: <esdrastarsis> Invalid gl_tess_spacing
21:30fdobridge: <esdrastarsis> ```
21:30fdobridge: <esdrastarsis> Strange Brigade error
21:37fdobridge: <gfxstrand> Spicy! 🌶️
21:39fdobridge: <esdrastarsis> Could it be TESS_SPACING_UNSPECIFIED?
21:39fdobridge: <esdrastarsis> Could it be `TESS_SPACING_UNSPECIFIED`? (edited)
21:40fdobridge: <gfxstrand> Possibly but we should git rid of that earlier
21:40fdobridge: <gfxstrand> It's been a bit since I've thought through what `TESS_SPACING_UNSPECIFIED` even means
21:45fdobridge: <benjaminl> kinda tempted to go through NAK and replace all the `panic!("invalid foo")` with `panic!("invalid foo: {actual_value}")` to make debugging things like this easier
21:45fdobridge: <benjaminl> is an MR for that likely to be accepted?
22:18fdobridge: <gfxstrand> Go for it!
22:18fdobridge: <gfxstrand> My only recommendation would be to try and do it in sensible pieces. Like, do unhandled opcodes in NIR, then unhandled enums. Then maybe various assertions in encode_sm70.
22:19fdobridge: <gfxstrand> That way the reviewer (me) is kinda looking at the same thing in every patch
22:20fdobridge: <benjaminl> yeah, that makes sense
22:21fdobridge: <benjaminl> probably also add some commits to swap `assert!(a == b)` for `assert_eq!(a, b)` and such, but I'll split that out so we could remove them easily
22:22gfxstrand: Sure
22:31fdobridge: <gfxstrand> Woo! NAK assembly in RenderDoc:
22:31fdobridge: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1174839163959390278/image.png?ex=65690d3c&is=6556983c&hm=24de00f3f36d65a645e063658eb58484b744e2e6c46a5ce9879071556db11747&
22:31fdobridge: <karolherbst🐧🦀> nice!
22:34fdobridge: <marysaka> now that's great :vibrate:
22:34fdobridge: <pac85> Wow I'm seeing so many exciting updates tonight, congrats!
22:38fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26241
22:41fdobridge: <gfxstrand> We probably want to expose a few more stats over time, but those three should get us going with shader-db as well.
22:42fdobridge: <gfxstrand> With codegen, we'll get stats but no assmebly. Only NAK has assembly hooked up. But I think that's okay.
22:43fdobridge: <gfxstrand> I think I just confused Marge... 🤦🏻♀️
22:46fdobridge: <gfxstrand> Unfortunately, with the GTA trace, even clicking on shaders with codegen just blows up everything. 🙃