00:03fdobridge: <gfxstrand> Well, it survived the synchronization tests. Let's see if it survives the rest of the run.
00:07fdobridge: <gfxstrand> ```
00:07fdobridge: <gfxstrand> DONE!
00:07fdobridge: <gfxstrand> Test run totals:
00:07fdobridge: <gfxstrand> Passed: 406865/3600883 (11.3%)
00:07fdobridge: <gfxstrand> Failed: 31/3600883 (0.0%)
00:07fdobridge: <gfxstrand> Not supported: 3193983/3600883 (88.7%)
00:07fdobridge: <gfxstrand> Warnings: 4/3600883 (0.0%)
00:07fdobridge: <gfxstrand> Waived: 0/3600883 (0.0%)
00:07fdobridge: <gfxstrand> ```
00:22fdobridge: <airlied> was that on turing btw?
00:30fdobridge: <gfxstrand> Yup
00:33fdobridge: <gfxstrand> Here's the fails if anyone's interested
00:33fdobridge: <gfxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1161099206379966524/fails.txt?ex=653710e6&is=65249be6&hm=ac2dd598ed77e57935b09e2da214932515910e32fbde2a4128107ef96d4ff36d&
00:35fdobridge: <gfxstrand> I'll take care of all the `dEQP-VK.api.*` tests myself. The two that I'd love it if someone took a crack at are the alpha-to-coverage fails and the depth bias ones.
00:35fdobridge: <airlied> I've looked at the depth bias ones twice now and gotten nowhere, but that was with codegen
00:35fdobridge: <gfxstrand> NAK won't change anything
00:35fdobridge: <gfxstrand> I've looked at them a few times, too.
00:36fdobridge: <gfxstrand> I should be able to knock out the easy ones tomorrow. But those two groups might be annoying.
00:36fdobridge: <gfxstrand> The YCbCr fails are us not supporting linear. I think the answer is we disable YCbCr for the CTS run.
00:37fdobridge: <gfxstrand> I've got a branch somewhere for linear texturing but it needs some love. Probably not hard but YCbCr is totally optional so I'm fine shutting it off for now.
00:38fdobridge: <gfxstrand> @marysaka has a patch for the image qualifiers tests. I gave her some feedback and I'll probably merge that in the morning.
00:39fdobridge: <airlied> are you going to merge NAK once the GS is done or wait to try and pass conformance?
00:39fdobridge: <airlied> or is conformance passing more of an XDC goal?
00:49fdobridge: <gfxstrand> More I'll think about merging NAK after XDC and the F2F.
00:49fdobridge: <gfxstrand> There's some NIR bits that need to go in and some build system arguing to do.
00:49fdobridge: <gfxstrand> I don't want to deal with that in the next 3 weeks.
00:50fdobridge: <gfxstrand> Looks like the shader object fails are CTS bugs. Fun!
00:50fdobridge: <airlied> oh no, you update CTS to fix those bugs, and you get a whole bunch of new ones 😛
00:51fdobridge: <airlied> all of my attempts to get newer conformance on llvm/lavapipe recently have ended because I file the CTS bugs and forget about it for 6 months
00:57fdobridge: <gfxstrand> Yeah....
00:57fdobridge: <gfxstrand> I can also hack Mesa to make it pass. 😅
01:10fdobridge: <gfxstrand> Those fails I can hack around, anyway.
01:10fdobridge: <gfxstrand> I probably should start working off a real CTS release branch, though. 🤔
01:53airlied: TimurTabi: any ideas what ROBUST_CHANNEL_PREEMPTIVE_REMOVAL would mean from GSP, it that like something went wrong, so I'm just blowing it all away?
02:39TimurTabi: airlied: where are you seeing this?
02:45fdobridge: <gfxstrand> Well, we're going to try `vulkan-cts-188.8.131.52`
02:45fdobridge: <gfxstrand> Who knows what bugs that's going to turn out to have? 🤷🏻♀️
02:49airlied: TimurTabi: when the gsp crashes with those oom errors, it first kills all the channels with error 45
02:49airlied: which translates into ROBUST_CHANNEL_PREEMPTIVE_REMOVAL
02:49airlied: https://paste.centos.org/view/6284d415 is the dmesg
02:55airlied: TimurTabi: I'm going to try and crash things there so I can pull logrm buffer before it fills up with other stuff
03:41TimurTabi: airlied: also increase the logrm buf to 256k
04:06fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Do you mean RAM or VRAM?
04:09fdobridge: <airlied> GSP's RAM
04:09fdobridge: <airlied> which is a piece of VRAM I think
04:23fdobridge: <gfxstrand> Do we just not have it sized correctly?
04:26fdobridge: <airlied> the last thing Ben did was fix the heap sizing calcs to correspond to openrm
04:28fdobridge: <gfxstrand> 🤔
05:28fdobridge: <airlied> what does TIR stand for? I think the TIR regs might be involved in the alpha coverage stuff
05:30fdobridge: <airlied> ah target independent rasterizer
09:33cwabbott: airlied: there's a vulkan extension that corresponds to TIR in DX land
09:40cwabbott: ah wait, it's a core Vulkan feature - `variableMultisampleRate`
09:42cwabbott: basically just the idea of doing whatever multisample count you want (even up to 16 samples) if there are no attachments bound
09:45fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> How easy would that be to implement in NAK/NVK?
11:39fdobridge: <mohamexiety> I was working on this but got heavily sidetracked by something else, sorry. .-.
11:39fdobridge: <mohamexiety> When is the deadline?
13:45fdobridge: <gfxstrand> There isn't really a deadline. For now, I'll just shut off ycbcr for the CTS runs.
13:47fdobridge: <gfxstrand> In theory, probably not hard. We just need to figure out what registers we're not setting. 🙃
14:51fdobridge: <mohamexiety> got it. I'll try to speed through it these days. sorry again
14:51fdobridge: <gfxstrand> No worries. It's fine.
14:51fdobridge: <gfxstrand> I'm not super worried about that one.
15:21fdobridge: <gfxstrand> Ugh... Of course these draw indirect barrier problems don't exist on Maxwell. 🙄
15:28fdobridge: <gfxstrand> Got it. Needed `MME_DMA_SYSMEMBAR`
16:26fdobridge: <georgeouzou> I tried to implement variableMultisampleRate in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24621#note_2096567
16:26fdobridge: <georgeouzou> Maybe there is a better way to do this correctly?
18:25fdobridge: <gfxstrand> Alright... Should be down to just depth bias and alpha-to-coverage.
18:25fdobridge: <gfxstrand> Maybe I'll start a run and go buy groceries
18:33fdobridge: <conan_kudo> that's a good plan
18:51fdobridge: <![NVK Whacker] Echo (she) 🇱🇹> Hopefully it isn't like this: https://youtube.com/shorts/PO4k2Svd92s
20:27fdobridge: <marysaka> I tried to poke those earlier today without much success 😅
21:08fdobridge: <airlied> I took a trace of the alpha to coverage and didn't get any enlightenment other than the TIR regs might be involved
22:30fdobridge: <gfxstrand> 😫
22:30fdobridge: <gfxstrand> I'll poke tonight or tomorrow
22:32fdobridge: <gfxstrand> I suspect TIR as well but I've already poked at them some.
22:33fdobridge: <gfxstrand> It could also be that we have to emit a dummy color surface with the sample count
22:33fdobridge: <gfxstrand> That occurred to me today
22:34fdobridge: <gfxstrand> I've got an idea for how to do that with a not-too-insane macro
22:35fdobridge: <gfxstrand> For depth bias... I got nothing. 🤷🏻♀️
22:51fdobridge: <airlied> Yeah I think NVIDIA emit a dummy I'll upload the trace later in case it helps
23:10fdobridge: <airlied> https://people.freedesktop.org/~airlied/scratch/nv-traces/alpha-coverage-no-color
23:11fdobridge: <airlied> there's the trace in case it helps
23:13fdobridge: <airlied> okay so GSP crash seems to be am MMU fault on a BAR2 NULL ptr, which doesn't seem healthy, not sure what causes it
23:14fdobridge: <gfxstrand> ```
23:14fdobridge: <gfxstrand> Passed: 401802/3988868 (10.1%)
23:14fdobridge: <gfxstrand> Failed: 8/3988868 (0.0%)
23:14fdobridge: <gfxstrand> Not supported: 3587054/3988868 (89.9%)
23:14fdobridge: <gfxstrand> Warnings: 4/3988868 (0.0%)
23:14fdobridge: <gfxstrand> Waived: 0/3988868 (0.0%)
23:14fdobridge: <gfxstrand> ```