08:46fdobridge: <ahuillet> @gfxstrand @marysaka I have an idea which you may dislike. class_parser.py generates header files in build/src/nouveau/headers at build time. Yet the nvk code itself references them, which sometimes feels strange when not building because it's referencing non-existing headers. How would you feel about checking in these generated headers in the source tree? When one updates the class files from open-gpu-doc they'd re-generate the headers in t
08:46fdobridge: <ahuillet> AAARGH Discord I hate you so much. I mean g<underscore>
08:46fdobridge: <ahuillet> @gfxstrand @marysaka I have an idea which you may dislike. 'class_parser.py' generates header files in build/src/nouveau/headers at build time. Yet the nvk code itself references them, which sometimes feels strange when not building because it's referencing non-existing headers. How would you feel about checking in these generated headers in the source tree? When one updates the class files from open-gpu-doc they'd re-generate the headers in
08:47fdobridge: <ahuillet> @gfxstrand @marysaka I have an idea which you may dislike. `class_parser.py` generates header files in build/src/nouveau/headers at build time. Yet the nvk code itself references them, which sometimes feels strange when not building because it's referencing non-existing headers. How would you feel about checking in these generated headers in the source tree? When one updates the class files from open-gpu-doc they'd re-generate the headers in
08:50fdobridge: <airlied> no checking in headers is never a good plan if we can avoid it
08:50fdobridge: <airlied> just causes conflicts and stuff when rebasing that are impossible to reconcile
08:51fdobridge: <ahuillet> sorry, can't parse the double negative, you're saying it's a bad idea to check in generated headers?
08:51fdobridge: <airlied> yes it's a bad idea unless its totally unavoidable
08:51fdobridge: <ahuillet> understood
08:52fdobridge: <airlied> esp if you ever change the generator script to produce a different format, and then you make rebasing a nightmare
08:55fdobridge: <ahuillet> https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/3d/clcb97.h#L27 don't sweat that line I guess ;)
08:55fdobridge: <ahuillet> (j/k)
09:19fdobridge: <valentineburley> @ahuillet Will you publicize the missing headers for mesh shaders too?
09:19fdobridge: <valentineburley> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27196/diffs?commit_id=c8405d883f5d0c82945e0fcf062e482235ddd38d
09:21fdobridge: <ahuillet> Working on it
09:39fdobridge: <ahuillet> but I'm hungry, it's baguette time
11:17fdobridge: <saancreed> https://github.com/NVIDIA/open-gpu-doc/commit/c702e9e8c57306e779cff7ab4a649691b8ce59f7 :frog_gears:
11:31fdobridge: <karolherbst🐧🦀> :ferrisBongo:
12:27fdobridge: <gfxstrand> That's fine. The headers we pull are our one source of truth. If we had NVIDIA's XML or whatever, we'd use that but we don't. What we don't want is something that can get out of sync with other stuff in the tree.
12:38fdobridge: <ahuillet> I was joking
12:38fdobridge: <ahuillet> these are the source of truth even for me. we have them checked in.
12:39fdobridge: <ahuillet> it's funny because I edit them before publication despite the big fat warning. :)
12:42fdobridge: <karolherbst🐧🦀> heh
13:20fdobridge: <gfxstrand> https://tenor.com/view/not-listening-no-nope-cant-hear-you-ears-plugged-gif-9375594
13:22fdobridge: <gfxstrand> At Intel, we had XML which we hand typed from PDFs that were generated from different XML.
13:36fdobridge: <gfxstrand> I had an XML -> XML generator at one point but the official XML was such a disaster that the HW enabling folks typically found it easier to just re-type.
13:42fdobridge: <mohamexiety> this is just so messed up :blobcatnotlikethis:
13:54fdobridge: <gfxstrand> Oh, yeah. Thoroughly cursed is the name of the game. 🙃
14:23fdobridge: <gfxstrand> @mohamexiety I just pulled your kernel patch into my NVK kernel tree and am building now. I'll poke about at the modifiers branch in a bit. I want to test depth_range_unrestricted first.
14:24fdobridge: <mohamexiety> understood, give me a boop if anything blows up. I'll get to it immediately
14:27fdobridge: <mtijanic> The HW class headers are unlikely to change at all, other than addition of new lines in the same format, so no merge conflicts there. The software ones for talking to GSP (e.g. <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/common/sdk/nvidia/inc/ctrl/ctrl2080/ctrl2080internal.h>) are due at least one massive change in format whenever something resembling a stable ABI comes along.
14:28fdobridge: <mtijanic> But those are generated from an IDL and when the time comes we could just publish the IDL+tool, or generate them for rust or whatever ends up being most convenient. Least of our problems there.
14:36fdobridge: <gfxstrand> Yup and that's the other reason I'm fine with checking them in. If stuff only ever gets added, that's a lot easier to deal with than if a code generator change alters behavior in some subtle way and someone fails to check that in.
14:54fdobridge: <!DodoNVK (she) 🇱🇹> Does GSP use COM (Component Object Model)?
14:58fdobridge: <mtijanic> Heh, I've never heard anyone make that connection before, but there's quite a few similarities, yes.
15:01fdobridge: <ahuillet> the best answer to "is this COM" when you want to look good is "ugh of course not"
15:28RSpliet: As long as the GSP is not spinning up a Tomcat server...
15:28karolherbst: what a wonderful idea that is
18:41fdobridge: <gfxstrand> Ugh... depth_range_unrestricted...
18:42fdobridge: <esdrastarsis> https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html
18:44fdobridge: <karolherbst🐧🦀> `Asserting unsafe preconditions` I hope I don't ahve to fix a bunch of random stuff 😄
18:47fdobridge: <rinlovesyou> mesa with nvk on certainly builds fine
19:27fdobridge: <samantas5855> Milos is the paperclip on your pfp a tegra reference?
19:37fdobridge: <gfxstrand> Okay, I think depth range unrestricted is working
19:43fdobridge: <mohamexiety> wait what's the relation with a paperclip and tegra 😮
19:43fdobridge: <mtijanic> I also don't know...
19:43fdobridge: <samantas5855> rcm
19:43fdobridge: <mtijanic> But it's a ref to <https://en.wikipedia.org/wiki/Instrumental_convergence#Paperclip_maximizer>. I was once told my greatest potential in life is as raw paperclip material.
19:45fdobridge: <samantas5855> mcgyver got a lot of uses out of a paperclips
19:45fdobridge: <mohamexiety> ohhh that AI thingy
19:46fdobridge: <mohamexiety> sorry to hear though, that's a messed up thing to be told..
19:49fdobridge: <mtijanic> No, it's probably the most original insult I ever got, I loved it. I'm not one to get offended by anything. And it wasn't even that serious.
19:50fdobridge: <samantas5855> is it a common saying in Serbia?
19:50fdobridge: <mohamexiety> ah lol
19:53fdobridge: <phomes_> I can confirm that the tests still pass and smoke test with a few random games all showed no problems 🙂
21:55fdobridge: <joobei> Guys today is a milestone in my life. I was finally able to play my favorite game on GNU/Linux. I am extatic 🙂 This is from steam hardware info, does this mean that my system is running mesa/nouveau?
21:55fdobridge: <joobei> https://cdn.discordapp.com/attachments/1034184951790305330/1235711184230027264/image.png?ex=66355d38&is=66340bb8&hm=7bbe2a575cec5c0dbf188ac08fe509dd5120fb9711f92d1776a22c617c0236c5&
22:01fdobridge: <Sid> no
22:01fdobridge: <Sid> it's running the mesa software renderer
22:22fdobridge: <mohamexiety> what game is this?
22:22fdobridge: <mohamexiety> there's a decent chance if you update you will use nouveau actually
22:23fdobridge: <leopard1907> It means your driver setup is borked
22:24fdobridge: <leopard1907> Bäd milestone
22:24fdobridge: <leopard1907> At least for 32 bit portion
22:51fdobridge: <Sid> that's the steam hw info