02:50 fdobridge: <g​fxstrand> Ugh... I knew barriers were going to be more complicated. 😩
03:37 fdobridge: <J​oshie with Max-Q Design> I mean you can get pretty bad image retention even without that :D
03:38 fdobridge: <J​oshie 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:18 fdobridge: <v​alentineburley> I looked into `dEQP-VK.reconvergence.subgroup_uniform_control_flow` a bit and I can reproduce the fails on CTS and but on CTS `main`
10:27 fdobridge: <v​alentineburley> I looked into `dEQP-VK.reconvergence.subgroup_uniform_control_flow` a bit and I can reproduce the fails on CTS and but not on CTS `main` (edited)
10:53 fdobridge: <v​alentineburley> And the WSI maintenance1 fails all seem to say `setVisible() called on window not supporting it at vkWsiPlatform.cpp:34`
10:53 fdobridge: <v​alentineburley> Everything I touched I broke 🤕
11:07 mupuf: 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:08 mupuf: For example, the security level...
11:09 mupuf: Anyway, it.is only a matter of time before firmware bugs need to be worked around for specific versions
14:27 fdobridge: <g​fxstrand> 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:28 fdobridge: <g​fxstrand> 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:29 fdobridge: <g​fxstrand> It's my fault I merged it without CTSing more first.
14:30 fdobridge: <g​fxstrand> That's not your fault. That's the fault of whoever implemented maintenance1 not checking carefully with with X11 or something.
14:35 fdobridge: <g​fxstrand> 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:45 fdobridge: <m​upuf> @gfxstrand: Done: https://gitlab.freedesktop.org/drm/nouveau/-/issues/340
14:48 fdobridge: <v​alentineburley> By the way `dEQP-VK.reconvergence.subgroup_uniform_control_flow_elect.compute.nesting4.0.40` instantly passes on but takes ages and then passes on CTS `main`
14:48 fdobridge: <v​alentineburley> Maybe something else to check out
14:49 fdobridge: <g​fxstrand> Interesting
14:49 fdobridge: <g​fxstrand> I'm still very sure NAK is broken, though.
14:49 fdobridge: <g​fxstrand> But I'm curious what changed in the tests.
14:50 fdobridge: <g​fxstrand> I should really bump to or even main for my testing. It's been a while since I've pulled the CTS.
23:01 fdobridge: <g​fxstrand> 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:13 fdobridge: <a​irlied> Do you get useful errors out of non gsp?
23:14 fdobridge: <a​irlied> 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:14 fdobridge: <g​fxstrand> Yes, very useful. For faults, it gave me a fault address. For validation errors, it gave me the method and the invalid value.
23:18 fdobridge: <a​irlied> 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:21 fdobridge: <g​fxstrand> Why are we sending things to Timur?
23:21 fdobridge: <g​fxstrand> I'm confused
23:28 fdobridge: <g​fxstrand> 😩
23:37 fdobridge: <a​irlied> Gsp logs stuff to a buffer we can't decode
23:38 fdobridge: <a​irlied> The OS reports what it gets from gsp
23:39 fdobridge: <a​irlied> Just I think with some faults we can use a separate fault reporting mechanism to make it happen
23:45 fdobridge: <r​edsheep> Are you expecting those logs are encrypted, or would it be worth making a project out of trying to learn to decode it?