00:10 fdobridge: <g​fxstrand> @airlied While we're messing about, it'd be great if you could rebase the linux-firmware copr
00:11 fdobridge: <g​fxstrand> I've updated grub and am attempting an install
00:27 fdobridge: <a​irlied> okay throwing into copr in a fewmins
00:35 fdobridge: <a​irlied> https://copr.fedorainfracloud.org/coprs/airlied/nouveau-gsp/build/6593115/ will be it when it finished
00:38 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> NAK is still too slow to replace codegen (and it only supports Turing)
00:39 fdobridge: <g​fxstrand> Thanks!
00:52 fdobridge: <a​irlied> okay dropped in on my f39 machine and installed a kernel with nouveau.config=NvGspRm=1 on command line and it at least boots 🙂
01:04 fdobridge: <g​fxstrand> Woo
01:09 fdobridge: <g​fxstrand> I've got my 780 in my box right now and not enough power for both that and the 2060 (1 kW PSU coming tomorrow) so I'll play with it later.
03:17 fdobridge: <a​irlied> okay sent the gsp pullreq to Linus, we shalll see if we make 6.7 or 6.8
03:30 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Hopefully he doesn't accidentally drop it 🍁
03:32 fdobridge: <a​irlied> I said it was optional for 6.7 so he will hopefully tell me yes or no 🙂
08:54 fdobridge: <r​hed0x> assuming it does get merged, what are the next steps?
08:58 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Basically you have to install the GSP firmware and set a kernel command line option on pre-Ada (once you've installed the new kernel)
09:00 fdobridge: <r​hed0x> no, I mean what work needs to happen on it
09:04 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> The first part (that has various display fixes) has already been merged so hwmon support is one of the missing features when using GSP
09:49 fdobridge: <a​irlied> Not sure how hwmon would work, also svm faults need work
10:36 fdobridge: <k​arolherbst🐧🦀> could have a worker thread which polls GSP every 10 seconds or so
10:36 fdobridge: <k​arolherbst🐧🦀> and with `*sleep_range` might not even hurt too much
10:36 fdobridge: <k​arolherbst🐧🦀> and then hwmon just returns cached values
10:42 fdobridge: <k​arolherbst🐧🦀> what's the actual problem here btw?
10:42 fdobridge: <k​arolherbst🐧🦀> we do have the interfaces to GSP for that afaik
11:24 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> 10 seconds 🐢
11:24 fdobridge: <k​arolherbst🐧🦀> well.. it's good enough
11:24 fdobridge: <k​arolherbst🐧🦀> I think nvidia polls like every 5 seconds?
11:24 fdobridge: <k​arolherbst🐧🦀> or maybe they just cache it?|
11:25 fdobridge: <k​arolherbst🐧🦀> something something
12:30 mupuf: airlied: oh, I was just coming to ask about the GSP situation :D
12:31 mupuf: "hwmon support is one of the missing features when using GSP" --> I feel called out
12:32 mupuf: karolherbst: please don't do that. Can't you call the GSP every time someone asks for the temperature?
12:32 mupuf: Just set the update property to 5s, and the userspace will know how often to poll
12:33 karolherbst: the thing is, that some people use like UI applications
12:33 mupuf: whoever gets to it first, I have been allowed to spend some time doing review for Nouveau... so I guess hwmon would be something I can actually help with
12:33 karolherbst: and they poll everything at once
12:33 karolherbst: and they might do so every second
12:33 karolherbst: and each value probably would be one RPC call
12:33 mupuf: and? It's not efficient but... does it matter?
12:33 karolherbst: it might be too slow
12:34 karolherbst: or causes other issues
12:34 karolherbst: also not very efficient anyway
12:34 mupuf: I would hope the RPC interface would be fast-enough for these not to matter
12:34 karolherbst: I think there is just one RPC to give us everything at once
12:34 mupuf: premature optimization is the root of all evil ;)
12:34 mupuf: well, at least there is that
12:34 karolherbst: we could also just cache it for x seconds
12:34 mupuf: yeah, that sounds sane
12:35 karolherbst: like hwmon does a request, we fetch everything and then just use that for a while
12:35 mupuf: +1 for that
12:37 mupuf: Honestly, the real question here is going to be the mapping from GSP to HWMON's interface
12:37 karolherbst: yeah
12:38 karolherbst: some things like temperature are probably straightforward
12:38 karolherbst: maybe we even have fan rpms
12:38 karolherbst: power consumption? probably as well, but the question is doe we get one or multiple values?
12:38 karolherbst: a lot of unknowns :)
12:39 mupuf: oh, it isn't documented what they expose?
12:39 mupuf: I would expect somewhat the same structure as what the thermal vbios table would container
12:39 karolherbst: uhh.. I just don't remember, I've looked at the header though
12:39 mupuf: contain*
12:39 karolherbst: let me find it
12:46 karolherbst: can't find it anymore :'(
14:24 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I just updated the nouveau-fw-gsp package to the more recent firmware: https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=nouveau-fw-gsp&id=59b755901bdecfa6c93d7eeaed7d2edc56dc5b90
15:21 fdobridge: <g​fxstrand> Annoyingly, `NVK_DEBUG=push_dump` doesn't dump QMDs...
15:21 fdobridge: <k​arolherbst🐧🦀> yeah.. I've talked with @marysaka about that
15:21 fdobridge: <k​arolherbst🐧🦀> the dumper might want to get a context and parse some of the interesting things
15:21 fdobridge: <k​arolherbst🐧🦀> so it could dump QMDs, shaders, macros, etc...
15:22 fdobridge: <k​arolherbst🐧🦀> or maybe a callback to the runtime to return the blob
15:22 fdobridge: <k​arolherbst🐧🦀> something something
15:22 fdobridge: <g​fxstrand> Yeah, that's the way the Intel dumper works.
15:27 fdobridge: <m​arysaka> yeah...
15:33 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> That term seems pretty obscure (does it mean `Queue Meta Data`?)
15:34 fdobridge: <k​arolherbst🐧🦀> correct
15:38 fdobridge: <g​fxstrand> Ugh... we're not handling relocs
15:38 fdobridge: <k​arolherbst🐧🦀> do we need them for kepler?
15:38 fdobridge: <g​fxstrand> Where do those even come from?
15:39 fdobridge: <k​arolherbst🐧🦀> ohh.. you mean the codegen stuff? uhhh
15:39 fdobridge: <k​arolherbst🐧🦀> that shouldn't happen after tesla...
15:39 fdobridge: <k​arolherbst🐧🦀> ehh wait..
15:39 fdobridge: <k​arolherbst🐧🦀> we do...
15:39 fdobridge: <k​arolherbst🐧🦀> pain
15:39 fdobridge: <k​arolherbst🐧🦀> it's for the builtin stuff 🥲
15:40 fdobridge: <k​arolherbst🐧🦀> @gfxstrand just lower opcodes
15:40 fdobridge: <k​arolherbst🐧🦀> in nir
15:40 fdobridge: <g​fxstrand> Only for OP_CALL
15:40 fdobridge: <k​arolherbst🐧🦀> yeah
15:40 fdobridge: <k​arolherbst🐧🦀> that's for integer division mostly I think
15:40 fdobridge: <k​arolherbst🐧🦀> or so..
15:40 fdobridge: <k​arolherbst🐧🦀> anyway
15:40 fdobridge: <k​arolherbst🐧🦀> lower it on the nir level
15:42 fdobridge: <g​fxstrand> Yeah, I'm not worried about that. I was more worried I had relocations
15:42 fdobridge: <g​fxstrand> But I don't. I added an assert
15:48 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> How important is lowering for NAK? :ferris:
15:49 fdobridge: <g​fxstrand> Every compiler employs some amount of lowering somewhere. NAK tries to do as much up-front in NIR as it can.
15:49 fdobridge: <g​fxstrand> There isn't even control-flow in this shader. How is it going wrong depending on address?!?
16:00 fdobridge: <k​arolherbst🐧🦀> that would rather sound like an alignment issue....
16:00 fdobridge: <k​arolherbst🐧🦀> but yeah...
16:25 fdobridge: <g​fxstrand> Alignment doesn't make sense either
16:42 fdobridge: <g​fxstrand> 0x000, 0x100, 0x200, 0x300 all work, 0x400 doesn't
16:43 fdobridge: <g​fxstrand> I wonder if the GPU is tiling my shader buffer
16:43 fdobridge: <g​fxstrand> I wonder if the GPU is tiling my shader heap (edited)
16:55 fdobridge: <k​arolherbst🐧🦀> there is some cache involved, but not sure how much that one is relevant here
17:00 fdobridge: <g​fxstrand> Okay, playing with PTE kinds is definitely doing something. 🤦🏻‍♀️
17:01 fdobridge: <g​fxstrand> IDK if I should be poking at the old UAPI or not...
17:02 fdobridge: <g​fxstrand> PTE stuff definitely changed at Maxwell
17:02 fdobridge: <g​fxstrand> pascal, rather
17:04 fdobridge: <k​arolherbst🐧🦀> yeah.. might be worth a try to see if it's indeed an UAPI issue or not
17:04 fdobridge: <k​arolherbst🐧🦀> but also.. pain
17:04 fdobridge: <k​arolherbst🐧🦀> not sure why it would really matter
17:05 fdobridge: <g​fxstrand> Like I said, this feels a whole lot like someone is tiling my shader heap
17:05 fdobridge: <g​fxstrand> Which sounds like PTEs messed up somehow
17:05 fdobridge: <g​fxstrand> the old UAPI takes a different, presumably working, path.
17:06 fdobridge: <k​arolherbst🐧🦀> mhhh.. yeah, could be
17:09 fdobridge: <g​fxstrand> Old API doesn't seem any better
17:13 fdobridge: <g​fxstrand> I wonder of this is why the GL driver likes to push so much stuff through DMAs
17:17 fdobridge: <g​fxstrand> Like, it can't be my map being screwed up. 0x400 is still inside a tile
17:18 fdobridge: <g​fxstrand> Like, it can't be my map being screwed up. 0x400 is still inside a page (edited)
17:19 fdobridge: <g​fxstrand> I bet my shader at 0x400 is still somewhere. I just need to find it.
17:39 fdobridge: <k​arolherbst🐧🦀> but where would it be honestly?
17:40 fdobridge: <k​arolherbst🐧🦀> maybe it's just some cache flushing afterall
17:45 fdobridge: <g​fxstrand> If I fill the whole heap with my shader....
17:46 fdobridge: <g​fxstrand> It's at 0x0000, 0x0100, 0x0200, 0x0300, 0x2000, 0x1f00, 0x1e00, 0x1d00, 0x1c00
17:46 fdobridge: <g​fxstrand> I can't find it anywhere else.
17:46 fdobridge:<k​arolherbst🐧🦀> odd
17:46 fdobridge: <g​fxstrand> It's not at 0x0400, 0x0500, 0x0600, 0x0700, 0x1a00, or 0x1b00
17:47 fdobridge: <k​arolherbst🐧🦀> what if you upload it via dma?
17:47 fdobridge: <k​arolherbst🐧🦀> like the command buffer stuff
17:47 fdobridge: <g​fxstrand> I haven't tried that
17:47 fdobridge: <g​fxstrand> We don't really have infra for that in NVK right now
17:47 fdobridge: <g​fxstrand> I'm debating if I type it or keep going
17:47 fdobridge: <k​arolherbst🐧🦀> mhh, yeah...
17:48 fdobridge: <k​arolherbst🐧🦀> it's good to have as a helper anyway
17:48 fdobridge: <k​arolherbst🐧🦀> is the buffer coherent and everything?
17:48 fdobridge: <k​arolherbst🐧🦀> (and also mapped as such)
17:48 fdobridge: <g​fxstrand> When my shader is at 0x0000, everything works.
17:48 fdobridge: <g​fxstrand> Shader executes, dEQP checks the result buffer okay
17:48 fdobridge: <g​fxstrand> And the shader writes 9.0f to a buffer, so I'm pretty sure it's doing things
17:49 fdobridge: <k​arolherbst🐧🦀> anyway, I'd check how the buffer is created and if it's a coherent one, because if not, that _might_ explain things
17:49 fdobridge: <g​fxstrand> hrm...
17:50 fdobridge: <g​fxstrand> Yeah, placing it in GART works.
17:50 fdobridge: <g​fxstrand> Maybe PCIe maps are broken
17:51 fdobridge: <k​arolherbst🐧🦀> pain
17:51 fdobridge: <g​fxstrand> Not hitting some VRAM banks or something
17:51 fdobridge: <k​arolherbst🐧🦀> but yeah.. uploading data via the pushbuffer solves all those caching issues :ferrisUpsideDown:
17:51 fdobridge: <g​fxstrand> Yeah but it also sucks. 😦
17:52 fdobridge: <k​arolherbst🐧🦀> yeah...
17:52 fdobridge: <k​arolherbst🐧🦀> it's fine in GL, but I can see how it's annoying in vulkan
17:53 fdobridge: <g​fxstrand> Yeah, in Vulkan, I basically have to have a queue of uploads that gets flushed periodically
17:53 fdobridge: <k​arolherbst🐧🦀> yeah
17:53 gfxstrand: dakr: ^^
17:53 gfxstrand: If you want something to look into
17:53 fdobridge: <k​arolherbst🐧🦀> I wonder if we can make VRAM mappings coherent or something...
17:53 gfxstrand: I can get VRAM maps on Kepler but they seem very weirdly busted.
17:54 fdobridge: <g​fxstrand> I mean, typically they-re write-combine
17:54 fdobridge: <g​fxstrand> But who knows if they actually work.
17:54 fdobridge: <k​arolherbst🐧🦀> yeah...
17:54 fdobridge: <k​arolherbst🐧🦀> no idea
17:54 fdobridge: <k​arolherbst🐧🦀> I'm sure there is a reason we've never used it in gl
17:54 fdobridge: <k​arolherbst🐧🦀> like.. nvidia probably also never done it in gl this way
17:54 fdobridge: <g​fxstrand> I'm sure there's *a* reason. I'm not sure it's a good one.
17:54 fdobridge: <g​fxstrand> 😝
17:55 fdobridge: <k​arolherbst🐧🦀> right
17:55 fdobridge: <k​arolherbst🐧🦀> but some parts are also just "copy nvidia" 😄
17:55 fdobridge: <k​arolherbst🐧🦀> but yeah...
17:55 fdobridge: <k​arolherbst🐧🦀> I think in GL nvidia generally uploads via the push buffers
17:55 fdobridge: <k​arolherbst🐧🦀> maybe they changed it
17:55 fdobridge: <k​arolherbst🐧🦀> but I know that in the traces I've seen in the past they don't map upload them
17:58 fdobridge: <g​fxstrand> The thing that really sucks about having to do them via DMA is that shader deletes have to check if there's an upload pending for that shader and flush the queue if there is.
17:58 fdobridge: <g​fxstrand> Or we have to refcount or something
17:58 fdobridge: <k​arolherbst🐧🦀> yeah...
17:58 fdobridge: <k​arolherbst🐧🦀> or just use GART on kepler 🤷
17:58 fdobridge: <g​fxstrand> Which would mean a delete can fail. Yeah, we don't want that.
17:58 fdobridge: <g​fxstrand> GART on kepler is the short-term plan
17:59 fdobridge: <k​arolherbst🐧🦀> mhhh
17:59 fdobridge: <k​arolherbst🐧🦀> could track dirty memory ranges and do the upload where the heap gets bound as well
17:59 fdobridge: <k​arolherbst🐧🦀> ehh wait
18:00 fdobridge: <k​arolherbst🐧🦀> it keeps the same VM address, no?
18:00 fdobridge: <g​fxstrand> yeah
18:00 fdobridge: <k​arolherbst🐧🦀> mhhh
18:00 fdobridge: <g​fxstrand> well, sort-of
18:00 fdobridge: <g​fxstrand> Ugh... resizes
18:00 fdobridge: <k​arolherbst🐧🦀> 🙂
18:00 fdobridge: <g​fxstrand> But that's okay. I can flush the queue on resize.
18:00 fdobridge: <k​arolherbst🐧🦀> yeah..
18:00 fdobridge: <k​arolherbst🐧🦀> what you could do is to upload dirty ranges of the shader heap bo on dynamic state tracking
18:00 fdobridge: <k​arolherbst🐧🦀> and use those helpers we have in mesa for that
18:00 fdobridge: <g​fxstrand> But ugh... This is a hidden queue which means that in a multi-queue setup, every vkQueueSubmit() has to flush it and wait on it with a syncobj.
18:01 fdobridge: <g​fxstrand> yuck
18:01 fdobridge: <g​fxstrand> I can abstract around it but yuck
18:01 fdobridge: <k​arolherbst🐧🦀> uhhh..
18:01 fdobridge: <g​fxstrand> GART for now seems better
18:01 fdobridge: <k​arolherbst🐧🦀> right
18:01 fdobridge: <k​arolherbst🐧🦀> yeah... pre turing that all sucks 😄
18:01 fdobridge: <k​arolherbst🐧🦀> I can totally see why nvidia moved aware from that
18:01 fdobridge: <k​arolherbst🐧🦀> *away
18:02 fdobridge: <g​fxstrand> Maxwell seems fine
18:03 fdobridge: <k​arolherbst🐧🦀> pain
18:03 fdobridge: <k​arolherbst🐧🦀> I think there have been signfiicant changes in the memory controller on maxwell, so that might be related
18:05 fdobridge: <g​fxstrand> ```
18:05 fdobridge: <g​fxstrand> Test run totals:
18:05 fdobridge: <g​fxstrand> Passed: 283/303 (93.4%)
18:05 fdobridge: <g​fxstrand> Failed: 0/303 (0.0%)
18:05 fdobridge: <g​fxstrand> Not supported: 20/303 (6.6%)
18:05 fdobridge: <g​fxstrand> Warnings: 0/303 (0.0%)
18:05 fdobridge: <g​fxstrand> Waived: 0/303 (0.0%)
18:05 fdobridge: <g​fxstrand> ```
18:05 fdobridge: <g​fxstrand> That's ssbo.basic_types
18:06 fdobridge: <g​fxstrand> That would certainly explain it, yes.
18:07 fdobridge: <k​arolherbst🐧🦀> not sure which gen it was exactly, but they changed a lot there
18:07 fdobridge: <k​arolherbst🐧🦀> we kinda had 2.5 gens of kepler and 2 gens of maxwell
18:07 fdobridge: <k​arolherbst🐧🦀> what kepler and maxwell did you test it on?
18:08 fdobridge: <k​arolherbst🐧🦀> also
18:08 fdobridge: <k​arolherbst🐧🦀> looks like 2nd gen maxwell got the new mmu code
18:09 fdobridge: <k​arolherbst🐧🦀> but yeah..
18:10 fdobridge: <k​arolherbst🐧🦀> 2nd gen maxwell also has updated PTE types
18:15 fdobridge: <g​fxstrand> But my 750 TI is fine
18:15 fdobridge: <g​fxstrand> That should be Maxwell A, shouldn't it?
18:16 fdobridge: <g​fxstrand> NVIDIA website says it
18:16 fdobridge: <g​fxstrand> NVIDIA website says it is (edited)
18:21 gfxstrand: dakr: My NVIDIA guy who knows everything doesn't remember VRAM mappings being broken on Kepler so he suspects we're doing something wrong in nouveau.ko
18:21 gfxstrand: dakr: Sadly, I don't think we really have a good reference to look at for HW that old. OGK doesn't even have Kepler headers.
18:22 fdobridge: <g​fxstrand> ```
18:22 fdobridge: <g​fxstrand> Test run totals:
18:22 fdobridge: <g​fxstrand> Passed: 5952/12160 (48.9%)
18:22 fdobridge: <g​fxstrand> Failed: 17/12160 (0.1%)
18:22 fdobridge: <g​fxstrand> Not supported: 6191/12160 (50.9%)
18:22 fdobridge: <g​fxstrand> Warnings: 0/12160 (0.0%)
18:22 fdobridge: <g​fxstrand> Waived: 0/12160 (0.0%)
18:22 fdobridge: <g​fxstrand> ```
18:22 fdobridge: <g​fxstrand> That's all the SSBO tests. The missing 17 are probably codegen failing to RA. 🙃
18:23 fdobridge: <g​fxstrand> We're off to the races now!
18:25 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26035
18:25 fdobridge: <g​fxstrand> Time to do another CTS run
18:26 fdobridge: <k​arolherbst🐧🦀> mhhhh.. yeah, that's odd, as that one should use the same kernel code as kepler...
18:26 fdobridge: <k​arolherbst🐧🦀> but it can still be a nouveau bug
18:30 fdobridge: <g​fxstrand> imageLoad seems busted
18:33 fdobridge: <g​fxstrand> Does suld not handle formats on Kepler?
18:34 fdobridge: <g​fxstrand> vulkaninfo says no...
18:38 fdobridge: <g​fxstrand> I guess it's possible bindless is busted
18:42 fdobridge: <g​fxstrand> What is it fetching from c0?!?
18:42 fdobridge: <g​fxstrand> What is it fetching from c1?!? (edited)
18:44 fdobridge: <g​fxstrand> Oh, this is the image lowering nonsense
18:45 fdobridge: <k​arolherbst🐧🦀> correct
18:46 fdobridge: <g​fxstrand> Yeah, there's no way we can plumb that through right now
18:46 fdobridge: <g​fxstrand> That sucks
18:46 fdobridge: <k​arolherbst🐧🦀> I think nvidia limited kepler to vk 1.2
18:46 fdobridge: <g​fxstrand> That was for other reasons
18:46 fdobridge: <k​arolherbst🐧🦀> right..
18:46 fdobridge: <k​arolherbst🐧🦀> but yeah... for kepler we can't do format lowering in any sane way
18:47 fdobridge: <k​arolherbst🐧🦀> *conversion
18:47 fdobridge: <g​fxstrand> The problem is that we need to pull all this stuff from the descriptor set, not some compiler-decided cbuf
18:47 fdobridge: <g​fxstrand> We solved this on Intel because everything pre-SKL needs lowering
18:47 fdobridge: <k​arolherbst🐧🦀> pain
18:48 fdobridge: <g​fxstrand> It's not too bad. You just do the lowering in NIR
18:49 fdobridge: <k​arolherbst🐧🦀> if we already have it, it might indeed be not too bad
18:50 fdobridge: <g​fxstrand> We did that lowering in NIR because then we could share between vec4 and fs back-ends
18:50 fdobridge: <g​fxstrand> Then I just had to rework it a bit and I could deploy it for VK
19:05 fdobridge: <g​fxstrand> It sucks that so much stuff uses storage images
19:05 fdobridge: <g​fxstrand> `Pass: 12160, Fail: 6, Crash: 2202, Skip: 130130, Flake: 2, Duration: 3:25, Remaining: 1:31:04`
19:06 fdobridge: <k​arolherbst🐧🦀> oof
19:07 fdobridge: <g​fxstrand> Still, only 6 fails in the first 3.5 minutes is pretty encouraging.
19:08 fdobridge: <g​fxstrand> If it's less than 200 or so and most of my crashes are the assert I just added, I'm going to say Kepler works.
19:13 fdobridge: <k​arolherbst🐧🦀> yeah.. there isn't really good reasons why kepler shouldn't 🙂
19:13 fdobridge: <g​fxstrand> Well, VRAM maps. 😛
19:15 fdobridge: <k​arolherbst🐧🦀> right.. but that's an unexpected reason 😛
19:15 fdobridge: <k​arolherbst🐧🦀> I'd be more worried about the nil stuff
19:15 fdobridge: <k​arolherbst🐧🦀> but also...
19:24 fdobridge: <g​fxstrand> NIL checks out according to my image layout fuzzer
19:25 fdobridge: <k​arolherbst🐧🦀> col
19:25 fdobridge: <k​arolherbst🐧🦀> *cool
19:25 fdobridge: <g​fxstrand> Well, the machine didn't survive
19:25 fdobridge: <g​fxstrand> Let's try this again. 😅
19:26 fdobridge: <k​arolherbst🐧🦀> :ferrisUwU:
20:05 fdobridge: <g​fxstrand> RIP
20:05 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1170091440165093436/message.txt?ex=6557c792&is=65455292&hm=0098426656b576f4e85672471209bab6b6819d7394d95a3f45da6e51babadf0e&
20:07 fdobridge: <k​arolherbst🐧🦀> mhhhhh
20:09 fdobridge: <k​arolherbst🐧🦀> I wished I'd know what the reg nouveau waits on to change would do
20:09 fdobridge: <k​arolherbst🐧🦀> `PFIFO_FLUSH.FLUSH_CTRL` mhhh
20:09 fdobridge: <k​arolherbst🐧🦀> bit 2 means `BUSY`... odd
20:10 fdobridge: <k​arolherbst🐧🦀> @gfxstrand mind dumping the content of that reg on timeout? though not sure if `nvkm_msec` returns an error or not...
20:20 fdobridge: <g​fxstrand> It took the whole machine down. 😢
20:21 fdobridge: <k​arolherbst🐧🦀> yeah....
20:21 fdobridge: <k​arolherbst🐧🦀> it's kinda a known issue
20:21 fdobridge: <k​arolherbst🐧🦀> somehow the GPU stops doing stuff
20:22 fdobridge: <k​arolherbst🐧🦀> but a bug like that is also a pain to trigger
20:22 fdobridge: <k​arolherbst🐧🦀> so what it's doing is to trigger a cache flush, but that never completes
20:23 fdobridge: <k​arolherbst🐧🦀> and the GPU not doing anything else also kinda means it's kinda toast
20:27 fdobridge: <g​fxstrand> deqp-runner on Kepler hits it pretty reliably. 😂
20:40 fdobridge: <k​arolherbst🐧🦀> fair enough. Maybe I can try to figure this one out then
21:11 fdobridge: <g​fxstrand> I'm running on @airlied's GSP branch FWIW
22:32 fdobridge: <k​arolherbst🐧🦀> mhhh
22:32 fdobridge: <k​arolherbst🐧🦀> given that I've seen that error before, I doubt it's related 😄
22:32 fdobridge: <k​arolherbst🐧🦀> but yeah.. maybe makes it more likely or whatever
22:34 fdobridge: <p​homes> I was thinking that it could be a fun project for the evening to see if I could fix a visual glitch in Serious Sam on nvk
22:34 fdobridge: <p​homes> I have been looking at various things without spotting anything wrong. Perhaps someone here has an idea of where I should even begin to look? 🙂
22:35 fdobridge: <p​homes> https://cdn.discordapp.com/attachments/1034184951790305330/1170129050904297552/Screenshot_from_2023-11-03_22-20-06.png?ex=6557ea99&is=65457599&hm=d9017e7482dbb77dd55567b425ced61513fbe7325265cd17b9a07bd864e7a803&
22:35 fdobridge: <p​homes> The shadows drawn in the top left corner should have covered the entire screen. The long lines along the top and left should not be there
22:35 fdobridge: <k​arolherbst🐧🦀> the shadow?
22:35 fdobridge: <k​arolherbst🐧🦀> right...
22:36 fdobridge: <k​arolherbst🐧🦀> mhhhh
22:36 fdobridge: <k​arolherbst🐧🦀> looks like some scaling problem
22:36 fdobridge: <p​homes> I looked at a capture with RenderDoc and there we do have a 2D color attachment of the same size as the screen
22:36 fdobridge: <k​arolherbst🐧🦀> mhh
22:36 fdobridge: <k​arolherbst🐧🦀> MSAA enabled/disabled?
22:36 fdobridge: <p​homes> the color attachment is what is in the lower right
22:36 fdobridge: <k​arolherbst🐧🦀> but uhhh
22:36 fdobridge: <k​arolherbst🐧🦀> weird
22:37 fdobridge: <k​arolherbst🐧🦀> it looks like something up with coords in texturing
22:37 fdobridge: <k​arolherbst🐧🦀> it's obviously clamping to the border
22:37 fdobridge: <k​arolherbst🐧🦀> it's obviously clamping to the edge (edited)
22:37 fdobridge: <p​homes> MSAA disabled
22:38 fdobridge: <p​homes> samler is clamp to edge for U and V
22:38 fdobridge: <k​arolherbst🐧🦀> right
22:38 fdobridge: <k​arolherbst🐧🦀> make it look funky my switching the clamp mode to repeat 😄
22:38 fdobridge: <k​arolherbst🐧🦀> *by
22:39 fdobridge: <k​arolherbst🐧🦀> I'd at least try it, to verify it's something with coords
22:39 fdobridge: <p​homes> I will try that
22:39 fdobridge: <k​arolherbst🐧🦀> please post a screenshot as I want to know how it looks like 😄
22:42 fdobridge: <p​homes> https://cdn.discordapp.com/attachments/1034184951790305330/1170130815699648603/Screenshot_from_2023-11-03_23-41-47.png?ex=6557ec3e&is=6545773e&hm=2b8aad7550fd67aa270cf9964ea5a9662f44c48734a7cebb75aac0f084d47df8&
22:42 fdobridge: <k​arolherbst🐧🦀> mhhh
22:42 fdobridge: <k​arolherbst🐧🦀> I was thinking mirror_repeat, but uhhh
22:42 fdobridge: <k​arolherbst🐧🦀> 😄
22:42 fdobridge:<k​arolherbst🐧🦀> anyway
22:43 fdobridge: <k​arolherbst🐧🦀> so it's something fucked up with coords
22:43 fdobridge: <k​arolherbst🐧🦀> I'm sure mirror_repeat looks way better
22:43 fdobridge: <k​arolherbst🐧🦀> not sure what's the proper value here in vulkan
22:44 fdobridge: <k​arolherbst🐧🦀> `VK_SAMPLER_ADDRESS_MODE_MIRRORED_REPEAT`
22:44 fdobridge: <k​arolherbst🐧🦀> anyway...
22:45 fdobridge: <p​homes> https://cdn.discordapp.com/attachments/1034184951790305330/1170131545131077632/Screenshot_from_2023-11-03_23-44-39.png?ex=6557ecec&is=654577ec&hm=e4bef8968aafe1b6a19df5b25550490d8d76b1fe4789d13eef03bf826461dc65&
22:45 fdobridge: <k​arolherbst🐧🦀> anything suspicious the shader is doing with the coords
22:45 fdobridge: <k​arolherbst🐧🦀> I expected that to look more cursed
22:46 fdobridge: <k​arolherbst🐧🦀> uhh.. it's spir-v... so I guess that might be hard to figure out what's wrong here
22:46 fdobridge: <k​arolherbst🐧🦀> @phomes anyway, could file a bug and attach traces or something... dunno
22:47 fdobridge: <p​homes> I can file a bug of course. I just wanted to have a little fun tonight and see if I could figure this out 🙂
22:47 fdobridge: <k​arolherbst🐧🦀> yeah.. fair
22:48 fdobridge: <k​arolherbst🐧🦀> anyway, image coords being messed up is the best I can help with 😄
23:09 fdobridge: <m​henning> I assume you're using codegen? You can try setting `NV50_PROG_OPTIMIZE` to 0 or 1 to see if it's a backend optimization that's breaking stuff
23:10 fdobridge: <m​henning> or set `NV50_PROG_DEBUG=1` to print out the shader assembly
23:13 fdobridge: <m​henning> I'd probably be trying to narrow down whether the shader compiler is wrong or the rest of the driver
23:14 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> How does codegen assembly compare with NAK assembly? 🤔
23:16 fdobridge: <p​homes> @mhenning codegen and NAK both have same result
23:17 fdobridge: <m​henning> the main difference is NAK instructions are all uppercase which makes me think the compiler is yelling at me
23:19 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I mean how optimized NAK assembly is when compared to codegen (vkcube only has 50-60 FPS with NAK)
23:20 fdobridge: <m​henning> Okay, cool. then it's probably not in the backend - although it could still be a compiler bug if it's in one of NVK's lowering passes, which get shared across backends
23:20 fdobridge: <p​homes> NV50_PROG_OPTIMIZE=1 has same result
23:21 fdobridge: <p​homes> NV50_PROG_OPTIMIZE=0 crashes with "src/nouveau/codegen/nv50_ir_emit_gv100.cpp:144: void nv50_ir::CodeEmitterGV100::emitFormA(uint16_t, uint8_t, int, int, int): Assertion `insn->src(src0 & FA_SRC_MASK).getFile() == FILE_GPR' failed"
23:22 fdobridge: <m​henning> I'm guessing that texture isn't mipmapped?
23:22 fdobridge: <p​ac85> Mmm that's a screen space buffer seemingly sampled using models UVs
23:23 fdobridge: <m​henning> woah, you're right - I missed that it's at a bit of an angle
23:24 fdobridge: <m​henning> but also... what? how?
23:26 fdobridge: <m​henning> maybe we bind the texture to the wrong slot?
23:27 fdobridge: <p​ac85> It does get blended correctly (it gets multiplied with albedo)
23:27 fdobridge: <p​ac85> (And this game has a weird format for shadow maps so if it was bound to that slot you'd definitely get a different result)
23:28 fdobridge: <p​ac85> (And this game has a weird format for light maps so if it was bound to that slot you'd definitely get a different result) (edited)
23:41 fdobridge: <g​fxstrand> How do I tell if I successfully got GSP?
23:42 fdobridge: <k​arolherbst🐧🦀> the errors look different
23:42 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Run `sensors`
23:42 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> If there's no nouveau then you're using GSP
23:47 fdobridge: <g​fxstrand> Ah. Updated linux-firmware but not nvidia-firmware
23:53 fdobridge: <g​fxstrand> It's time we put GSP through it's paces. 😁
23:53 fdobridge: <g​fxstrand> I feel air coming out of the back of my turing card
23:55 fdobridge: <g​fxstrand> I haven't seen a flake yet.... This is already promising