03:10tiredchiku[d]: redsheep[d]: how long until the artifacting shows up on chromium applications?
03:10redsheep[d]: Under the right conditions it is actually immediate
03:10tiredchiku[d]: the right conditions being..?
03:10redsheep[d]: But you have to have the system under load, and be looking at one of the kinds of ui elements that does it
03:11redsheep[d]: The server sidebar is the most buggy afaik
03:11tiredchiku[d]: got it, compile mesa
03:11redsheep[d]: No, I think it needs to be a gpu load
03:11redsheep[d]: But it is not clear to me whether it is more potent for it to be a cpu or gpu bound one
03:11tiredchiku[d]: got it, compile mesa while testing a game
03:11redsheep[d]: Probably just that it loads or pollutes whatever is not working properly
03:12redsheep[d]: tiredchiku[d]: Probably effective, yeah
03:26tiredchiku[d]: playing black ops 3 zombies while mesa is compiling
03:26tiredchiku[d]: no artifacting in the discord server list
03:27tiredchiku[d]: official client
03:27tiredchiku[d]: 1440p 165hz, displayPort
03:30redsheep[d]: Hmm maybe it is fixed. I will boot linux next time I get the chance and recheck, if I can get discord to launch
03:31tiredchiku[d]: pull in MR 31528 for the chromium fix
03:32tiredchiku[d]: or, well, stopgap fix :P
03:32redsheep[d]: Oh right that is a thing you did, hopefully 31517 merges before too long
03:32tiredchiku[d]: yeah
03:36tiredchiku[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31488
03:37tiredchiku[d]: just me not knowing what I'm doing
03:37tiredchiku[d]: and Jane Vulkan telling me what I'm doing wrong
04:44gfxstrand[d]: If the system being under load matters, maybe it's an issue with getting non-zero buffers. Have you tried with `NVK_DEBUG=zero_memory`?
04:45gfxstrand[d]: It's also possible that there's some sort of issue with stuff getting paged out. But given that I can do 36-thread CTS runs pretty reliably, that seems unlikely.
05:27redsheep[d]: Hmm interesting theory, I will try zeroing if I can replicate it again
05:31redsheep[d]: I've been tinkering with seeing how viable messing around with games the way I do on linux is on windows, and it really sucks to run games with environment variables. The method with the launch options field in steam doesn't work, and I haven't found a sane solution
05:32tiredchiku[d]: hmmmmmmmm I'd like a list of all depth formats, where can I find it
05:32redsheep[d]: Probably just running steam with the environment variables is the least nasty, and that's not what I would call sane
05:32tiredchiku[d]: also VK_FORMAT_D32_SFLOAT_S8_UINT would be a floating point format too, right?
05:35tiredchiku[d]: tiredchiku[d]: ah cool: https://docs.vulkan.org/guide/latest/depth.html#depth-formats
07:35tiredchiku[d]: hmmm
07:35tiredchiku[d]: looks like clamping to [0,1] all the time is not valid
07:35tiredchiku[d]: it's causing some CTS failures .-.
07:35tiredchiku[d]: but first, lunch break
08:04tiredchiku[d]: tiredchiku[d]: ...maybe?
13:12tiredchiku[d]: I'm so confused
13:12tiredchiku[d]: I feel like I'm missing a piece
13:13tiredchiku[d]: why does doing this break depthclamp_deltasmall
13:13tiredchiku[d]: ```c
13:13tiredchiku[d]: if (nvk_cmd_buffer_3d_cls(cmd) >= VOLTA_A) {
13:13tiredchiku[d]: if(clamp_zero_one){
13:13tiredchiku[d]: P_NV9097_SET_VIEWPORT_CLIP_MIN_Z(p, i, fui(0.0f));
13:13tiredchiku[d]: P_NV9097_SET_VIEWPORT_CLIP_MAX_Z(p, i, fui(1.0f));
13:13tiredchiku[d]: } else {
13:13tiredchiku[d]: P_NV9097_SET_VIEWPORT_CLIP_MIN_Z(p, i, fui(zmin));
13:13tiredchiku[d]: P_NV9097_SET_VIEWPORT_CLIP_MAX_Z(p, i, fui(zmax));
13:13tiredchiku[d]: }
13:13tiredchiku[d]: }
13:28tiredchiku[d]: it's literally the only logic change in nvk_flush_vp_state()
13:28tiredchiku[d]: and if I revert it, depthClampZeroOne breaks .-.
13:28tiredchiku[d]: the one where _only_ depthClampZeroOne is enabled
13:28tiredchiku[d]: guh, I'll poke at it more after dindin
13:30tiredchiku[d]: might try to run the test via gdb to get a backtrace
14:04HdkR: /12/4
14:50gfxstrand[d]: tiredchiku[d]: Yes
14:52gfxstrand[d]: tiredchiku[d]: I'm not 100% sure why that test is breaking but the depth clamp 1/0 extension is annoyingly subtle in the way that it interacts with depth clipping. Unlike depth_clip_control, it doesn't modify the clip/clamp threshold. It adds an additional clamp.
14:53gfxstrand[d]: So if you have depth clipping and depth_clamp_control both enabled, you get both a clip and a clamp
14:55gfxstrand[d]: But I think the spec is such that only one of them actually happens in practice because the viewport Z volume is required to be inside [0, 1] unless you're in unrestricted depth territory. But with unrestricted depth, depth_clamp_zero_one doesn't apply.
15:33tiredchiku[d]: gfxstrand[d]: yeah, am struggling to figure out the subtlety that's breaking here .-.
15:39tiredchiku[d]: I did manage to pinpoint that it's breaking when z_clamp is enabled
15:39tiredchiku[d]: tiredchiku[d]: and when the depthClampZeroOne conditions are met
15:40tiredchiku[d]: i.e. when both our z_clamp is used alongside clamping to [0,1]
15:42tiredchiku[d]: ...I think I have an idea on solving it
15:54tiredchiku[d]: :wahoo:
15:58tiredchiku[d]: now 13 minutes for the *depth\* CTS, then I can push this (hopefully) final revision
16:00tiredchiku[d]: oh btw, should pre-volta also get the depthClampZeroOne logic?
16:01tiredchiku[d]: I imagine it should, but am not 100% sure
16:09tiredchiku[d]: :wahoo:
16:09tiredchiku[d]: no fails!
16:09tiredchiku[d]: let me see if I can fix some checks and then I'll push
16:24tiredchiku[d]: pushed :D
16:28tiredchiku[d]: can finally rm -rf uh
16:28tiredchiku[d]: 25 gigs worth of mesa builds
16:32tiredchiku[d]: we trial and error like that
17:19gfxstrand[d]: Okay, I'll read through it on Monday
17:23tiredchiku[d]: no worries! hope you have a nice sunday c: