00:01redsheep[d]: Does it fail when all the rates are set to x4? I wonder if maybe the hardware can't actually mix multisample and course and expects you to render in two passes with the overlap set as x0
00:02redsheep[d]: Or something along those lines, I haven't been able to read over an example of the extension actually getting used yet
02:29redsheep[d]: I just finished reviewing the spec and it reads to me like you at least have the option to just change the shading rate to fewer pixels when there's msaa, but that's specifically mentioned with the combiner ops and it's not clear to me whether those are optional for this mixed case. I can't find any example code for the mixed case.
02:42AshiskumarNaik[m]: <gfxstrand[d]> "Ashis kumar Naik: That's not..." <- I wanted to ask about, I am interested to work on the project ideas related to “nouveau” listed on the Xorg EVoC site. I am looking for any mentors out there , thats what I am asking.
02:48gfxstrand[d]: On the userspace side, it's probably karolherbst[d] or myself and I'm not looking to take someone on at the moment.
02:49AshiskumarNaik[m]: okay
06:08redsheep[d]: gfxstrand[d]: Why is this suddenly talking about NVC596 instead of NVC597? https://gitlab.freedesktop.org/gfxstrand/mesa/-/commit/fdb143349dbc927f9cda610050b6cc4a67acb5eb
10:19blockofalumite[d]: gfxstrand[d]: There's a Matrix room ?
10:19blockofalumite[d]: ~~I am so sorry~~
10:49asdqueerfromeu[d]: blockofalumite[d]: https://matrix.to/#/%23xdc-2024%3Amatrix.org
12:34blockofalumite[d]: Thanks ^^
13:46gfxstrand[d]: redsheep[d]: typo
13:47gfxstrand[d]: Ugh... I think my HSW box might have finally died
13:49gfxstrand[d]: Which is annoying because that's the box I was running the blob driver on
13:55gfxstrand[d]: Yeah, it's not posting.
13:55gfxstrand[d]: I guess I get to install the blob on my test box and figure out how to safely dual-boot
13:59gfxstrand[d]: 🪦
13:59redsheep[d]: It's not that bad, just better hope your test box reboots quickly. Also need to set up automation around updates to stop it blacklisting nouveau all the time, when you need to be doing that yourself explicitly depending on boot option
14:00zmike[d]: switching blob<->nouveau isn't too bad these days
14:00gfxstrand[d]: marysaka[d]: How well does the shader dumper work on new blobs?
14:05mohamexiety[d]: gfxstrand[d]: since iirc you're on Fedora it's as simple as just installing the blob via rpmfusion and then when you want to boot nouveau, remove the `rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1` kernel args. when you want to boot the blob, keep them
14:05mohamexiety[d]: I have had both installed for a while now and things are fine
14:05kwizart: mohamexiety[d], +1 ;)
14:05mohamexiety[d]: I am not sure if installing the blob directly via the NVIDIA installer changes things negatively though :thonk:
14:07notthatclippy[d]: Can't nouveau be rmmod/insmod'd? I never reboot when reloading the blob, and requiring reboot for nouveau sounds like a lot of wasted time
14:08gfxstrand[d]: Maybe? But once your display is up, it's a bit dicy
14:09mohamexiety[d]: it would be really cool if we could swap without a reboot. the rpmfusion wiki says it isn't possible atm but maybe there's a more involved way
14:09notthatclippy[d]: Switch to a VT, kill the wm, reload, restart wm
14:10notthatclippy[d]: Takee me about 20 seconds to reload the blob and (mostly) get back to where I was. Just the browser tabs get unloaded and are lazy reloaded.
14:11gfxstrand[d]: marysaka[d]: 's talking!
14:11mohamexiety[d]: yep. mesh shader hype
14:11gfxstrand[d]: https://www.youtube.com/watch?v=d0MP9-hFUZE
14:12gfxstrand[d]: gfxstrand[d]: The good news is that this means I no longer have to care about hasvk or crocus. Sorry, airlied[d]. 😛
14:21gfxstrand[d]: karolherbst[d]: can you make me a maintainer of the nouveau group in GitLab?
14:23karolherbst[d]: gfxstrand[d]: done
14:25gfxstrand[d]: Okay now nv-shader-tools is in nouveau/
14:37gfxstrand[d]: UGH... `VPRS_TABLE_INDEX` goes before `PRIMITIVE_ID` in the attribute space which breaks our neat groupings. :blobcatnotlikethis:
14:39gfxstrand[d]: Maybe it's kind of okay
14:48marysaka[d]: gfxstrand[d]: It just work with the fixes I did a while back
14:59gfxstrand[d]: Yeah, I got a dump
14:59gfxstrand[d]: `gl_PrimitiveShadingRateEXT` does indeed move on Ampere.
15:07gfxstrand[d]: Okay, I've got envyhooks running on my test desktop now too
15:07gfxstrand[d]: RIP Haswell. 🪦
15:20redsheep[d]: I wonder where the sample coordinates come from for the msaa+fragment shading rate case. Is that maybe contained in that gibberish setup data?
15:23gfxstrand[d]: Oh, that one's fun.
15:24gfxstrand[d]: https://gitlab.freedesktop.org/gfxstrand/mesa/-/commit/7260635da8cff7c7ff418644a401ec3bde1433bf
15:24gfxstrand[d]: Okay, this is entertaining... 1x MSAA and 4x MSAA work but not 2x or 8x
15:25gfxstrand[d]: Narrowing down the problem...
15:26gfxstrand[d]: karolherbst[d]: Here's an intern idea: Make the pushbuf parser stateful and add a `--expand-macros` option
15:26redsheep[d]: ... Have you tested if 16x works in this context? I assumed you disabled it because it's broken in the general case
15:26gfxstrand[d]: The MME simulators should have the hooks to do it now
15:26redsheep[d]: Would be funny if 16x works here
15:27gfxstrand[d]: redsheep[d]: 16x is really wonky. It only works for depth buffers
15:27gfxstrand[d]: So I've not actually enabled it
15:27redsheep[d]: That's... Interesting
15:27gfxstrand[d]: It might also be useful for the no attachments case. But, seriously, multisampling with no attachments? What are you even doing.
15:28gfxstrand[d]: redsheep[d]: Yeah, there was a lot of frustration that went into figuring that out.
15:30redsheep[d]: I guess I can see why that would still be useful just for depth? But that's a really weird limitation
15:31gfxstrand[d]: Yeah
15:31redsheep[d]: I can see why you just shut it off, 16x isn't more accurate by enough to be worth the trouble very often
15:32gfxstrand[d]: If Proton ever needs it for some D3D limit, I'll figure it out. Until then, it's not worth the bother.
15:32redsheep[d]: I just assumed the hardware could do it because for example optifine in Minecraft exposes 16x and it appears to work fine, but I haven't actually checked whether it's actually just 8x
15:37gfxstrand[d]: <a:shrug_anim:1096500513106841673>
16:00gfxstrand[d]: I really want to know what `0x0f60` is...
16:00gfxstrand[d]: It feels relevant
16:13gfxstrand[d]: Oh, please tell me it isn't this...
16:16gfxstrand[d]: Oh, damn... That was it!
16:16gfxstrand[d]: https://gitlab.freedesktop.org/gfxstrand/mesa/-/commit/2b7e7a6a9e61a157ad4bb61a24e379817d60683a
16:17gfxstrand[d]: But now tests are failing
16:19gfxstrand[d]: I'm going to do a CTS run with just that patch to see if it's a general problem or an FSR problem
16:20gfxstrand[d]: What's the difference between the OGL and D3D modes? No idea.
16:24gfxstrand[d]: Yeah, looks like lots of tests are failing now
16:24gfxstrand[d]: Oh, goodie
16:29gfxstrand[d]: I wonder if SET_SAMPLE_LOCATIONS is different with the D3D enums. :frog_thinking:
16:48gfxstrand[d]: Just needed to fix up NIL
16:51gfxstrand[d]: I'm sure this is going to break multisample storage images but I can figure out and fix that
16:51gfxstrand[d]: Or maybe it won't. <a:shrug_anim:1096500513106841673>
16:53gfxstrand[d]: 4% of a CTS run says I'm fine but IDK that I believe that. 😅
16:57gfxstrand[d]: Time to make lunch while I wait for the CTS, I guess.
17:13gfxstrand[d]: gfxstrand[d]: I used to think the `_D3D` modes were just aliases in the hardware. There's a lot of those in the state packets. I guess they're materially different somehow. <a:shrug_anim:1096500513106841673>
17:14gfxstrand[d]: And the non-D3D 2x1 and 4x2 are effectively deprecated. THey don't seem to work with a few of the new features.
17:44gfxstrand[d]: Ugh... There's something subtle different with `gl_SampleMaskIn[]`
18:28gfxstrand[d]: 4X2_D3D is so cursed...
18:35gfxstrand[d]: Okay, gl_SampleMaskIn[] was already busted in NVK. I need to re-think this from scratch
18:40gfxstrand[d]: Fortunately, there are only 3 interesting cases: 4 * 0.5, 8 * 0.5, and 8 * 0.25
18:42gfxstrand[d]: There are more if I start caring about 16x but I don't care about that today
18:42gfxstrand[d]: But 4x4 is already busted. so my new patches are not to blame
18:43gfxstrand[d]: The CTS tests for this are just a bit rubbish
19:45gfxstrand[d]: I could just stop implementing partial MSAA
19:45gfxstrand[d]: No one else does
21:46gfxstrand[d]: Okay, sample masks fixed, I think.
21:46gfxstrand[d]: That was gnarly
21:50linkmauve: triang3l[d], sorry I have no other way to contact you than from here, are you perhaps on IRC or on XMPP so that we wouldn’t pollute this room about unrelated projects? You’re one of the Xenia maintainers right?
23:11redsheep[d]: gfxstrand[d]: That seems really weird, but glad it worked out. Have you been able to start another cts run?
23:12redsheep[d]: gfxstrand[d]: What do you mean by partial msaa?
23:16gfxstrand[d]: When you have 8 samples but run the shader 4x.
23:16gfxstrand[d]: On most HW, it's either one invocation per pixel or one per sample and nothing in between.
23:17redsheep[d]: Hmm. I see. That does sound pretty tricky
23:18redsheep[d]: Reading all the related specs has made me appreciate that rasterization is way more complicated than I knew, and I already thought it was pretty complicated
23:29redsheep[d]: I'm still not quite sure I understand which parts correspond to the ROPs vs the TMUs to be honest
23:39gfxstrand[d]: Test run totals:
23:39gfxstrand[d]: Passed: 32378/107044 (30.2%)
23:39gfxstrand[d]: Failed: 8257/107044 (7.7%)
23:39gfxstrand[d]: Not supported: 66409/107044 (62.0%)
23:39gfxstrand[d]: Warnings: 0/107044 (0.0%)
23:39gfxstrand[d]: Waived: 0/107044 (0.0%)
23:39gfxstrand[d]: but dmesg is clean
23:40redsheep[d]: That's progress