00:52 airlied: TimurTabi: yes that does seem to get leaked alright
00:52 airlied: and the wpr one
02:18 fdobridge_: <a​irlied> uggh did a bios update on my turing laptop and now the gpu won't come out of runpm either
02:24 fdobridge_: <g​fxstrand> 😭
02:24 fdobridge_: <g​fxstrand> :xenia_sob:
02:36 fdobridge_: <a​irlied> I'm not sure my current low alcohol intake lifestyle is compatible with looking at ACPI tables
03:14 fdobridge_: <g​fxstrand> Trying to trim the repro case now. This one doesn't repro 100%
03:26 fdobridge_: <g​fxstrand> Down to 100k tests...
03:26 airlied: TimurTabi: btw sent out a fix finally for that registry rpc size being wrong
03:31 fdobridge_: <S​id> we don't have DSC yet, right?
04:01 fdobridge_: <a​irlied> https://patchwork.freedesktop.org/patch/576335/
04:01 fdobridge_: <a​irlied> @gfxstrand care to check if that changes the runpm behaviour for you?
04:05 TimurTabi: airlied: have taken a look at my command-line registry patch? I sent a v2 today.
04:39 fdobridge_: <g​fxstrand> Down to two tests that appear to have nothing whatsoever to do with each other. 😭
04:45 fdobridge_: <a​irlied> that patch actually probably won't be any yse, reproduced the runpm again on turing
04:46 airlied: TimurTabi: looks good, I just wanted to land the fix for the current code before adding more on top
04:47 TimurTabi: airlied: my patch supercedes yours and will cause a merge conflict, just FYI.
04:49 airlied: TimurTabi: yes yours will need to be rebased onto that once it is landing
04:49 airlied: or it might end up just as a fixes/next mere
04:49 airlied: merge
04:52 TimurTabi: airlied: so you want my patch to go into drm-next? Np
05:21 fdobridge_: <g​fxstrand> I think my workgroup barriers are hosed.
05:21 fdobridge_: <g​fxstrand> I'll look more tomorrow
08:57 simplymastermind: Marcelina Wanda Fecalinksa as most of you is a birth abortion leftover suicidal abuser. He makes close anal business with Paul PoopWise., sme time ago we had a punisher who would make it harder, he would fuck so bad to the butt that the shithole comes loose from the butt. you get that therapy all soon.
08:59 simplymastermind: tranny do you need something else for today?
09:47 fdobridge_: <r​inlovesyou> looks like it has not made it into 6.7.2, i'll keep an eye out for it though
09:47 fdobridge_: <r​inlovesyou>
09:47 fdobridge_: <r​inlovesyou> Also, what's going on with the IRC..?
09:48 fdobridge_: <!​DodoNVK (she) 🇱🇹> There's some Estonian person that's doing weird stuff and constantly joining the #ID:1034184951790305330 channel
09:49 fdobridge_: <r​inlovesyou> what a weirdly specific channel to attack
09:50 fdobridge_: <r​inlovesyou> Ah yes let me go harass the open source nvidia driver
09:50 fdobridge_: <!​DodoNVK (she) 🇱🇹> I think that person also joins some other related channels (but I can't confirm that)
09:50 fdobridge_: <!​DodoNVK (she) 🇱🇹> Like #dri-devel for example
09:52 fdobridge_: <r​inlovesyou> Either way sad times for me right now, can't test anything when 6.8-rc1 keeps freezing my graphical interface >:V
09:53 fdobridge_: <r​inlovesyou> That or there's a nasty memory leak somewhere
09:57 fdobridge_: <r​inlovesyou> https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg478682.html
09:57 fdobridge_: <r​inlovesyou>
09:57 fdobridge_: <r​inlovesyou> Looks like I'm not alone though :)
10:04 fdobridge_: <a​irlied> Try rc2 already 🙂
10:59 fdobridge_: <r​inlovesyou> Sadly still present :(
11:00 fdobridge_: <r​inlovesyou> Too bad the gsp fix didn't make it into 6.7.2, perhaps 6.7.3
12:51 fdobridge_: <S​id> @rinlovesyou does the whole system freeze? can you switch to another tty? do you have an iGPU as well?
13:29 fdobridge_: <r​inlovesyou> whole system seems to freeze. can not switch to a tty. sadly no IGPU, it's a ryzen 9 3900x
13:29 fdobridge_: <r​inlovesyou> notable that firefox audio continues to play
13:29 fdobridge_: <S​id> ...hmm, no igpu
13:29 fdobridge_: <r​inlovesyou> until it crashes, as described in the mail above
13:29 fdobridge_: <r​inlovesyou> so the system is at least still going on that level
13:30 fdobridge_: <S​id> oh wait you're having it pre 6.8rc2 as well
13:30 fdobridge_: <r​inlovesyou> yes
13:30 fdobridge_: <r​inlovesyou> it has been present ever since 6.8rc1
13:30 fdobridge_: <r​inlovesyou> linus *said* system freeze is supposed to be gone in rc2 but it doesn't seem to be
13:31 fdobridge_: <S​id> I thought maybe this patch would help but since it's not iGPU related and has been happening prior as well...
13:31 fdobridge_: <S​id> oh so not on 6.7?
13:31 fdobridge_: <r​inlovesyou> no, it's fine on 6.7, even 6.7.2
13:32 fdobridge_: <r​inlovesyou> inb4 it's actually a nouveau thing and i'm only catching it because gsp works in 6.8 :clueless:
13:32 fdobridge_: <S​id> I see
13:32 fdobridge_: <r​inlovesyou> inb4 it's actually a nouveau thing and i'm only catching it in 6.8 because gsp works in 6.8 :clueless: (edited)
13:32 fdobridge_: <S​id> gsp works on 6.7 as well
13:32 fdobridge_: <r​inlovesyou> inb4 it's actually a nouveau thing and i'm only catching it in 6.8 because gsp works :clueless: (edited)
13:32 fdobridge_: <r​inlovesyou> not for turing
13:32 fdobridge_: <S​id> it does
13:32 fdobridge_: <r​inlovesyou> brokey.
13:32 fdobridge_: <S​id> you just have to enable it
13:32 fdobridge_: <S​id> oh, right, you had those RIPs
13:33 fdobridge_: <S​id> WorksOnMyMachine 😅
13:33 fdobridge_: <r​inlovesyou> lol
13:33 fdobridge_: <S​id> has worked since 6.6 (since before gsp support was mainline)
13:33 fdobridge_: <r​inlovesyou> at the very least not for my card
13:33 fdobridge_: <S​id> granted, I had iGPU related issues that only got fixed in 6.7-rc5? 4? but yeah
13:34 fdobridge_: <r​inlovesyou> gsp only functions correctly for the 2070 super in 6.8
13:34 fdobridge_: <S​id> ..yeah, it looks like even within the same generation the hardware is wildly different
13:34 fdobridge_: <S​id> 1660Ti here
13:34 fdobridge_: <r​inlovesyou> typical nvidia moment
13:34 fdobridge_: <S​id> I'm actually on nouveau+gsp right now too
13:35 fdobridge_: <r​inlovesyou> i would be too if 6.8 didn't yeet my system at random
13:35 fdobridge_: <r​inlovesyou> hopefully soon, following along NVK's development is exciting
13:35 fdobridge_: <S​id> you'll get there :>
13:37 fdobridge_: <!​DodoNVK (she) 🇱🇹> I might have to open a bug report for the emulator repo (because I don't really know what's happening here)
14:33 fdobridge_: <!​DodoNVK (she) 🇱🇹> `vita3k: ../mesa/src/nouveau/vulkan/nvk_device_memory.c:57: zero_vram: Assertion '(bo->size / 4096) < (1 << 15)' failed.` :cursedgears:
15:03 fdobridge_: <r​inlovesyou> It would be nice if i could just use the gsp from 6.8 but I'm not able to Frankenstein myself a kernel
15:03 fdobridge_: <r​inlovesyou> It would be nice if i could just use the gsp from 6.8 but I'm not about to Frankenstein myself a kernel (edited)
15:26 fdobridge_: <!​DodoNVK (she) 🇱🇹> Bug report made: https://github.com/Vita3K/Vita3K/issues/3199 (feel free to comment on it)
15:37 fdobridge_: <k​arolherbst🐧🦀> let's see how much ping-pong we are going to play with that one
18:02 fdobridge_: <g​fxstrand> Well, that turned out to be extremely uninteresting: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27365
18:02 fdobridge_: <g​fxstrand> I guess it's not going to help cts + wsi
18:02 fdobridge_: <g​fxstrand> Maybe it'll at least make it so I can run 8 shards? 🤷🏻‍♀️
18:04 fdobridge_: <g​fxstrand> The fact that this test failed when run after certain 3D tests implies that shared memory lives in the same internal memories as some other sort of cache like index or vertex buffers. It looked very much like index buffer data.
18:04 fdobridge_: <g​fxstrand> So that's fun.
18:09 fdobridge_: <k​arolherbst🐧🦀> btw, nvidia prefers to use `SV_COMBINED_TID` because it's faster to do the alu in extracting the components than to do three pulls 🥲
18:13 fdobridge_: <g​fxstrand> Yeah
18:13 fdobridge_: <g​fxstrand> I'll probably switch to it at some point
18:13 fdobridge_: <g​fxstrand> Do you have the bit pattern in your magic docs? It looks like x is at bit 0 and y is at bit 16 from what I saw but I'd like to be sure.
18:13 fdobridge_: <g​fxstrand> And, yeah, PRMT is cheap
18:15 fdobridge_: <k​arolherbst🐧🦀> yeah.. it's x = 10:0, y = 25:16, z = 31:26
18:15 fdobridge_: <k​arolherbst🐧🦀> same sizes as the separate ones btw
18:17 fdobridge_: <g​fxstrand> Ugh.. That 26 sucks...
18:17 fdobridge_: <g​fxstrand> I mean, it's not too bad because it's just a shift but still...
18:17 fdobridge_: <g​fxstrand> Oh, the 25:16 sucks worse
18:17 fdobridge_: <k​arolherbst🐧🦀> why?
18:18 fdobridge_: <g​fxstrand> If they were aligned to bytes, I could use PRMT
18:18 fdobridge_: <g​fxstrand> Z is just a shift so that's fine. X is just an AND so that's fine, too.
18:18 fdobridge_: <g​fxstrand> But y is a full bitfield extract. 😭
18:18 fdobridge_: <g​fxstrand> But Y is a full bitfield extract. 😭 (edited)
18:18 fdobridge_: <k​arolherbst🐧🦀> just use `BMSK`?
18:19 fdobridge_: <g​fxstrand> Turing doesn't have the full extract version
18:19 fdobridge_: <k​arolherbst🐧🦀> ehh wait
18:19 fdobridge_: <k​arolherbst🐧🦀> that's just a mask 😄
18:19 fdobridge_: <g​fxstrand> On Maxwe.., I can use BFE
18:19 fdobridge_: <k​arolherbst🐧🦀> right..
18:19 fdobridge_: <g​fxstrand> On Maxwell, I can use BFE (edited)
18:20 fdobridge_: <g​fxstrand> But, like, it's 4 ALU vs. 3 so still kinda meh
18:21 fdobridge_: <k​arolherbst🐧🦀> maybe they stopped using it on Turing? Dunno.. I know we've added it to codegen, because they used that one on maxwell or so
18:22 fdobridge_: <g​fxstrand> Yeah, it's easy enough to switch how we implement `gl_LocalInvocationIndex`.
18:22 fdobridge_: <g​fxstrand> But also it's a compute shader so guaranteed to do memory things and you probably do it once at the top so... meh. 🤷🏻‍♀️
18:24 fdobridge_: <g​fxstrand> Unfortunately, fixing this bug (as entertaining as it was to chase down) sheds no light whatsoever on my CTS+WSI woes. :xenia_sob:
18:24 fdobridge_: <g​fxstrand> I'm also very close to just officially not caring.
18:24 fdobridge_: <g​fxstrand> I submitted last night without WSI. There's nothing in the spec that says a driver has to have WSI
18:25 fdobridge_: <k​arolherbst🐧🦀> that's what we settled with for GL :ferrisUpsideDown:
18:25 fdobridge_: <g​fxstrand> And no one's going to sue us over IP in our WSI implementation.
18:26 fdobridge_: <g​fxstrand> I do want to find/fix the bug if we can because, until we understand and fix it, there's a chance someone will hit it in the wild. Most apps do use WSI, after all.
18:26 fdobridge_: <g​fxstrand> But for the purposes of checking off 1.3 and moving on... I'm kinda meh at this point.
18:57 fdobridge_: <!​DodoNVK (she) 🇱🇹> I wonder what's the difference between Maxwell 1 and 2 (I know Maxwell 2 introduced the high-secure firmware stuff)
19:00 fdobridge_: <g​fxstrand> Maxwell 2 also added the new texture headers
19:03 fdobridge_: <g​fxstrand> Okay, let's try 8 shards with VK_KHR_zero_initialize_workgroup_memory fixed
19:12 fdobridge_: <!​DodoNVK (she) 🇱🇹> I see multiple SM versions for Maxwell (is there any difference between them?)
19:17 fdobridge_: <!​DodoNVK (she) 🇱🇹> Also could codegen be disabled for NVK once SM20 or SM30 support lands? codegen can be useful as a reference for example in that GTA fog bug (but its reliability and performance can be questionable so 🤷‍♀️)
19:24 fdobridge_: <g​fxstrand> Yeah, I'm planning to eventually totally remove it but it'll stay as long as there's hardware we want to enable which NAK doesn't support yet.
19:24 fdobridge_: <g​fxstrand> I've got it pretty well walled off in the compile pipeline so it's not hurting anything.
19:25 fdobridge_: <!​DodoNVK (she) 🇱🇹> Nuking codegen will break the nouveau OpenGL driver though (which will still be needed for old hardware)
19:26 fdobridge_: <g​fxstrand> Well, totaly remove it from NVK
19:26 fdobridge_: <g​fxstrand> It'll stick around for nouveau GL for as long as that's useful
20:35 fdobridge_: <a​zkali> Huh it should be working 🤔
20:35 fdobridge_: <a​zkali> Let me test that then but my rootfs is working
20:54 fdobridge_: <g​fxstrand> @airlied What's the page alignment for VRAM? Is it really 64K?
20:54 fdobridge_: <g​fxstrand> What does nouveau.ko do if we bind with a smaller alignment?
20:55 fdobridge_: <a​irlied> probably lets you do it, not sure it can stop you
20:56 fdobridge_: <g​fxstrand> So can we bind VRAM at a 4k granularty?
20:56 fdobridge_: <g​fxstrand> Is 64K just more efficient then
20:56 fdobridge_: <g​fxstrand> Is 64K just more efficient then? (edited)
20:56 fdobridge_: <a​irlied> it only matters for images
20:56 fdobridge_: <g​fxstrand> Well, images are what we're working with here....
20:56 fdobridge_: <a​irlied> at least I think it does, don't really know what the rules are in the hw
20:57 fdobridge_: <g​fxstrand> @mohamexiety is trying to get sparse residency working and I'm trying to figure out the rules.
20:57 fdobridge_: <a​irlied> start by assuming the kernel isn't enforcing the rules, since we don't know the rules
20:58 fdobridge_: <g​fxstrand> womp womp
20:58 fdobridge_: <a​irlied> you can have 64k pages with a kind attached
20:58 fdobridge_: <a​irlied> now whether you can suballocate multiple images inside a 64k kind block, I'm not sure
20:58 fdobridge_: <g​fxstrand> Okay, that's not the question being asked.
20:58 fdobridge_: <g​fxstrand> We can. It's fine.
20:59 fdobridge_: <g​fxstrand> The bigger question is if the page tables allow us to bind multple discontiguous VRAM segments in the same 64K
20:59 fdobridge_: <g​fxstrand> Like, what is the required alignment of the VM_BIND offset/size parameters
20:59 fdobridge_: <a​irlied> no I think you have one page table entry for the 64k
20:59 fdobridge_: <g​fxstrand> Okay
20:59 fdobridge_: <g​fxstrand> @mohamexiety There's your answer^^
21:00 fdobridge_: <g​fxstrand> Assert everything is 64k aligned in the image bind handling path and we'll figure out what granularity and limits to advertise to make that happen
21:01 fdobridge_: <m​ohamexiety> okay, got it
21:01 fdobridge_: <a​irlied> { 47, &gp100_vmm_desc_16[4], NVKM_VMM_PAGE_Sxxx },
21:01 fdobridge_: <a​irlied> { 38, &gp100_vmm_desc_16[3], NVKM_VMM_PAGE_Sxxx },
21:01 fdobridge_: <a​irlied> { 29, &gp100_vmm_desc_16[2], NVKM_VMM_PAGE_Sxxx },
21:01 fdobridge_: <a​irlied> { 21, &gp100_vmm_desc_16[1], NVKM_VMM_PAGE_SVxC },
21:01 fdobridge_: <a​irlied> { 16, &gp100_vmm_desc_16[0], NVKM_VMM_PAGE_SVxC },
21:01 fdobridge_: <a​irlied> { 12, &gp100_vmm_desc_12[0], NVKM_VMM_PAGE_SVHx },
21:01 fdobridge_: <a​irlied> are the turing options in the kernel
21:01 fdobridge_: <a​irlied> S is sparse, V is VRAM, H is host, and C is comp
21:02 fdobridge_: <a​irlied> so you can have empty sparse maps 47,38,29 bits, then 21 or 16 bits VRAM, and 12 bits vram/host,
21:02 fdobridge_: <a​irlied> so in theory we might be allowed 4k alignment for non-comp images, which is all we support right now
21:09 fdobridge_: <!​DodoNVK (she) 🇱🇹> Any progress for https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26622 ? :nouveau:
22:28 fdobridge_: <g​fxstrand> @airlied typed me a kernel patch for a REBAR query so I should be able to do that and hide it behind REBAR
22:29 fdobridge_: <g​fxstrand> I also need to work up the courage to lane !27205
22:32 fdobridge_: <g​fxstrand> He also typed a kernel patch for getting VRAM size which we should be able to use for "real" memory_budget
22:36 fdobridge_: <!​DodoNVK (she) 🇱🇹> What if I don't have ReBAR?
22:36 fdobridge_: <g​fxstrand> They you either won't get it or you'll get a very small region
22:36 fdobridge_: <g​fxstrand> Like 128M or something
22:36 fdobridge_: <g​fxstrand> Maybe 64M
22:36 fdobridge_: <!​DodoNVK (she) 🇱🇹> Is a small region good enough for gamescope?
22:37 fdobridge_: <g​fxstrand> If you have REBAR, you get the whole thing.
22:37 fdobridge_: <g​fxstrand> Should be
22:37 fdobridge_: <g​fxstrand> 64M is quite a bit for just upload memory
22:37 fdobridge_: <g​fxstrand> You can fit a lot of vertices in 64M
22:43 fdobridge_: <S​id> if you don't have ReBAR, 256mb is the bar size
22:43 fdobridge_: <S​id> on turing
22:43 dj-death: gfxstrand: are you going to upload descriptors like that as well?
22:46 fdobridge_: <g​fxstrand> Yeah, but we also use some of that for the driver
22:46 fdobridge_: <g​fxstrand> I'd rather not but IDK.
22:46 fdobridge_: <S​id> ah, fair
22:46 fdobridge_: <g​fxstrand> dj-death: We can upload descriptors with the DMA engine but ugh...
22:46 fdobridge_: <g​fxstrand> I'd rather just map, I think.
22:47 fdobridge_: <g​fxstrand> Even if I have to keep descriptor buffers in system ram
22:49 fdobridge_: <!​DodoNVK (she) 🇱🇹> What BAR do you like the most? Resizable Snickers BAR? Non-resizable Bounty BAR? 1 GB Mars BAR? 😅
22:50 dj-death: gfxstrand: right
22:50 fdobridge_: <g​fxstrand> I'm a Snickers girl, myself. Though I don't mind an Almond Joy..
22:53 fdobridge_: <!​DodoNVK (she) 🇱🇹> I never heard of Almond Joy
22:58 fdobridge_: <a​irlied> For egpu you really want DMA uploads
22:58 fdobridge_: <g​fxstrand> Yeah...