02:50fdobridge: <gfxstrand> Ugh... I knew barriers were going to be more complicated. 😩
03:37fdobridge: <Joshie with Max-Q Design> I mean you can get pretty bad image retention even without that :D
03:38fdobridge: <Joshie with Max-Q Design> Stuff like that on LCD should always go away though -- just throw a minute of random rgb noise at it, or play a game 🐸
10:18fdobridge: <valentineburley> I looked into `dEQP-VK.reconvergence.subgroup_uniform_control_flow` a bit and I can reproduce the fails on CTS 1.3.7.0 and 1.3.8.0 but on CTS `main`
10:27fdobridge: <valentineburley> I looked into `dEQP-VK.reconvergence.subgroup_uniform_control_flow` a bit and I can reproduce the fails on CTS 1.3.7.0 and 1.3.8.0 but not on CTS `main` (edited)
10:53fdobridge: <valentineburley> And the WSI maintenance1 fails all seem to say `setVisible() called on window not supporting it at vkWsiPlatform.cpp:34`
10:53fdobridge: <valentineburley> Everything I touched I broke 🤕
11:07mupuf: gfxstrand: GSP being intentionally transparent is good, but having a sysfs folder with one file per firmware that specify which version and other info the firmware may have would be good
11:08mupuf: For example, the security level...
11:09mupuf: Anyway, it.is only a matter of time before firmware bugs need to be worked around for specific versions
14:27fdobridge: <gfxstrand> mupuf: Yeah, it would be good to have something. Care to file a drm/nouveau issue about it? Tag me and we can chat on the issue about what exactly we want.
14:28fdobridge: <gfxstrand> I'm not sure what that difference is there but I am sure NAK handles this wrong today. I've got a plan, I think, but it's gonna take real work. And it's absurdly tricky compiler shit. Not something I expect you to be able to sort out.
14:29fdobridge: <gfxstrand> It's my fault I merged it without CTSing more first.
14:30fdobridge: <gfxstrand> That's not your fault. That's the fault of whoever implemented maintenance1 not checking carefully with with X11 or something.
14:35fdobridge: <gfxstrand> Also, that sounds a bit like broken tests but I'm not sure. I'd recommend stepping through the CTS with a debugger and trying to see how that error maps to the API. Since it's a .cpp file, that's probably an internal dEQP error.
14:45fdobridge: <mupuf> @gfxstrand: Done: https://gitlab.freedesktop.org/drm/nouveau/-/issues/340
14:48fdobridge: <valentineburley> By the way `dEQP-VK.reconvergence.subgroup_uniform_control_flow_elect.compute.nesting4.0.40` instantly passes on 1.3.8.0 but takes ages and then passes on CTS `main`
14:48fdobridge: <valentineburley> Maybe something else to check out
14:49fdobridge: <gfxstrand> Interesting
14:49fdobridge: <gfxstrand> I'm still very sure NAK is broken, though.
14:49fdobridge: <gfxstrand> But I'm curious what changed in the tests.
14:50fdobridge: <gfxstrand> I should really bump to 1.3.8.0 or even main for my testing. It's been a while since I've pulled the CTS.
23:01fdobridge: <gfxstrand> Ugh... I really wish I could get errors out of GSP. Any time I'm debugging something that isn't shader related I just get... nothing.
23:13fdobridge: <airlied> Do you get useful errors out of non gsp?
23:14fdobridge: <airlied> Like for mmu faults we might be able to get them reported, but there is 0 chance for other crashes apart from sending the logs to Timur from his kernel patch
23:14fdobridge: <gfxstrand> Yes, very useful. For faults, it gave me a fault address. For validation errors, it gave me the method and the invalid value.
23:18fdobridge: <airlied> Yeah faults might be possible to workaround, not sure on the method unfortunately, the turn around time on timur makes it pointless unless you get super stuck
23:21fdobridge: <gfxstrand> Why are we sending things to Timur?
23:21fdobridge: <gfxstrand> I'm confused
23:28fdobridge: <gfxstrand> 😩
23:37fdobridge: <airlied> Gsp logs stuff to a buffer we can't decode
23:38fdobridge: <airlied> The OS reports what it gets from gsp
23:39fdobridge: <airlied> Just I think with some faults we can use a separate fault reporting mechanism to make it happen
23:45fdobridge: <redsheep> Are you expecting those logs are encrypted, or would it be worth making a project out of trying to learn to decode it?