11:31 fdobridge: <z​mike.> ugh I fucked up something with my format selection fixes and now I've got a bunch of snorm fails again
11:44 fdobridge: <z​mike.> ...or I was using nvidia blob and something weird was going on there?
12:03 fdobridge: <z​mike.> okay, we have some definite regressions...
12:06 fdobridge: <z​mike.> a lot of regressions...
12:24 fdobridge: <v​alentineburley> Can you please take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28203/diffs?commit_id=13e60bc40c675e03b8fe738aa32f7835ea6363fc when you've got some time?
12:24 fdobridge: <v​alentineburley> It got me through CTS but there's a TON of unsupported tests still. I don't know how RADV does.
12:24 fdobridge: <v​alentineburley> CC @prop_energy_ball 😄
12:25 fdobridge: <z​mike.> @gfxstrand I think your maintenance5 implementation may be slightly broken
12:25 fdobridge: <z​mike.> if I stop emitting pointsize=1.0 all over the place, everything explodes
12:37 fdobridge: <J​oshie with Max-Q Design> Looks fine, thanks for looking into it
12:39 fdobridge: <J​oshie with Max-Q Design> I'll do turnip tomorrow when I wakeup if you havent beat me =)
13:00 fdobridge: <g​fxstrand> That's plausible. There is a GPU state for it which I'm setting but I was never convinced the CTS coverage was good.
13:01 fdobridge: <z​mike.> well good news for you
13:01 fdobridge: <z​mike.> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28162 + glcts is all the coverage you'll ever need
13:19 fdobridge: <g​fxstrand> lol
13:51 fdobridge: <g​fxstrand> Alright, let's run ES3 CTS a third time and see where it hangs/crashes this time. 😅
13:52 fdobridge: <z​mike.> I'm seeing some weirdness on other drivers too :stressheadache:
13:53 fdobridge: <g​fxstrand> Oh, I assume it's not an NVK bug. NVK has no bugs.
13:59 fdobridge: <r​edsheep> I can picture the phoronix article now "NVK passes OpenGL CTS and is said to now be entirely free of bugs"
14:23 fdobridge: <J​oshie with Max-Q Design> Faith is manufacturing pesticide
14:23 fdobridge: <J​oshie with Max-Q Design> Not a driver
14:25 fdobridge: <J​oshie with Max-Q Design> NVK stands for Noverdurin Valerate Ketahydroxide which is meant to finally replace DDT
14:38 fdobridge: <g​fxstrand> Any particular test or just search for something that uses points?
14:39 fdobridge: <z​mike.> I was glancing at `GTF-GL46.gtf43.GL3Tests.multi_draw_indirect.multi_draw_indirect_conditional_render` as a simple fail, but I got sidetracked before I could do more than run it on a couple drivers and see it was failing
14:42 fdobridge: <z​mike.> and now I ran your EGL test and it asserts differently for me somehow...
14:50 fdobridge: <g​fxstrand> I've seen a couple different asserts with that one. I think it depends on how badly it looses the race with the window system. 🤡
14:53 fdobridge: <g​fxstrand> Ugh... gltf
14:53 fdobridge: <g​fxstrand> Let me pull that
14:58 fdobridge: <g​fxstrand> Ugh... I hate EGL. What config params do I need for the gtf tests?
15:01 fdobridge: <g​fxstrand> I guess I can run it with Wayland
15:01 fdobridge: <z​mike.> `cmake .. -GNinja -DDEQP_TARGET=x11_egl_glx -DGLCTS_GTF_TARGET=gl`
15:01 fdobridge: <z​mike.> is what I build with
15:01 fdobridge: <z​mike.> for running I don't use any special params
15:01 fdobridge: <z​mike.> I'm trying to figure out a bug with io lowering so I'm a bit sidetracked
15:07 fdobridge: <g​fxstrand> Okay, I got it to run
15:11 fdobridge: <g​fxstrand> Hrm... Looks like disabling the POINT_SIZE attribute doesn't do what I thought it did
15:11 fdobridge: <g​fxstrand> I wonder what the GL driver does for this
15:15 fdobridge: <g​fxstrand> I'm doing the same thing as the GL driver...
15:15 fdobridge:<g​fxstrand> doesn't want to look at the blob. 😭
15:29 fdobridge: <g​fxstrand> > GTFRunTest: FAIL
15:29 fdobridge: <g​fxstrand> > 0 passes, 1 failures, test case FAILED!
15:29 fdobridge: <g​fxstrand> > Test case duration in microseconds: 86373 us
15:29 fdobridge: <g​fxstrand> Thanks CTS... Real helpful...
15:36 fdobridge: <z​mike.> CTS like
15:36 fdobridge: <z​mike.> https://cdn.discordapp.com/attachments/1034184951790305330/1218221177286164560/4zlk8b.png?ex=6606dfe2&is=65f46ae2&hm=078e04329f9b3488fa5d0b6e601c2bff4b460e1a0b7f298513efe4cf6d061682&
15:48 fdobridge: <z​mike.> ohhhh lmao
15:48 fdobridge: <z​mike.> right, nvk doesn't support modifiers
15:48 fdobridge: <z​mike.> so you're hitting the swrast path
15:48 fdobridge: <z​mike.> uhhhhh
15:48 fdobridge: <z​mike.> wow
15:51 fdobridge: <z​mike.> @gfxstrand re: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10827 what was your -DDEQP_TARGET for this cts build?
16:01 fdobridge: <g​fxstrand> Wayland. Says so in the issue title.
16:04 fdobridge: <z​mike.> so it does
16:04 fdobridge: <z​mike.> good thing I can read on fridays
16:05 fdobridge: <z​mike.> huh
16:05 fdobridge: <z​mike.> this is pretty broken
16:16 fdobridge: <g​fxstrand> :cursedgears:
16:16 fdobridge: <g​fxstrand> :cursedgears: (edited)
16:22 fdobridge: <v​alentineburley> This is completely untested (as I don't have a device) and probably very broken but maybe it helps you a bit
16:22 fdobridge: <v​alentineburley> https://gitlab.freedesktop.org/Valentine/mesa/-/commit/a7a5eecb95f6c3aa014d5e149e29157b4fc2cbec
16:23 fdobridge: <J​oshie with Max-Q Design> Ty, I can CTS this tomorrow
16:30 fdobridge: <v​alentineburley> Not sure if it does anything 😄
16:37 fdobridge: <r​edsheep> For the requested testing on the shader exceptions MR 28096 what kind of game issue should I be looking for?
16:37 fdobridge: <r​edsheep>
16:37 fdobridge: <r​edsheep> I'd like to help test but it's quite the hunt. I've ran through a few dozen games while testing various things over the past few months, and I think the only unexpected fail I know of right now is doom 2016 which hits an mmu fault in dmesg, which doesn't sound like the kind of issue that is applicable.
16:38 fdobridge: <r​edsheep> Really almost anything that isn't using d3d12 or raytracing basically just works, at least for me.
16:40 fdobridge: <S​id> I wonder if that'll fix elite dangerous for me
16:43 fdobridge: <r​edsheep> Worth testing. At this point if a game is more than 5 years old I think I'm quite a lot more likely to find that some given game is failing due to lack of support for Linux or proton than I am to find that NVK doesn't work.
16:43 fdobridge: <S​id> I know it's worth testing, however, I can't test :\
16:43 fdobridge: <r​edsheep> Ah, that.
16:44 fdobridge: <r​edsheep> I'd test but I don't have the game.
16:45 fdobridge: <S​id> I'd give you my account .-.
16:45 fdobridge: <S​id> but
16:45 fdobridge: <S​id> it is 50 gig
16:45 fdobridge: <S​id> 55 I think now
16:46 fdobridge: <S​id> NVK testers family sharing when
16:47 fdobridge:<S​id> is half joking
16:47 fdobridge: <r​edsheep> I mean... I can download a 55 GB game in like 10 minutes
16:47 fdobridge: <g​fxstrand> Mostly it's just things to try if you have a game hang you don't know what to do with.
16:47 fdobridge: <g​fxstrand> I don't expect it to break anything.
16:47 fdobridge: <r​edsheep> Right
16:48 fdobridge: <r​edsheep> Hmm. Maybe I'll try it with doom 2016 then
16:49 fdobridge: <S​id> I wonder if QC launcher now
16:49 fdobridge: <S​id> s\/launcher/launches
16:50 fdobridge:<g​fxstrand> wonders if she can repro this in crucible.
16:51 fdobridge: <g​fxstrand> Or maybe there's a VK CTS in gerrit
16:51 fdobridge: <r​edsheep> Out of curiosity why not merge it? Are you just looking for confirmation anybody needs those exceptions off?
16:52 fdobridge: <g​fxstrand> Typically shader exceptions catch real bugs so I'd like to know what we're fixing.
16:57 fdobridge: <S​id> would shader exceptions throw xids
16:57 fdobridge: <S​id> or is it entirely possible for them to not output any special logging
16:58 fdobridge: <S​id> the last round of out of range exceptions though xid 13
16:59 fdobridge: <S​id> wtf brain
16:59 fdobridge: <g​fxstrand> They're one of the few things GSP logs nicely
16:59 fdobridge: <S​id> s\/though/threw
16:59 fdobridge: <S​id> okay, so if I wasn't seeing xids on a game, the shader exception mr is not likely to fix them
17:00 fdobridge: <r​edsheep> Was there an xid thrown with doom?
17:01 fdobridge: <S​id> nope, not that I remember seeing
17:03 fdobridge: <S​id> the only place where I had an xid was sea of thieves
17:05 fdobridge: <r​edsheep> Yeah now that you mention it I've seen it a few times but those have all cleared up
17:43 mupuf: DRM: GART: 536870912 MiB. .. seems veeeeerrrryyyy wrong
17:43 mupuf: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/56356548#L1412
17:43 mupuf: May explain the insta hangs?
17:43 mupuf: I don't see any message about loading the GSP though. Is it expected?
17:45 fdobridge: <g​fxstrand> It usually advertises a huge GART
17:49 fdobridge: <g​fxstrand> A single hang when you run the CTS isn't surprising. There's something that hangs early which I have yet to diagnose.
17:49 fdobridge: <g​fxstrand> But that shouldn't take the machine down
17:58 fdobridge: <g​fxstrand> So my point size is fine, maybe? But it's getting weirdly scaled somewhere.
17:58 fdobridge: <g​fxstrand> Like, I'm definitely controlling it from the API just not the way someone somewhere expects
18:00 fdobridge: <z​mike.> 🤔
18:06 fdobridge: <g​fxstrand> I don't think this multidraw fail has anything to do with point size
18:08 fdobridge: <z​mike.> very possible
18:08 fdobridge: <z​mike.> I still haven't been able to look at it
18:08 fdobridge: <z​mike.> spent the morning fixing xfb with lowered io
18:10 fdobridge: <z​mike.> now I'm looking at egl while I make lunch
18:10 fdobridge: <z​mike.> maybe multidraw later as a treat if I finish in time
18:22 fdobridge: <S​id> https://github.com/jp7677/dxvk-nvapi/pull/168 merged
18:22 mupuf: gfxstrand: yeah, we have way more hangs than that. That's why I am suspecting something wrong.with the kernel setup
18:23 fdobridge: <S​id> @ivyl if we could now revert the wine-side commits for this, that'd be great, thanks <3
18:27 fdobridge: <g​fxstrand> Yup. The gallium patch is bad. IDK how easy it is to differentiate between 1.0 and the API-specified size but it's not doing that. The CTS test was using a point size of 5.0 and NVK was (correctly!) giving it 1.0.
18:27 fdobridge: <S​id> faith is there a way we can provide gpu architecture info
18:27 fdobridge: <g​fxstrand> Once again, NVK has no bugs. 😤
18:28 fdobridge: <S​id> right now nvapi is checking gpu arch on nvk by checking for available vulkan extensions
18:28 fdobridge: <S​id> which.. isn't working for Ampere
18:29 fdobridge: <g​fxstrand> What kind of arch info?
18:29 fdobridge: <g​fxstrand> We provide the PCI ID and the name printed on the box
18:29 fdobridge: <z​mike.> great, thanks for reviewing
18:29 fdobridge: <S​id> they just wanna know if the gpu is turing, or ampere, or ada, or pascal, that kinda stff
18:29 fdobridge: <i​vyl> How's dxvk doing with the revert? We don't want to have a mismatch between the ids
18:29 fdobridge: <S​id> I poked about the dxvk revert as well https://discord.com/channels/853130811581530142/853133408737296394/1218263449168122026
18:30 fdobridge: <i​vyl> Thanks!
18:31 fdobridge: <i​vyl> I'll revert once it's done here as wine's faking also tricks dxvk
18:31 fdobridge: <S​id> ok fair nvm they do it by extension for nv proprietary as well
18:31 fdobridge: <S​id> we just seem to not implement the extension they check for yet
18:32 fdobridge: <S​id> s\/extension/feature
18:32 fdobridge: <S​id> primitiveFragmentShadingRateWithMultipleViewports
18:45 fdobridge: <m​arysaka> You need `VK_KHR_fragment_shading_rate` implemented for that too
18:45 fdobridge: <S​id> yeah
19:00 fdobridge: <l​oothelion (Liam Middlebrook)> I chose the various extensions and feature bits that I did because they were what was exposed via VK GPUInfo to distinguish between architectures. If something else is needed for NVK, I’d bet that the dxvk-nvapi maintainers would be open up to a specific path as needed there.
19:01 fdobridge: <S​id> no it's okay, because using a different method for prop and nvk will just add to dxvk-nvapi maintainers' headaches
19:02 fdobridge: <S​id> I do wonder if there are more exts/feature bits that we already implement that are ampere specific, but, that's just me thinking
19:04 fdobridge: <l​oothelion (Liam Middlebrook)> I don’t recall there being much around the time I added this function, but it’s certainly possible that new extensions over the past few years have exposed some new ones. The compare feature on GPUInfo should make that pretty easy to figure out (at least assuming it picks up the latest + greatest fields)
19:06 fdobridge: <S​id> that's a good idea, I'll check
19:14 fdobridge: <s​aancreed> We already have some driver-specific paths in arch detection code but it would certainly be nice if we could query the same thing on both drivers at some point in the future.
20:33 mupuf: It's aliiiiivvvveeee! https://gitlab.freedesktop.org/mesa/mesa/-/jobs/56366783
20:34 mupuf: Sooooo, yeah.... nouveau wasn't loaded with the GSP option... so that explains the hangs
20:35 mupuf: Nvk should probably complains if the.GSP isn't loaded
20:39 mupuf: And nouveau.ko should also say what it is using in the kernel logs
20:40 fdobridge: <v​alentineburley> Oh no, seeing some wsi maintenance1 fails there
20:41 fdobridge: <v​alentineburley> Nothing failed for me locally
20:43 fdobridge: <S​id> making nouveau output if GSP was initialized should be a fairly trivial change
20:43 fdobridge: <S​id> just one printk in the init sequence
20:43 fdobridge: <S​id> @airlied thoughts? :D
20:54 Lyude: huh [ 171.682192] nouveau 0000:1f:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
20:58 Lyude: airlied: btw on the DP bug you were mentioning before, do you know if this is a regression?
21:05 airlied: I'll just reboot with non-gsp and see
21:07 airlied: Lyude: it does break different without gsp, but still broken, no idea if it broke recently though
21:11 Lyude: i do at least know there's a few spots I've wanted to fix where we do some apparently incorrect stuff with payload updates (but it never really caused problems elsewhere), so I wonder if that might be related. it might also just be another deadlock somewhere
21:17 fdobridge: <g​fxstrand> I'm not sure how to do that. GSP is intentionally invisible to userspace.
21:18 fdobridge: <g​fxstrand> Yeah, making nouveau.ko spit it out would be great.
21:18 fdobridge: <S​id> it's a one liner change, really
21:20 fdobridge: <!​DodoNVK (she) 🇱🇹> Check if the GSP option is inside the kernel cmdline or if GPU architecture is Ada or higher
21:20 fdobridge: <!​DodoNVK (she) 🇱🇹> ~~Or check if hwmon for nouveau is present~~
21:22 Lyude: btw - I did send one fix that might be worth tryig. I don't think it'll change much, but apparently we haven't been returning GSP errors properly on failed aux transactions
21:22 Lyude: (this is in addition to the previous issues we originally had with it when we needed to implement support for aux delays)
21:26 fdobridge: <g​fxstrand> I mean, yes, you can do that. But it would solve so many user reports if there was a "GSP loaded successfully" or "GSP load failed" message.
21:26 fdobridge: <g​fxstrand> I've had the same complaints about Intel and the GuC for years.
21:33 fdobridge: <S​id> guc does have some logging on load
21:34 fdobridge: <g​fxstrand> Maybe it does now. 😅
21:35 fdobridge: <k​arolherbst🐧🦀> nouveau should print what firmware it loads
21:35 fdobridge: <S​id> ```
21:35 fdobridge: <S​id> [sidpr@constructor ~]$ sudo dmesg | grep -iE nouveau
21:35 fdobridge: <S​id> [sidpr@constructor ~]$```
21:35 karolherbst: Lyude: nouveau really should start to return errors properly...
21:35 fdobridge: <S​id> oh wait
21:36 karolherbst: for modesetting I mean
21:36 fdobridge: <S​id> am dumb, it does have logging on load, but
21:36 fdobridge: <S​id> [ 6997.248718] nouveau 0000:01:00.0: pmu: firmware unavailable
21:42 Lyude: karolherbst: the original fix for it was supposed to make it do that but either me or dave forgot to change which variable we're returning from that function :(
21:42 Lyude: another reason for rust
21:42 karolherbst: I mean..
21:42 karolherbst: we just don't pipe errors through
21:42 karolherbst: and then continue to program the disp hardware even if something in the middle failed
21:43 Lyude: tbh there's usually not much you can do once you've misprogrammed the display hardware, it's kind of one of the reasons we introduced atomic in the first place
21:43 karolherbst: like.. if link training would fail to a bad cable, we simply run into errors
21:43 karolherbst: Lyude: even with atomic we'd continue to do so
21:44 karolherbst: like.. e.g. r535_sor_hda_eld
21:44 karolherbst: there are tons of WARN_ONs instead of actually handling it
21:44 Lyude: oh eesh, yeah I haven't gone through much of that code
21:44 Lyude: well I mean I have, but I haven't tried fixing anything in it
21:45 karolherbst: atm I'm fighitng this: "DRM: [DRM/00000003:kmsOutp] [HDMI head:0 enable:1 max_ac_packet:45 rekey:56 khz:1097750 scdc:1 scdc_scrambling:1 scdc_low_rates:0] (ret:-22)" the internal ioctl fails, and we just don't handle it anyway either
21:45 karolherbst: though that error we return...
21:46 karolherbst: anyway... we kinda need to figure out what needs to be fixed there so it gets a bit more reliable
21:46 Lyude: mst lesson revisited: always blame the cable. don't worry, you're probably right
21:47 karolherbst: :D
21:47 Lyude: (my MST setup was not working but I thought it was too suspicious without errors so I switched cables and now it works, lol...)
21:47 karolherbst: I mean.. I use a HDMI 1.4 cable to run 2.1 modes, so yes, I do blame the cable :DP
21:47 karolherbst: but I'm not getting to the point where link training would even start
21:48 karolherbst: though the cable seems to be good enough for 4K@60...
21:48 karolherbst: so dunno yet
21:48 Lyude: maybe HDMI added pins again?
21:49 karolherbst: ohhh..
21:49 karolherbst: yeah..
21:49 karolherbst: "args->v0.max_ac_packet > 0x1f" this check triggers
21:49 karolherbst: "max_ac_packet:45"
21:49 karolherbst: do we even do anything with this value?
21:49 karolherbst: apparently we don't :D
21:50 Lyude: good news at least, it seems like my mst setup at home (granted, this is only dp 1.2) at least seems to work perfectly fine with nouveau.
21:51 karolherbst: yeah...
21:51 karolherbst: as long as nothing hits any errors it's fine
21:51 Lyude: :P
21:51 karolherbst: I have this cursed laptop where both USB-C _and_ ports on the laptop directly both go to the nvidia gpu
21:51 karolherbst: for extra fun
21:52 Lyude: airlied: when you test again with the patch that I sent to the mailing list: if things start timing out again, try doing sysrq+w to see if you can get it to spit out a backtrace on what threads might be blocked
21:52 karolherbst: I don't know if my docks are HDMI 2.1 capable tho
21:52 Lyude: (and also lockdep if you can)
21:52 Sid127: dxvk will no longer override pci IDs by default for NVK and will only override it if the override exists for proprietary driver too https://github.com/doitsujin/dxvk/commit/e857b09432241c68b8fa6d873c3943d669f561fe
21:53 karolherbst: so if it doens't work now, I'll be disappointed
21:54 karolherbst: mhhh
21:54 karolherbst: so GSP didn't complain on link training...
21:56 karolherbst: I hate this TV, it's a pain to work with...
21:57 karolherbst: like there is no option to disable the timeout it just turns itself off on no signal :')
21:58 karolherbst: Lyude: what's the best way to parse those disp state dumps?
22:05 fdobridge: <r​edsheep> Your docks are almost certainly not FRL capable
22:06 fdobridge: <r​edsheep> And yeah TVs are a pain because they also only want to accept things being set up exactly right, where a display would just shrug it off and try it anyway with a weird mode
22:53 Lyude: i can respect a panel being picky after seeing some lenovo laptops where the display would just be like "i'll accept any mode/underrun/etc.. :)" to the point you could disrupt the voltage , sine wave? not sure what you would call it
22:54 Lyude: the thing where you cause an LCD to not drive it's voltage +n/-n so that the pixels start acting like they have screen burn even when they're powered off