01:13 noocsharp: what makes the firmware more difficult to get to for maxwell and onward, is it just hard to find them in the binary?
01:35 fdobridge_: <b​enjaminl> are there preferences on whether to "ununify" ops on SM50 at this point? There used to be several instruction that don't exist on SM50 but were implemented as something else in the encoder. Most of these were moved to dedicated instructions at some point, with the split between SM50 and SM70 happening in the builder
01:35 fdobridge_: <b​enjaminl> I'm currently looking at `iabs`, which is implemented in the encoder as `i2i`
01:37 fdobridge_: <b​enjaminl> it's missing the abs src modifier bit, which is a trivial fix, but I'm also considering splitting out a separate `OpI2I` and emitting that in the builder `iabs` method
01:37 fdobridge_: <b​enjaminl> I guess I mostly just get confused when the instructions in the IR don't match up to the ones we're actually using
03:16 fdobridge_: <g​fxstrand> @airlied you familiar with this one?
03:17 fdobridge_: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1197016897108054147/message.txt?ex=65b9bbdb&is=65a746db&hm=87f8140ad7e8734056f914f87adf257fc3c542a5f179be94c859f4770def2c15&
03:17 fdobridge_: <g​fxstrand> dakr: ^^
03:18 fdobridge_: <g​fxstrand> Admittedly, it's been a minute since I rev'd my kernel on that box.
03:22 fdobridge_: <g​fxstrand> For those wondering, ^^ is what happened to my CTS run on ampere.
03:39 fdobridge_: <g​fxstrand> I wonder if these magic fencing patches will fix it.
04:09 fdobridge_: <a​irlied> Any sign of a problem before that? Like channel hangs or VM alloc fails?
06:42 fdobridge_: <!​DodoNVK (she) 🇱🇹> Normal 6.7 should work now (because it has the initial GSP support with various fixes)
14:42 fdobridge_: <m​arysaka> That should hopefully be okay to get mixins on headers around https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27115
14:43 fdobridge_: <g​fxstrand> Nope, not for about 5k seconds.
14:44 fdobridge_: <!​DodoNVK (she) 🇱🇹> I'm getting Minecraft modding flashbacks from that word
14:45 fdobridge_: <m​arysaka> Same but it's not as fancy as that.
14:46 fdobridge_: <m​arysaka> Same but it's not as fancy as Sponge's mixins. (edited)
14:53 fdobridge_: <g​fxstrand> We've got a different version in the conservative rasterization MR. Mind giving that a look?
14:54 fdobridge_: <m​arysaka> I missed that one 😓
14:54 fdobridge_: <g​fxstrand> Yeah, I did some fixing to make it so we always give a semi-full path: "nvidia/classes/foo.h" vs. "mixin/classes/foo.h"
14:55 fdobridge_: <g​fxstrand> Seems a little dangerous but I think I like that over prefixing everything.
14:56 fdobridge_: <m​arysaka> yeah so it looks mostly the same I guess I will close my MR and rebase on those patches
14:56 fdobridge_: <g​fxstrand> Okay
14:57 fdobridge_: <g​fxstrand> I'm going to try and merge that today. I'm not entirely happy with the "if file exists" checks in the meson but IDK that there's a better option.
14:57 fdobridge_: <m​arysaka> what is the min version needed to compile mesa? because I *think* the |= syntax on method is after 3.9
14:57 fdobridge_: <m​arysaka> what is the min version needed to compile mesa? because I *think* the |= syntax on dictis after 3.9 (edited)
14:57 fdobridge_: <m​arysaka> what is the min version needed to compile mesa? because I *think* the |= syntax on dict is after 3.9 (edited)
14:57 fdobridge_: <m​arysaka> what is the min version needed to compile mesa? because I *think* the |= syntax on dict is since ~3.9 (edited)
14:58 fdobridge_: <!​DodoNVK (she) 🇱🇹> Of Meson? I guess it's 1.3 with NAK enabled
14:58 fdobridge_: <m​arysaka> of python in general
14:58 fdobridge_: <m​arysaka> sorry I forgot words here I need another cup of tea 😅
14:58 fdobridge_: <m​arysaka> what is the min version of python needed to compile mesa? because I *think* the |= syntax on dict is since ~3.9 (edited)
14:59 fdobridge_: <m​arysaka> what is the min version of python needed to compile mesa? because I *think* the |= syntax on dict is since 3.9 (<https://peps.python.org/pep-0584/>) (edited)
15:00 fdobridge_: <g​fxstrand> I think 2.6 or 2.7
15:00 fdobridge_: <g​fxstrand> I think 3.6 or 3.7 (edited)
15:01 fdobridge_: <!​DodoNVK (she) 🇱🇹> Meson requires Python 3.7 by itself
15:01 fdobridge_: <m​arysaka> Will add a comment then
17:13 fdobridge_: <g​fxstrand> With the latest fence patches, I didn't get this fail. Instead, I just got what looked like a standard channel timeout.
17:40 fdobridge_: <b​enjaminl> does CI check python 3.7? I ask because there's a comment at the top of `class_parser` that says it probably needs 3.9 and I'd like to remove it if it's been tested with 3.7
17:47 fdobridge_: <g​fxstrand> I don't think so
17:48 fdobridge_: <g​fxstrand> I think that requirement comes from ChromeOS and they don't care about NVK
17:48 fdobridge_: <g​fxstrand> If we require 3.9, that's really not going to be the thing distros struggle with. 😅
17:49 fdobridge_: <b​enjaminl> alright I'll leave the comment then
17:50 fdobridge_: <b​enjaminl> I tried to test it myself but decided that getting a compatible mako version set up was too much of a pain lol
17:53 fdobridge_: <g​fxstrand> Yeah
18:10 fdobridge_: <g​fxstrand> Just got it again. Same CTS test. This time on the `nouvellis/alirlied-gsp-fixes`
18:11 fdobridge_: <g​fxstrand> @airlied ^^
18:16 fdobridge_: <g​fxstrand> `dEQP-VK.synchronization.timeline_semaphore.device_host.write_copy_buffer_read_copy_buffer_to_image.buffer_16384` is the test that hits it
18:16 fdobridge_: <g​fxstrand> Test passes when run by itself.
18:17 fdobridge_: <g​fxstrand> It only seems to fail as part of a full CTS run. 🤦🏻‍♀️
18:17 fdobridge_: <g​fxstrand> And it runs fast so I don't think it's timing out
18:43 fdobridge_: <g​fxstrand> @marysaka does your dumper know how to dump QMDs?
18:43 fdobridge_: <m​arysaka> not currently
18:43 fdobridge_: <g​fxstrand> I'm very unconvinced by our `*_SM_CONFIG_SHARED_MEM_SIZE` configuration
18:44 fdobridge_: <m​arysaka> how does NVIDIA upload those atm on dGPU?
18:44 fdobridge_: <g​fxstrand> IDK
18:44 fdobridge_: <m​arysaka> I know that on tegra it's an inline upload from the command buffer
18:44 fdobridge_: <g​fxstrand> Hrm... Let me do a dump and see what's there
18:44 fdobridge_: <g​fxstrand> Maybe I can find it in a DMA
18:53 fdobridge_: <g​fxstrand> Looks like they're doing a DMA. Now let me see if I can decode it.
18:53 fdobridge_: <g​fxstrand> @marysaka Did you ever upstream `nv_push_dump`?
18:54 fdobridge_: <m​arysaka> It's on this branch https://gitlab.freedesktop.org/marysaka/mesa/-/tree/nouveau/pushbuf-dump-tool?ref_type=heads
18:56 fdobridge_: <m​arysaka> and I have this script https://gist.github.com/marysaka/3b203164793cb6d61834debc3dfda04e/revisions
18:57 fdobridge_: <a​irlied> @gfxstrand what ampere gpu is that btw? I'll plug one back in today and give it a run
19:04 fdobridge_: <g​fxstrand> 3060
19:04 fdobridge_: <S​id> I could try running it on my 1660Ti too, if needed
19:04 fdobridge_: <g​fxstrand> Oh, right. You had to hack up the isaspec stuff
19:05 fdobridge_: <m​arysaka> yeah :nya_flop:
19:05 fdobridge_: <g​fxstrand> How about we just get rid of isaspec?
19:05 fdobridge_: <g​fxstrand> This seems like a solvable problem. 😂
19:05 fdobridge_: <m​arysaka> that would be awesome 😄
19:06 fdobridge_: <m​arysaka> I wanted to fix isaspec but I forgot to look into it again
19:06 fdobridge_: <g​fxstrand> Like, we're already hand-typing the decode
19:06 fdobridge_: <m​arysaka> not for mme macro tho?
19:07 fdobridge_: <m​arysaka> I remember having to fix some stuffs in the Fermi isaspec definition to get better disassembly (that I probably forgot to push somewhere)
19:07 fdobridge_: <g​fxstrand> @karolherbst Does Volta use the Turing MME or the Fermi one?
19:08 fdobridge_: <k​arolherbst🐧🦀> fermi
19:08 fdobridge_: <g​fxstrand> Okay
19:08 fdobridge_: <g​fxstrand> Yet more weirdness
19:08 fdobridge_: <k​arolherbst🐧🦀> yeah...
19:08 fdobridge_: <g​fxstrand> It really is a Maxwell with Turing SMs
19:08 fdobridge_: <k​arolherbst🐧🦀> indirect draws are missing thing, right?
19:08 fdobridge_: <k​arolherbst🐧🦀> yeah.. more or less
19:08 fdobridge_: <k​arolherbst🐧🦀> well.. more like pascal
19:09 fdobridge_: <k​arolherbst🐧🦀> pascal changed compute a little
19:09 fdobridge_: <m​arysaka> (Volta is just Maxwell Gen 4 right)
19:09 fdobridge_: <k​arolherbst🐧🦀> pain
19:11 fdobridge_: <g​fxstrand> Really, it's a "Turing isn't ready but AMD might do something cool so we need to tape out some hardware. What do ya got , guys?"
19:16 fdobridge_: <g​fxstrand> Either that or they fab'd a few so the compiler folks could get real-world testing with the new ISA while the other bits got finalized and someone in marketing decided to sell it.
19:19 fdobridge_: <g​fxstrand> No, I will not RiiR the MME stuff while I'm at it...
19:24 fdobridge_: <g​fxstrand> Maybe I'll genxml them.
19:24 fdobridge_: <g​fxstrand> nah
19:27 fdobridge_: <m​ohamexiety> tbf it may not be an entirely bad idea to lock volta support behind experimental like pascal/maxwell/etc because it's genuinely rare HW
19:28 fdobridge_: <g​fxstrand> It already is
19:41 Lyude: sheesh, there are a lot of commits from the asahi tree that don't compile and need another commit to actually build properly
19:43 airlied: yeah I except some of it is rust compiler changes over time
19:45 airlied: expect
19:52 fdobridge_: <!​DodoNVK (she) 🇱🇹> Rarer than Tempest 3000?
20:03 Lyude: currently trying to figure out where kernel::device::Device::raw() comes from, since I see it used in some asahi commits but can't seem to find any implementation for it
20:21 Lyude: airlied: btw - any idea if lina actually hangs out on the #asahi-dev channel or elsewhere? wondering if she might know the answer to this
20:21 fdobridge_: <a​irlied> @gfxstrand https://paste.centos.org/view/a3c8b804 will fix the warning, but not sure if it will fix the causes of the warning
20:22 Lyude: (also it appears I meant drm::device::Device )
20:29 Lyude: actually now looking at it more closely i'm, not actually sure how this was ever meant to work. maybe raw() just got renamed at some point
20:30 Lyude: since the next patch moves over to using raw_mut(), and the original patch seems to expect raw() to provide a mutable reference
21:01 Lyude: btw airlied, dakr: https://gitlab.freedesktop.org/lyudess/linux/-/commits/0ad7088f current status on things I've pulled in, it appears I will likely have to go back and pull a number of other things in so that I can get access to the rust drm gem abstractions fwiw so I expect a lot more stuff to appear soon
21:01 Lyude: some of those commits will definitely be squashed as well eventually to make sure everything builds on each commit
21:05 fdobridge_: <g​fxstrand> There's a push command type that we can't decode. Type 6. NVIDIA seems to like using it
21:06 airlied: Lyude: I thought lina was on discord or zulip, but not seeing them around either currently
21:07 fdobridge_: <a​irlied> @gfxstrand so that warn shouldn't be fatal either
21:21 fdobridge_: <g​fxstrand> @airlied All I know is that I see a device lost and that warning
21:21 fdobridge_: <g​fxstrand> I've not dug any deeper to figure out why it's killing my channel
21:22 fdobridge_: <g​fxstrand> `LOAD_INLINE_QMD_DATA`
21:22 fdobridge_: <g​fxstrand> Which we should probably use...
21:22 fdobridge_: <g​fxstrand> It'd save us a lot of headaches
21:22 fdobridge_: <m​arysaka> huh
21:22 fdobridge_: <m​arysaka> Oh that's Pascal+
21:25 fdobridge_: <m​arysaka> On T210 (Maxwell) they were uploading it with that one inline way
21:25 fdobridge_: <a​irlied> okay I suspect now you'll see just device lost 🙂
21:25 fdobridge_: <a​irlied> with that patch
21:25 fdobridge_: <g​fxstrand> @marysaka https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27126
21:25 fdobridge_: <m​arysaka> I think I reproduced that on Pascalinette some years ago let me find it
21:25 fdobridge_: <m​arysaka> https://github.com/Pascalinette/gpu_playground/blob/master/maxwell/dma_copy_engine.py#L33
21:25 fdobridge_: <m​arysaka> That one thinggy
21:26 fdobridge_: <g​fxstrand> Okay, now I can actually look at this QMD. 😂
21:26 fdobridge_: <a​irlied> https://paste.centos.org/view/raw/80b22bfc result of a cts run on my ampere just now
21:26 fdobridge_: <m​arysaka> no more isaspec, thank you :SoniiPray:
21:26 fdobridge_: <g​fxstrand> Yeah, look at the LOC count.
21:27 fdobridge_: <m​arysaka> missing a 6 for my liking /s
21:27 fdobridge_: <m​arysaka> but yeah we should probably do inline upload that way for gen before Pascal (might be useful for Kepler? idk)
21:28 fdobridge_: <g​fxstrand> What do you mean?
21:28 fdobridge_: <m​arysaka> We should also add some code in the parser to make it understand LAUNCH_DMA inline data
21:28 fdobridge_: <g​fxstrand> Yeah...
21:29 fdobridge_: <m​arysaka> (-606)
21:29 fdobridge_: <g​fxstrand> And maybe decode QMDs
21:29 fdobridge_: <g​fxstrand> hehe
21:39 fdobridge_: <a​irlied> those cond render/xfb fails are new, I wonder are they new tests
21:40 fdobridge_: <g​fxstrand> I'm not seeing them and I thought I was running on a pretty new CTS
21:42 fdobridge_: <a​irlied> I just rebased to main 5m ago
21:43 fdobridge_: <g​fxstrand> Okay, they may be new
21:43 fdobridge_: <g​fxstrand> I'm on the 1.7.3 branch
21:44 fdobridge_: <a​irlied> anyways I've sent kernel warning fix to the mailing list
21:49 fdobridge_:<g​fxstrand> is very confused by the blob's configuration of `MIN_SM_CONFIG_SHARED_MEM_SIZE`
21:49 fdobridge_: <g​fxstrand> _is very confused by the blob's configuration of_ `MIN_SM_CONFIG_SHARED_MEM_SIZE` (edited)
21:50 fdobridge_: <g​fxstrand> It sets the min to 32k
21:50 fdobridge_: <g​fxstrand> which is a lot
21:51 fdobridge_: <k​arolherbst🐧🦀> well.. we don't know what those values do
21:51 fdobridge_: <k​arolherbst🐧🦀> so there is that
21:51 fdobridge_: <g​fxstrand> Yeah
21:51 fdobridge_: <g​fxstrand> I think it has to do with how shared memory is partitioned among workgroups
21:51 fdobridge_: <k​arolherbst🐧🦀> yeah...
21:52 fdobridge_: <g​fxstrand> Where you can have multiple workgroups in-flight with different shared memory sizes and different workgroup sizes and the HW has to be able to ringbuffer it all.
21:52 fdobridge_: <g​fxstrand> But how we're supposed to calculate that is a mystery
21:55 fdobridge_: <g​fxstrand> It seems setting 64k as a maximum is okay even with large workgroup sizes.
21:56 fdobridge_: <g​fxstrand> Poking at the blob, it seems they set max=64k, min=32k
21:56 fdobridge_: <g​fxstrand> IDK why the min is so large
21:56 fdobridge_: <g​fxstrand> With min=64k whenever the shader wants more than 32k
23:06 fdobridge_: <a​irlied> is nvk_cmd_copy_query_pool_results_mme dead code?