00:07 fdobridge: <a​irlied> https://paste.centos.org/view/raw/ab1e64cc
00:08 fdobridge: <a​irlied> @karolherbst okay gears doesn't crash but doesn't render with that at least 🙂
00:08 fdobridge: <k​arolherbst🐧🦀> heh.. on X it didn't crash with my branch either 😄
00:08 fdobridge: <k​arolherbst🐧🦀> but yeah...
00:08 fdobridge: <a​irlied> though still seeing some EINVAL in strace
00:08 fdobridge: <k​arolherbst🐧🦀> ohh.. where exactly?
00:09 fdobridge: <k​arolherbst🐧🦀> or rather.. which ioctls
00:09 fdobridge: <a​irlied> doh I screwed up
00:11 fdobridge: <a​irlied> https://paste.centos.org/view/56a9918f crashes on zsbuf still
00:13 fdobridge: <a​irlied> ah yes other parts of the driver rely on the kernel flags
00:13 fdobridge: <k​arolherbst🐧🦀> yeah...
00:15 fdobridge: <a​irlied> so you also need to create vma space and bind for any imported bos
00:15 fdobridge: <k​arolherbst🐧🦀> sure once I test on wayland, but on Xorg I don't have to bother with any of that for now
00:15 fdobridge: <k​arolherbst🐧🦀> but maybe the modesetting DDX side of things can't handle it...
00:16 fdobridge: <k​arolherbst🐧🦀> at which point I probably have to bother anyway 🥲
00:16 fdobridge: <S​id> do we not have access to the hardware's crystal frequency?
00:18 fdobridge: <a​irlied> https://paste.centos.org/view/dc5af086 gets me to exec failing at least 😛
00:18 fdobridge: <k​arolherbst🐧🦀> mhhhh
00:19 fdobridge: <k​arolherbst🐧🦀> why would the exec fail though?
00:21 fdobridge: <k​arolherbst🐧🦀> well anyway, I'll check tomorrow how far you got , but at least for me on X11 the only thing not working was scanout, though I'm not sure if rendering actually did something. But then again, CL examples worked
00:22 fdobridge: <k​arolherbst🐧🦀> though... I had the issue that at some point the exec started to fail
00:24 fdobridge: <p​homes_> I can finally play Transport Fever 2 for more than 5 minutes without it crashing: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28027
00:28 fdobridge: <a​irlied> exec fails because we get a vmfault on the previous exec
00:29 fdobridge: <k​arolherbst🐧🦀> ohh, that's something I didn't get with glxgears at least
00:29 fdobridge: <k​arolherbst🐧🦀> it kept submitting stuff
00:40 fdobridge: <S​id> hmm `means that memory type 1 and 2 (hence mask 0x6) either do not have the required property flags or the corresponding heap is full and the allocation fails that way`
00:59 sadmoments: Can not even find words how retarded you are dudes, such call me mentally ill and harass my friends with their fuck stories call me names of wanker, poison me, assault me, bomb with explosives, impressive leeches criminal record, and do not know shit about science, it's so embarrassing , ouh you get executed rats.
02:15 fdobridge: <a​irlied> @karolherbst so one problem is we need to make sure the same GL driver is in the X server
02:15 fdobridge: <a​irlied> since by not setting the tile flags etc the old GL driver will fail
02:50 fdobridge: <g​fxstrand> @mohamexiety I just pushed to the sparse branch. It's still failing a few tests but the good news is that I think I figured out what hardware bit we were missing to make tiles wider.
02:51 fdobridge: <g​fxstrand> I think this changes our strategy a little bit but should actually make everything simpler over-all.
02:51 fdobridge: <g​fxstrand> What I haven't done yet is rework things to use wide tiles
02:52 fdobridge: <g​fxstrand> Also, wide tiles is the reason why we can't do sparse pre-Maxwell
03:04 HdkR: I assume 750/750ti is disqualified from sparse? :P
03:04 fdobridge: <g​fxstrand> In short, I think our tiling choiceends up looking like
03:04 fdobridge: <g​fxstrand> ```c++
03:04 fdobridge: <g​fxstrand> if ((usage & SPARSE_RESIDENCY) && extent_B <= block_size / 2)
03:04 fdobridge: <g​fxstrand> return block_size_as_tiling;
03:04 fdobridge: <g​fxstrand>
03:04 fdobridge: <g​fxstrand> // Normal tiling calculations
03:04 fdobridge: <g​fxstrand> ```
03:04 fdobridge: <g​fxstrand> No, 750 TI should be fine. That's a Maxwell
03:04 HdkR: Neat, Gen1 was the weirdo gen
03:04 HdkR: Didn't know if they could support it
03:05 fdobridge: <g​fxstrand> Well, at least it has the right texture header version. We'll have to test it to be sure
03:07 fdobridge: <g​fxstrand> @mohamexiety The thing I'm not sure about is how we want to structure the tiling calculations now.
03:08 fdobridge: <g​fxstrand> The original claculation treated each miplevel entirely independently. That worked because we could assume the previous miplevel was the same calculation.
03:09 fdobridge: <g​fxstrand> I'm not sure we want to do it that way anymore.
03:10 fdobridge: <g​fxstrand> Instead, I think we want to select the tiling for level0 and then have a helper which selects the tiling for level N given the tiling for level N-1 and the size of level N.
03:10 fdobridge: <S​id> Faith I had a question or two
03:10 fdobridge: <g​fxstrand> Go for it
03:11 fdobridge: <S​id> 1. what's our hardware's crystal and timestamp frequency? how do I find this info?
03:11 fdobridge: <S​id> 2. heap allocation seems to be failing on my hw, causing OOVMem errors when using ReBAR
03:13 fdobridge: <S​id> on nvk, vulkan info shows heaps like this
03:13 fdobridge: <S​id> ```
03:13 fdobridge: <S​id> memoryHeaps: count = 2
03:13 fdobridge: <S​id> memoryHeaps[0]:
03:13 fdobridge: <S​id> size = 6442450944 (0x180000000) (6.00 GiB)
03:13 fdobridge: <S​id> budget = 0 (0x00000000) (0.00 B)
03:13 fdobridge: <S​id> usage = 0 (0x00000000) (0.00 B)
03:13 fdobridge: <S​id> flags: count = 1
03:13 fdobridge: <S​id> MEMORY_HEAP_DEVICE_LOCAL_BIT
03:13 fdobridge: <S​id> memoryHeaps[1]:
03:13 fdobridge: <S​id> size = 17379098624 (0x40be00000) (16.19 GiB)
03:13 fdobridge: <S​id> budget = 4983881728 (0x129100000) (4.64 GiB)
03:14 fdobridge: <S​id> usage = 0 (0x00000000) (0.00 B)
03:14 fdobridge: <S​id> flags:
03:14 fdobridge: <S​id> None
03:14 fdobridge: <S​id> ```
03:14 fdobridge: <S​id> is budget being 0 a problem?
03:15 fdobridge: <a​irlied> should probably test with a newer kernel
03:15 fdobridge: <S​id> I'm on 6.8-rc6
03:15 fdobridge: <g​fxstrand> 1. I'm not sure. I copied the timestamp frequency from the blob driver and it advertises 1 so it seems to be a ns timer.
03:15 fdobridge: <g​fxstrand> As for the actual crystal frequency, I have no idea. I also don't know why it'd matter
03:16 fdobridge: <g​fxstrand> 2. I'm not sure. What do you mean by an OOVMem error?
03:16 fdobridge: <a​irlied> should probably test with a newer kernel
03:16 fdobridge: <S​id> I was looking at implementations of calibrated timestamps in radv and anv and both seem to depend on crystal freq
03:16 fdobridge: <S​id> Out of Video Memory error
03:17 fdobridge: <S​id> ^
03:17 fdobridge: <g​fxstrand> Yeah, our `timestampPeriod` is 1 and I don't know how we can get the actual frequency
03:17 fdobridge: <S​id> same error for vkd3d-proton apps unless I set no_upload_hvv
03:17 HdkR: 1Ghz is a pretty good timestamp frequency if that's true
03:17 fdobridge: <S​id> hm, okie
03:17 fdobridge: <g​fxstrand> We'll have to just do the best we can
03:17 fdobridge: <a​irlied> there was a bug in rc6 that was fixed in rc7
03:18 fdobridge: <S​id> compiling
03:18 fdobridge: <g​fxstrand> `CreateDevice` returning OOM is weird
03:19 fdobridge: <S​id> ~20 mins, though I have a class in 10, so I'll only be able to verify in about an hour
03:19 fdobridge: <S​id> it is... I'll try again with rc7 before bothering you with it though 😅
03:19 fdobridge: <a​irlied> yeah I doubt it will fix that though
03:20 fdobridge: <a​irlied> I thought it was regular OOM
03:20 fdobridge: <S​id> still worth checking first, imo
03:21 fdobridge: <S​id> this vkd3d-proton config option disables the use of rebar on vkd3d side, which allows apps to function normally right now fwiw
03:21 fdobridge: <S​id> as in, no out of vid mem error, the game boots and loads as far as nvk ca
03:21 fdobridge: <a​irlied> I'm not seeing any path in nvk create device that should return that error
03:21 fdobridge: <S​id> s\/ca/can
03:22 fdobridge: <S​id> also if I revert all the commits here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26622 the error goes away
03:22 fdobridge: <a​irlied> ah descriptor table growing could
03:22 fdobridge: <S​id> I tried adding the commits back one by one but, the error only returns on the last commit which makes sense since that's where we expose the mem types
03:23 fdobridge: <a​irlied> nvk_descriptor_table_grow_locked might be where it happens
03:23 fdobridge: <S​id> haven't had the time to try various permutations 😅
03:24 fdobridge: <g​fxstrand> Quite possibly. You may be running into the budget reporting bug
03:25 fdobridge: <g​fxstrand> That should be fixed up the\se days
03:25 fdobridge: <S​id> but yeah, I ran into this when I made a few gfxr captures of a couple games on proprietary driver and tried to replay then on nvk
03:25 fdobridge: <S​id> which sent me down the rabbit hole
03:25 fdobridge: <S​id> huh
03:25 fdobridge: <g​fxstrand> That should be fixed up these days (edited)
03:26 fdobridge: <a​irlied> oh it this a prop gfxr?
03:26 fdobridge: <a​irlied> I don't think there is really any reason to make sure that works
03:28 fdobridge: <S​id> sure but I'm also running into the same on vkd3d-proton
03:28 fdobridge: <a​irlied> you sure it's the same problem? device memory failure on create device?
03:28 fdobridge: <S​id> this and
03:28 fdobridge: <S​id> this
03:28 fdobridge: <a​irlied> okay that's a different problem
03:28 fdobridge: <a​irlied> to the gfxr one
03:29 fdobridge: <S​id> fair
03:29 fdobridge: <a​irlied> that one might be fixed by rc
03:29 fdobridge: <S​id> will check after this class
03:31 fdobridge: <S​id> also apart from gfxr from prop, what can I do to identify why some games won't work
03:36 fdobridge: <a​irlied> do you actually identify why games aren't working with gfxr from prop?
03:36 fdobridge: <S​id> dunno, first time I tried
03:37 fdobridge: <a​irlied> seems like noise unless you are going to workout what nvk is doing different or wrong
03:37 fdobridge: <S​id> however apitrace from prop was helpful in verifying nvk behaviour a while ago
03:37 fdobridge: <S​id> my metal hellsinger traces come to mind
03:37 fdobridge: <a​irlied> apitrace is usually more portable
03:38 fdobridge: <S​id> yes but this game does not like apitrace
03:38 fdobridge: <a​irlied> I think there is some gfxr work to make them a bit more portable
03:38 fdobridge: <S​id> multiplayer, anti-cheat, all that
03:38 fdobridge: <a​irlied> but if it fails in wierd ways it probably isn't always useful
03:38 fdobridge: <S​id> fair
03:39 fdobridge: <S​id> for elite dangerous I can go the apitrace route, but
03:39 fdobridge: <S​id> no can do for Quake Champions
03:40 fdobridge: <a​irlied> I think gfxcon-replay has some options to use traces on other drivers for some common cases
03:40 fdobridge: <S​id> okie, will look around
03:40 fdobridge: <a​irlied> but I doubt nvidia/nvk diffs will be covered there
03:41 fdobridge: <S​id> yeah, that's fair
03:41 fdobridge: <S​id> would fossilize be any helpful here?
03:41 fdobridge: <S​id> .foz from prop, that is
03:41 fdobridge: <g​fxstrand> I really suspect you're running into budget stuff.
03:42 fdobridge: <S​id> because QC seems to launch with damavand and ziNVK but not with dxvk
03:42 fdobridge: <S​id> damavand being wined3d's vulkan backend
03:43 fdobridge: <S​id> which is weird, considering I'm on mesa/main and rc6
03:44 fdobridge: <S​id> but then again
03:44 fdobridge: <S​id> my hw isn't exactly standard anyway
03:44 fdobridge: <S​id> rebar on turing and all that
03:45 fdobridge: <g​fxstrand> You can disable it by commenting out https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvk_physical_device.c?ref_type=heads#L1167
03:46 fdobridge: <S​id> will try that after I check out rc7 <3
03:46 fdobridge: <g​fxstrand> I don't remember exactly what version the bug is in or where the fix is
03:46 fdobridge: <S​id> hmm, fair
03:47 fdobridge: <S​id> but yeah, I should have calibrated timestamps ready by the weekend at most
03:48 fdobridge: <g​fxstrand> Cool
03:48 fdobridge: <g​fxstrand> For reference, I try to keep this branch up-to-date with what I'm testing on: https://gitlab.freedesktop.org/gfxstrand/linux/-/commits/nvk/?ref_type=heads
03:49 fdobridge: <S​id> gotcha
03:50 fdobridge: <a​irlied> @karolherbst I've pushed the same name branch to my repo, glxgears works for me, but I haven't done the sync import/export
03:52 fdobridge: <a​irlied> but it requires the same nvc0 on both client and server
04:37 fdobridge: <S​id> rc7 fixed mem budget error
04:37 fdobridge: <S​id> proton experimental is updating, will try dx12 after that
04:42 fdobridge: <S​id> okay
04:42 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1215157681975853107/image.png?ex=65fbbac7&is=65e945c7&hm=fed9a82c6f510a3aedc6cdb23bf236478b3a14211e3b1e2355a8d0d048971b62&
04:42 fdobridge: <S​id> @airlied @gfxstrand
04:43 fdobridge: <S​id> mem budget is fine now
04:43 fdobridge: <S​id> ```
04:43 fdobridge: <S​id> memoryHeaps: count = 2
04:43 fdobridge: <S​id> memoryHeaps[0]:
04:43 fdobridge: <S​id> size = 6442450944 (0x180000000) (6.00 GiB)
04:43 fdobridge: <S​id> budget = 5700059136 (0x153c00000) (5.31 GiB)
04:43 fdobridge: <S​id> usage = 0 (0x00000000) (0.00 B)
04:43 fdobridge: <S​id> flags: count = 1
04:43 fdobridge: <S​id> MEMORY_HEAP_DEVICE_LOCAL_BIT
04:43 fdobridge: <S​id> memoryHeaps[1]:
04:43 fdobridge: <S​id> size = 17379098624 (0x40be00000) (16.19 GiB)
04:43 fdobridge: <S​id> budget = 8070889472 (0x1e1100000) (7.52 GiB)
04:43 fdobridge: <S​id> usage = 0 (0x00000000) (0.00 B)
04:43 fdobridge: <S​id> flags:
04:43 fdobridge: <S​id> None
04:43 fdobridge: <S​id> ```
04:50 fdobridge: <S​id> um
04:51 fdobridge: <S​id> hm
04:51 fdobridge: <S​id> proprietary driver exposes 5 memory types
04:53 fdobridge: <g​fxstrand> Ugh... That error is... Unhelpful. 🫤
04:53 fdobridge: <S​id> that's from UE4
04:53 fdobridge: <S​id> let me grab vkd3d log
04:54 fdobridge: <S​id> update, it's 6
04:55 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1215160801619476510/nvkd3d.log?ex=65fbbdaf&is=65e948af&hm=c95763fcb755149ef35eb6a4ba2b2496b18b732f5663043fc2cc8224d193aef8&
05:03 fdobridge: <S​id> also shared this log with some people who know vkd3d-proton better than me
05:08 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1215164023604256798/gfxrecon_capture_20240307T103407.json.gz?ex=65fbc0af&is=65e94baf&hm=ab1422acf86957f64cefe13ec1208a0e800e0f597407caf01287fc6b2cc5e97f&
05:08 fdobridge: <S​id> if anyone wants to trace api calls on this 🐸
05:13 fdobridge: <S​id> I see 3 VK_INCOMPLETEs on vkGetPhysicalDeviceSurfacePresentModesKHR
05:14 fdobridge: <S​id> and one VK_NOT_READY on vkGetFenceStatus
05:25 fdobridge: <S​id> VK_NOT_READY: <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvk_query_pool.c#L691>
07:04 fdobridge: <v​alentineburley> I hope I did everything right: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28033
07:53 fdobridge: <k​arolherbst🐧🦀> yeah.. that's what I kinda was worried about is messing things up
07:53 fdobridge: <r​edsheep> I have updated everything to latest and retested running zink for the session, and I think zink is actually working really well. From what I can tell kwin, even on the new vulkan path, is still having to do some super slow fallback without drm modifiers merged yet. It's super fast and responsive when running a plain openbox (x11) session
07:55 fdobridge: <r​edsheep> Things still seem to really misbehave with plasma wayland, even on the new kde 6 update. I assume that's also modifiers somehow, but I don't really know. It just completely locks my system, even on 6.8rc7
08:04 fdobridge: <k​arolherbst🐧🦀> @airlied also.. why the deduplication? I used a `set` because it already deduplicates the values, no?
08:06 fdobridge: <a​irlied> It didn't seem to at least the kernel was getting 8 of the same syncobj
08:07 fdobridge: <r​edsheep> Nice, the modesetting crash with tf2 is gone now
08:13 fdobridge: <k​arolherbst🐧🦀> ... annoying, maybe I messed up how I do the set
08:13 fdobridge: <k​arolherbst🐧🦀> Will check out what's going wrong there then
08:13 fdobridge: <k​arolherbst🐧🦀> but I used a set for this very reason
08:14 fdobridge: <k​arolherbst🐧🦀> mhhh yeah.. I can reproduce this behavior..
08:16 fdobridge: <k​arolherbst🐧🦀> uhh
08:16 fdobridge: <k​arolherbst🐧🦀> it hashes the pointer...
08:16 fdobridge: <r​edsheep> 🎉
08:17 fdobridge: <r​edsheep> https://cdn.discordapp.com/attachments/1034184951790305330/1215211581575667722/image.png?ex=65fbecfa&is=65e977fa&hm=0c0fc595f49e9ed23085d4194d3ecb558319201f7508bfc295c1be9c3947a72a&
08:17 fdobridge: <r​edsheep> As of now, Baldur's Gate 3 loads. Great work everyone!
08:17 fdobridge: <k​arolherbst🐧🦀> I don't hink `_mesa_set_create_u32_keys` is the thing I want to use here...
08:20 fdobridge: <k​arolherbst🐧🦀> nvm.. I just used it incorrectly
08:20 fdobridge: <r​edsheep> @tom3026 You might want to retest, I have updated your issue as well
08:26 fdobridge: <t​om3026> i have an issue? 😄 but cool must test
08:26 fdobridge: <r​edsheep> Issue 10432 was you, right?
08:27 fdobridge: <t​om3026> doubt it, only one ive done is drm about hdmi not reaching 144hz the rest have gone through discord
08:27 fdobridge: <t​om3026> unless early dementia is hitting
08:27 fdobridge: <k​arolherbst🐧🦀> @airlied but anyway.. have to figure out how to run on an older/newer mesa, because of use cases like flatpak
08:29 fdobridge: <r​edsheep> Oh I see now, that was @phomes_ who opened 10432, well anyway it should work now. Guess it was just a coincidence there's two Tom's saying they want that game to work 😛
08:29 fdobridge: <t​om3026> "Thomas Anderson" i can see why one might think im related but nope 😄
08:35 fdobridge: <S​id> what about vk renderer
08:35 fdobridge: <r​edsheep> In another news the latest mesa and kernel together net an improvement in Talos from 74 to 107 fps (from installed version to installed version, no icds involved so no room for things getting tainted)
08:35 fdobridge: <r​edsheep> The vulkan renderer is generally considered to be worse but I suppose I can test it
08:39 fdobridge: <t​om3026> i dont even get the vk renderer to work on blob
08:40 fdobridge: <r​edsheep> Does it even exist anymore? I don't see the preference for it anymore in the json file
08:42 fdobridge: <t​om3026> @redsheep isnt it just /mnt/stuff/GOG Galaxy/Games/Baldurs Gate 3/bin/ , bg3_d11.exe versus bg3.exe
08:43 fdobridge: <t​om3026> https://imgur.com/9H9dFLj this is all i get running it anyhow
08:43 fdobridge: <t​om3026> on blob
08:43 fdobridge: <t​om3026> i guess could just be my wine being borked but
08:44 fdobridge: <r​edsheep> I was able to enable it by adding the line in the file, oddly I am finding it gets much further than the blob on nvk, it loads to the menu, albeit black. It does crash if you load a save. Either way it doesn't matter, it's not the preferred renderer and the game works with the good one.
08:45 fdobridge: <t​om3026> yeah heh
08:48 fdobridge: <S​id> fair
08:48 fdobridge: <S​id> was just curious
08:51 fdobridge: <t​om3026> now i just gotta figure out why nouveau doesnt power off my gpu so i dont waste 50w when idling on battery and im permanently switched
08:51 fdobridge: <t​om3026> or well as long as im not getting 2 fps in bg3 heh
08:53 fdobridge: <S​id> kernel version?
08:53 fdobridge: <t​om3026> currently 6.7.7
08:53 fdobridge: <t​om3026> but i guess i could try the -rc
08:53 fdobridge: <k​arolherbst🐧🦀> 🥲
08:53 fdobridge: <k​arolherbst🐧🦀> https://cdn.discordapp.com/attachments/1034184951790305330/1215220854707851304/image.png?ex=65fbf59d&is=65e9809d&hm=754558ee342d705f5e19ff6325159287c842713aa0a206b346a5338a08083fb2&
08:53 fdobridge: <S​id> rc unnecessary
08:54 fdobridge: <S​id> gimme 2 mins tho
08:54 fdobridge: <t​om3026> is that what we call HDR, more colors then SDR.
08:54 fdobridge: <k​arolherbst🐧🦀> yes
08:54 fdobridge: <k​arolherbst🐧🦀> I wonder if I can make it all work on legacy mesa..
08:55 fdobridge: <k​arolherbst🐧🦀> but I suspect something @airlied did broke it this way 😄
08:56 fdobridge: <S​id> tom try 6.7.9
08:56 fdobridge: <a​irlied> There is no way with current kernel to mix old and new gl
08:56 fdobridge: <k​arolherbst🐧🦀> well..
08:56 fdobridge: <k​arolherbst🐧🦀> we have to
08:57 fdobridge: <a​irlied> In that case VM bind might not be a good idea
08:57 fdobridge: <k​arolherbst🐧🦀> We could fix the kernel and just not use VM_BIND on the gl side for kernels were it wouldn't work
08:57 fdobridge: <k​arolherbst🐧🦀> how much work would it be on the kernel side to make it all work?
08:58 fdobridge: <a​irlied> the problem is then we have to compromise nvk
08:58 fdobridge: <k​arolherbst🐧🦀> in which sense?
08:58 fdobridge: <a​irlied> It would have to poke the legacy bo metadata into kernel object
08:59 fdobridge: <k​arolherbst🐧🦀> we could special case the GEM object being created the gl way and then it means you have to follow special rules in VM_BIND or something?
08:59 fdobridge: <S​id> @tom3026
09:00 fdobridge: <k​arolherbst🐧🦀> like `tile_flags` and `tile_mode` will be always zero with nvk, no?
09:00 fdobridge: <t​om3026> @tiredchiku
09:00 fdobridge: <a​irlied> No that's the metadata
09:00 fdobridge: <S​id> hi
09:00 fdobridge: <a​irlied> It has to be filled in properly for any shared objects
09:00 fdobridge: <a​irlied> If want to use the old Gl driver
09:00 fdobridge: <t​om3026> @tiredchiku yeah i will, just fetching debug symbols gotta bugreport a kwin systemsettings
09:00 fdobridge: <t​om3026> crash
09:00 fdobridge: <S​id> fair, all the best
09:01 fdobridge: <k​arolherbst🐧🦀> the issue will be that with things like flatpak you'll end up mixing mesa versions on the host and application side
09:01 fdobridge: <k​arolherbst🐧🦀> and it can go either direction
09:02 fdobridge: <k​arolherbst🐧🦀> and I suspect this will also extend to nvk
09:02 fdobridge: <k​arolherbst🐧🦀> there are two different use cases though
09:03 fdobridge: <k​arolherbst🐧🦀> the app using different mesa versions for VK and GL? uhh.. that's super cursed and I don't care at all if that's broken
09:03 fdobridge: <k​arolherbst🐧🦀> but anything compositor <-> application related has to be able to deal with different mesa versions
09:03 fdobridge: <a​irlied> Well we should have fixed that when we add modifiers :-p
09:04 fdobridge: <k​arolherbst🐧🦀> right...
09:04 fdobridge: <k​arolherbst🐧🦀> so the main question for now is, what we do about container use cases
09:05 fdobridge: <a​irlied> Assume nobody cares and declare mesa 24.1 the new bas3
09:05 fdobridge: <k​arolherbst🐧🦀> well.. users will care
09:05 fdobridge: <k​arolherbst🐧🦀> that's not really something we can assume they don't
09:06 fdobridge: <S​id> call it unsupported :3
09:07 fdobridge: <k​arolherbst🐧🦀> though... running older mesa inside a container on top of newer compositor mesa is more important than the reverse
09:07 fdobridge: <S​id> anything below 24.1
09:07 fdobridge: <k​arolherbst🐧🦀> I'd be fine telling distributions to just fix their mesa 😛
09:07 fdobridge: <k​arolherbst🐧🦀> but older mesa in the app + newer mesa in the compositor has to work
09:30 fdobridge: <k​arolherbst🐧🦀> @airlied it works actually...
09:30 fdobridge: <k​arolherbst🐧🦀> at least on X
09:30 fdobridge: <k​arolherbst🐧🦀> if compression is enabled
09:30 fdobridge: <k​arolherbst🐧🦀> (I just allocated * 0x10 memory to not run into GPU crashes)
09:31 fdobridge: <k​arolherbst🐧🦀> so I guess if I figure out what needs to change for compression we are good to go here
09:31 fdobridge: <k​arolherbst🐧🦀> ehh wait
09:31 fdobridge: <k​arolherbst🐧🦀> nouveau didn't load, nvm
09:33 fdobridge: <k​arolherbst🐧🦀> but anyway, I think the corruption is compression related or something silly
09:49 fdobridge: <t​om3026> @tiredchiku didnt you do some magic to not make kwin run xwayland on your second gpu automaticly?
09:49 fdobridge: <t​om3026> or the hdmi audio bits hm
09:49 fdobridge: <S​id> yeah, but
09:49 fdobridge: <S​id> it won't work with nouveau/nvk stack
09:49 fdobridge: <S​id> since no separate egl icd for those
09:50 fdobridge: <t​om3026> yeah probably why its kept powered on then
09:50 fdobridge: <S​id> F
09:50 fdobridge: <S​id> suspend works fine on sway, fwiw
09:50 fdobridge: <t​om3026> oh well just gotta get steam client wayland native and il strip out the entire xorg bit
09:50 fdobridge: <t​om3026> 😄
09:51 fdobridge: <S​id> I was gonna say flatpak it
09:51 fdobridge: <S​id> but
09:51 fdobridge: <S​id> even that relies on system xwayland
09:51 fdobridge: <a​irlied> Compression isn't used properly anyways afaik, I didn't get any misrenders
09:52 fdobridge: <a​irlied> I tested gears vs X server with the VM bind paths
09:54 fdobridge: <k​arolherbst🐧🦀> sure, but did you had the same mesa on the X side?
09:55 fdobridge: <k​arolherbst🐧🦀> but the GPU crash I'm seeing is kinda weird...
09:55 fdobridge: <k​arolherbst🐧🦀> like..
09:55 fdobridge: <k​arolherbst🐧🦀> it only happens if compression is enabled
09:55 fdobridge: <k​arolherbst🐧🦀> and it's in a valid address
09:56 fdobridge: <k​arolherbst🐧🦀> it's even referenced in the push...
09:58 fdobridge: <k​arolherbst🐧🦀> though that might the reason you disabled compression, because the kernel might not map it?
10:05 fdobridge: <a​irlied> Yup same on both sides
10:06 fdobridge: <t​om3026> @redsheep waited like 10 minutes for bg3 menu, the little loading circle spins an inch per minute. gave up and swapped tty
10:06 fdobridge: <t​om3026>
10:06 fdobridge: <t​om3026> ```
10:06 fdobridge: <t​om3026> [ 269.337060] BUG: kernel NULL pointer dereference, address: 00000000000007d8
10:06 fdobridge: <t​om3026> [ 269.337063] #PF: supervisor read access in kernel mode
10:06 fdobridge: <t​om3026> [ 269.337064] #PF: error_code(0x0000) - not-present page
10:07 fdobridge: <t​om3026> [ 269.337065] PGD 0 P4D 0
10:07 fdobridge: <t​om3026> [ 269.337066] Oops: 0000 [#1] PREEMPT SMP
10:07 fdobridge: <t​om3026> [ 269.337068] CPU: 1 PID: 407 Comm: kworker/1:1H Tainted: G S U OE 6.7.9-1 #1 e41996cda849683e7c4867181d037226192e8d49
10:07 fdobridge: <t​om3026> [ 269.337069] Hardware name: LENOVO 82WQ/LNVNB161216, BIOS KWCN42WW 09/15/2023
10:07 fdobridge: <t​om3026> [ 269.337070] Workqueue: ttm ttm_bo_delayed_delete [ttm]
10:07 fdobridge: <t​om3026> [ 269.337076] RIP: 0010:nouveau_mem_fini+0x4f/0x230 [nouveau]
10:07 fdobridge: <t​om3026>
10:07 fdobridge: <t​om3026> [ 269.337134] Call Trace:
10:07 fdobridge: <t​om3026> [ 269.337136] <TASK>
10:07 fdobridge: <t​om3026> [ 269.337137] ? __die_body+0x68/0xc0
10:07 fdobridge: <t​om3026> [ 269.337139] ? page_fault_oops+0x3af/0x400
10:07 fdobridge: <t​om3026> [ 269.337140] ? exc_page_fault+0x54a/0x6e0
10:07 fdobridge: <t​om3026> [ 269.337142] ? asm_exc_page_fault+0x22/0x30
10:07 fdobridge: <t​om3026> [ 269.337144] ? nouveau_mem_fini+0x4f/0x230 [nouveau cb645e7c7b136ca5c192d67c701d581c9e4e899e]
10:07 fdobridge: <t​om3026> [ 269.337180] ? nouveau_bo_move_ntfy+0x1ca/0x200 [nouveau cb645e7c7b136ca5c192d67c701d581c9e4e899e]
10:07 fdobridge: <t​om3026> [ 269.337214] ? dma_fence_default_wait+0x1a0/0x1a0
10:07 fdobridge: <t​om3026> [ 269.337215] ? dma_resv_wait_timeout+0x162/0x1e0
10:07 fdobridge: <t​om3026> [ 269.337216] nouveau_ttm_tt_unpopulate+0x34/0x60 [nouveau cb645e7c7b136ca5c192d67c701d581c9e4e899e]
10:07 fdobridge: <t​om3026> [ 269.337251] ttm_tt_unpopulate+0x29/0x90 [ttm 0470f27a705dc28a702f24834508c3abde9c5775]
10:07 fdobridge: <t​om3026> [ 269.337255] ttm_bo_delayed_delete+0x65/0xa0 [ttm 0470f27a705dc28a702f24834508c3abde9c5775]
10:07 fdobridge: <t​om3026> ```
10:07 fdobridge: <p​homes_> I am at work so cannot test right now. I only test the vulkan renderer. Also my card does not have rebar which I think is where things break for me
10:07 fdobridge: <t​om3026> it was like its chugging down the entire wayland session to 1fps too until i killed it heh
10:08 fdobridge: <a​irlied> Yes kernel doesn't seem to map properly with compressed there
10:09 fdobridge: <k​arolherbst🐧🦀> okay
10:09 fdobridge: <k​arolherbst🐧🦀> can it be figured out?
11:02 eric_engestrom: (dropping in because I happened to look at this channel, but I don't usually follow so tag me if you want me to see a message)
11:02 eric_engestrom: for the container case (eg. flatpak), isn't virgl/virtio/venus the solution here?
11:02 karolherbst: eric_engestrom: container as in flatpak
11:09 eric_engestrom: karolherbst: I'm not sure what you mean?
11:10 karolherbst: like.. within flatpak containers you usually use the native driver
11:11 karolherbst: and if a different mesa version is used in there and it breaks stuff, that's bad
11:11 karolherbst: and we can't really rely on future solutions here either
11:11 fdobridge: <a​irlied> @karolherbst i don't think we know the correct rules around compression VM mappings
11:12 fdobridge: <a​irlied> It sounds like @gfxstrand needs to compromise on one of the bad paths and pick the least bad
11:12 eric_engestrom: karolherbst: yeah but that's my point: whouldn't the solution be to use virgl in the flatpak instead of trying to use a potentially incompatible version of the native driver?
11:12 fdobridge: <k​arolherbst🐧🦀> okay fair.. but why was the GL driver able to use them?
11:13 karolherbst: eric_engestrom: maybe? But that's not up to us to decide
11:13 fdobridge: <a​irlied> Because the GL driver is broken with modifiers
11:13 fdobridge: <k​arolherbst🐧🦀> mhh, fair
11:13 fdobridge: <a​irlied> And doesn't do separate bo and vm
11:13 fdobridge: <a​irlied> So it binds VM attributes as bo metadata
11:14 fdobridge: <k​arolherbst🐧🦀> but I guess we have to figure this out for vulkan anyway, no?
11:14 fdobridge: <a​irlied> And assumes when sharing the other side will to
11:14 fdobridge: <k​arolherbst🐧🦀> like.. compression mappings
11:14 fdobridge: <a​irlied> That's like a project for when someone get compression properly RE
11:14 fdobridge: <a​irlied> My guess is the GL driver is just setting bits for no benefit
11:14 eric_engestrom: karolherbst: well, it could be, if we decide "mixing different versions of mesa inside and outside the container is not supported" they will have to use the next option
11:15 karolherbst: eric_engestrom: fair, but I'm not in the mood for such discussions as the obvious response will be: "but that's going to be pain for any mesa developer"
11:15 karolherbst: like.. if I need to restart my compositor to bisect a bug in mesa I probably just won't
11:16 eric_engestrom: mesa dev? you mean app dev?
11:16 karolherbst: no, it's a pain for mesa devs
11:16 eric_engestrom: ah
11:16 eric_engestrom: yeah your example made it cleare
11:16 eric_engestrom: *clearer
11:16 karolherbst: so yeah.. I think to make it easier to bisect mesa we have to keep the guarantee that it all works
11:16 eric_engestrom: I'm not saying "we should make sure that use case is broken" but "that use case is not supported so don't do it in prod"
11:17 karolherbst: sure, but if I can't bisect stuff because of it, it's still bad
11:17 eric_engestrom: fair
11:18 eric_engestrom: ok so my suggestion of not supporting it is bad, but I think my suggestion of having containers systems not rely on it is still valid
11:18 eric_engestrom: but then we're back to your point, it's their decision not ours
11:19 eric_engestrom: thanks :)
11:19 fdobridge: <k​arolherbst🐧🦀> mhhh
11:19 fdobridge: <k​arolherbst🐧🦀> but disabling it in older mesa is also not really an option sadly
11:20 fdobridge: <k​arolherbst🐧🦀> though...
11:20 fdobridge: <k​arolherbst🐧🦀> we could ignore the bit in the kernel...
11:20 fdobridge: <k​arolherbst🐧🦀> but that's going to be a pain as well
11:20 fdobridge: <k​arolherbst🐧🦀> because I don't think it's a bit at all
12:18 fdobridge: <m​ohamexiety> oh wow, that's really nice. I thought we couldn't touch tiles' width at all. now we can exactly match the std block shapes
12:18 fdobridge: <m​ohamexiety> (which tests fail btw?)
12:22 fdobridge: <m​ohamexiety> that makes sense, got it
13:37 fdobridge: <g​fxstrand> Great! But does it play? 😅
13:39 fdobridge: <g​fxstrand> There's a set of tests that use power-of-two image sizes and assert that the mip tail start LOD is at least some level. We're starting it too quickly. That should be fixable with wide tiles.
13:44 fdobridge: <m​ohamexiety> I see
13:44 fdobridge: <g​fxstrand> Nice!
13:46 fdobridge: <z​mike.> is VK_FORMAT_R4G4B4A4_UNORM_PACK16 really not supported for color rendering?
13:47 fdobridge: <z​mike.> @karolherbst @gfxstrand
13:49 fdobridge: <g​fxstrand> Yes and no. In theory, when we have modifiers, current nouveau GL is providing redundant data. The modifier data and the BO data are the same. If new GL and/or Zink only use the modifier data, they should be fine as long as we're willing to assume your system Mesa is the modern one.
13:50 fdobridge: <g​fxstrand> 🤷🏻‍♀️ I'll have to poke at it. I stole the tables from the old GL driver and they're probably out of date.
13:50 fdobridge: <z​mike.> trying to parse this macro table to see if I can test it...
13:51 fdobridge: <k​arolherbst🐧🦀> yeah.. I think assuming system mesa is modern is something we can do if the alternative is too much work
13:52 fdobridge: <k​arolherbst🐧🦀> though there might also be like Ubuntu LTS users firing up some modern flatpak...
13:53 fdobridge: <g​fxstrand> The hail Mary option is to burn the old modifiers and create new ones for NVK and new GL.
13:54 fdobridge: <k​arolherbst🐧🦀> but then we still have to figure out how to run new/old gl on old/new gl
13:55 fdobridge: <k​arolherbst🐧🦀> and atm the problem to solve here is how to use compression stuff
14:06 fdobridge: <z​mike.> hmmm well I tested and I think it might be correct 🤕
14:06 fdobridge: <z​mike.> or at least it's not a trivial enable
14:37 fdobridge: <g​fxstrand> I really need to turn that macro table into a CSV file
14:38 fdobridge: <g​fxstrand> The good news is that a VM_BIND driver should still be able to read the flags set on the BO by a non-VM_BIND driver
14:39 fdobridge: <g​fxstrand> So you can pull the tile mode and PTE kind out of the BO and then VM_BIND it with that
14:39 fdobridge: <k​arolherbst🐧🦀> okay. So the current issue is, that bos with compression set by the VM_BIND driver aren't getting mapped into the VM 🥲 And the old gl driver just assumes compression or something
14:39 fdobridge: <g​fxstrand> Again, that assumes the old driver was the one to allocate the BO
14:39 fdobridge: <k​arolherbst🐧🦀> I haven't debugging _why_ the output is so trashy though
14:39 fdobridge: <g​fxstrand> For new on old, we have to use linear
14:40 fdobridge: <k​arolherbst🐧🦀> yeah.. but this is new GL rendering something and old gl on the compositor and the content is all corrupted as seen in the screenshot
14:40 fdobridge: <k​arolherbst🐧🦀> it's all with linear
14:40 fdobridge: <k​arolherbst🐧🦀> because I tested on X
14:40 fdobridge: <k​arolherbst🐧🦀> no modifiers at play at all
14:41 fdobridge: <k​arolherbst🐧🦀> or mhh.. maybe on the compositor side? though I think that's till linear? mhh
14:41 fdobridge: <k​arolherbst🐧🦀> but I haven't seen any buffers exported, but maybe I have to check again with daves patches
14:42 fdobridge: <g​fxstrand> You have to be careful. nvc0 will use tiled even when there aren't modifiers. It just trusts in the BO bits.
14:43 fdobridge: <k​arolherbst🐧🦀> mhhh..
14:43 fdobridge: <k​arolherbst🐧🦀> sure, but uhhm...
14:43 fdobridge: <k​arolherbst🐧🦀> not sure if that's due to bad tiling
14:43 fdobridge: <k​arolherbst🐧🦀> or maybe it is...
14:43 fdobridge: <g​fxstrand> That looks like one thing is tiling and the other thinks it's linear
14:44 fdobridge: <k​arolherbst🐧🦀> ... okay
14:44 fdobridge: <k​arolherbst🐧🦀> so maybe it's that then...
14:44 fdobridge: <k​arolherbst🐧🦀> uhh.. that would be annoying
14:44 fdobridge: <g​fxstrand> If it were just bad tiling, it wouldn't be stretched like that.
14:44 fdobridge: <k​arolherbst🐧🦀> ahh.. right
14:44 fdobridge: <k​arolherbst🐧🦀> _anyway_ it works if both sides use VM_BIND...
14:44 fdobridge: <g​fxstrand> (Side note: Being able to detect what kind of tiling issue something is just by looking at it has got to be one of the strangest skills I've ever acquired.)
14:45 fdobridge: <k​arolherbst🐧🦀> okay, then even with compression enabled, I'd probably see the same result
14:46 fdobridge: <k​arolherbst🐧🦀> so basically I just hit the bug you wanted to see fixed in the first place 🥲
14:47 fdobridge: <r​edsheep> I think latest kernel is important for getting it to load
14:49 fdobridge: <g​fxstrand> A variation of it, yes.
14:49 fdobridge: <g​fxstrand> The actual bug I was hitting only seems to happen on Kepler. I think the usual `pte_kind=0, tile_mode=0` doesn't actually mean linear there.
14:49 fdobridge: <k​arolherbst🐧🦀> ohh.. yeah, that wouldn't surprised me at all
14:50 fdobridge: <k​arolherbst🐧🦀> *surprise
14:50 fdobridge: <k​arolherbst🐧🦀> I wonder what options we'd have to make new gl interoperate with old gl properly
14:52 fdobridge: <g​fxstrand> For this one, I think we just have to figure out what the right kind/mode is and teach the kernel to use that for VM_BIND BOs instead of 0,0
14:55 fdobridge: <g​fxstrand> We have the same options we've always had:
14:55 fdobridge: <g​fxstrand> 1. Let old BOs work with VM_BIND, re-define the modifiers as "you also have to set the BO metadata", and poison NVK by requiring dedicated allocations forever
14:55 fdobridge: <g​fxstrand> 2. Define the old modifiers as "you have to set BO metadata", burn them, and make new ones for NVK. Any old<->new interactions will require linear.
14:55 fdobridge: <g​fxstrand> 3. Somehow retroactively fix old GL.
14:55 fdobridge: <g​fxstrand> Just replace NVK with "VM_GL" and it's the same set of options.
14:55 fdobridge: <g​fxstrand> We have the same options we've always had:
14:55 fdobridge: <g​fxstrand> 1. Let old BOs work with VM_BIND, re-define the modifiers as "you also have to set the BO metadata", and poison NVK by requiring dedicated allocations forever
14:55 fdobridge: <g​fxstrand> 2. Define the old modifiers as "you have to set BO metadata", burn them, and make new ones for NVK. Any old<->new interactions will require linear.
14:55 fdobridge: <g​fxstrand> 3. Somehow retroactively fix old GL.
14:56 fdobridge: <g​fxstrand> Just replace NVK with "VM_GL" and it's the same set of options. (edited)
14:56 fdobridge: <g​fxstrand> We have the same options we've always had:
14:56 fdobridge: <g​fxstrand> 1. Let old BOs work with VM_BIND, re-define the modifiers as "you also have to set the BO metadata", and poison NVK by requiring dedicated allocations forever
14:56 fdobridge: <g​fxstrand> 2. Define the old modifiers as "you have to set BO metadata", burn them, and make new ones for NVK. Any old<->new interactions will require linear.
14:56 fdobridge: <g​fxstrand> 3. Somehow retroactively fix old GL.Just replace NVK with "VM_GL" and it's the same set of options. (edited)
14:56 fdobridge: <g​fxstrand> We have the same options we've always had:
14:56 fdobridge: <g​fxstrand> 1. Let old BOs work with VM_BIND, re-define the modifiers as "you also have to set the BO metadata", and poison NVK by requiring dedicated allocations forever
14:56 fdobridge: <g​fxstrand> 2. Define the old modifiers as "you have to set BO metadata", burn them, and make new ones for NVK. Any old<->new interactions will require linear.
14:56 fdobridge: <g​fxstrand> 3. Somehow retroactively fix old GL.
14:56 fdobridge: <g​fxstrand> Just replace NVK with "VM_GL" and it's the same set of options. (edited)
14:56 fdobridge: <g​fxstrand> (Sorry to those on the bridge)
14:56 fdobridge: <k​arolherbst🐧🦀> 1. is something we shouldn't do I guess...
14:57 fdobridge: <k​arolherbst🐧🦀> is 3. we could do on the kernel side?
14:58 fdobridge: <k​arolherbst🐧🦀> *something
14:58 fdobridge: <g​fxstrand> Not really
14:58 fdobridge: <g​fxstrand> Really, at this point I think we should just do 2
14:58 fdobridge: <k​arolherbst🐧🦀> yeah....
14:58 fdobridge: <g​fxstrand> The annoying bit is that we'll have to re-plumb the display code to support both sets of modifiers.
14:58 fdobridge: <g​fxstrand> Annoying but probably not the worst thing we could do.
14:59 fdobridge: <g​fxstrand> They won't really be different from the display PoV.
14:59 fdobridge: <k​arolherbst🐧🦀> but support for old ones might be something we can throw away in 10 years
14:59 fdobridge: <g​fxstrand> It's just more entries in a table somewhere.
14:59 DodoGTA: gfxstrand: I now know you edited that message 3 times
15:00 fdobridge: <g​fxstrand> I was trying to get bullets to work. 😅
15:00 fdobridge: <k​arolherbst🐧🦀> but yeah... given the option and circumstances, I think 2. is less work overall
15:00 fdobridge: <k​arolherbst🐧🦀> and user support is also work
15:00 fdobridge: <g​fxstrand> And 2 actually has a shot at working
15:00 fdobridge: <k​arolherbst🐧🦀> yeah... breaking new-old is a support nightmare
15:00 fdobridge: <z​mike.> good news: I think I just fixed all the remaining glcts fails except:
15:00 fdobridge: <z​mike.> * the nvk hangs
15:00 fdobridge: <z​mike.> * that one case where it has to compile a shader with MS images (maybe I just delete this in zink if I see it since I know it can't be used?)
15:00 fdobridge: <z​mike.> * one multisample-related nvk bug
15:01 fdobridge: <z​mike.> good news: I think I just fixed all the remaining glcts fails except:
15:01 fdobridge: <z​mike.> * the 2 nvk hangs
15:01 fdobridge: <z​mike.> * that one case where it has to compile a shader with MS images (maybe I just delete this in zink if I see it since I know it can't be used?)
15:01 fdobridge: <z​mike.> * one multisample-related nvk bug (edited)
15:02 fdobridge: <k​arolherbst🐧🦀> @gfxstrand is the "you have to set BO metadata" from 2. something the current new UAPI even allows?
15:02 fdobridge: <k​arolherbst🐧🦀> well.. if you mean set metadata on `GEM_CREATE` then the answer is no :ferrisUpsideDown:
15:02 fdobridge: <g​fxstrand> No, it isn't
15:02 fdobridge: <g​fxstrand> And that's why NVK will just never support the old modifiers.
15:03 fdobridge: <k​arolherbst🐧🦀> yeah, that's fair
15:03 fdobridge: <k​arolherbst🐧🦀> but how would new GL do it?
15:03 fdobridge: <r​edsheep> Yes and no, I can load a save but it's slow enough not to really play well, 12 fps or so.
15:03 fdobridge: <!​DodoNVK (she) 🇱🇹> ~~Did you waste a lot of them in the process?~~
15:04 fdobridge: <k​arolherbst🐧🦀> or I guess it also wouldn't...
15:04 fdobridge: <g​fxstrand> new GL wouldn't either
15:04 fdobridge: <k​arolherbst🐧🦀> which just means I have to figure out why the output is so messed up and how to make it all work...
15:05 fdobridge: <g​fxstrand> Or we can just bin the old GL driver. 😜
15:05 fdobridge: <k​arolherbst🐧🦀> I wished we had that option
15:06 fdobridge: <r​edsheep> Why isn't that an option? Does it not work to just say nvc0 doesn't support Maxwell or turing and up?
15:06 fdobridge: <k​arolherbst🐧🦀> flatpaks mostly
15:07 fdobridge: <k​arolherbst🐧🦀> like.. some users on ubuntu LTS 20.04 in 2026 decides to run new chrome flatpak
15:07 fdobridge: <S​id> we can still say we only support the thingy that ships nvk+zink
15:07 fdobridge: <S​id> it's not hard to tell flatpak which driver thingy to use
15:07 fdobridge: <r​edsheep> If you can't tell the flatpaks to render with zink yeah that makes sense that it's a problem
15:07 fdobridge: <S​id> sorry, words hard, brain mush
15:08 fdobridge: <k​arolherbst🐧🦀> they might even ship with a gl runtime where nvk isn't really working or built yet
15:08 fdobridge: <k​arolherbst🐧🦀> or well.. zink
15:08 fdobridge: <k​arolherbst🐧🦀> or something something
15:08 fdobridge: <S​id> right, gl runtime
15:08 fdobridge: <k​arolherbst🐧🦀> the other direction is also possible...
15:08 fdobridge: <k​arolherbst🐧🦀> like.. somebody running a flatpak with an old GL runtime
15:09 fdobridge: <k​arolherbst🐧🦀> (or like developers doing that with `git bisect`)
15:11 fdobridge: <S​id> I have decided I am never using flatpak
15:11 fdobridge: <S​id> because prime render offload is still ultra wonky in it
15:14 fdobridge: <k​arolherbst🐧🦀> ohh.. yeah, that's true
16:26 fdobridge: <g​fxstrand> I think if we go with plan 2 and do it properly, we can make all the interesting cases work.
16:27 fdobridge: <g​fxstrand> Well, the case of old on new is tricky but I think we can probably come up with something.
16:27 fdobridge: <g​fxstrand> Like we support the old modifiers but only for texturing or something like that.
16:28 fdobridge: <g​fxstrand> It's possible for NVK or NGL to import the BOs from the old driver and extract the tiling bits from them.
16:28 fdobridge: <g​fxstrand> We just can't allocate tiled BOs
16:28 fdobridge: <k​arolherbst🐧🦀> yeah... that's fine
16:28 fdobridge: <k​arolherbst🐧🦀> supporting anything more than linear imported bos from Old GL is out of scope
16:28 fdobridge: <g​fxstrand> Yeah, so plan 2 then
16:29 fdobridge: <g​fxstrand> With plan 2, we should get linear whenever old is talking to new
16:29 fdobridge: <k​arolherbst🐧🦀> tiled bos are only really relevant for compositors (where you use NGL) or tegra (where we strongly advise to use NGL)
16:29 fdobridge: <g​fxstrand> Just so we're clear, by NGL I mean "new GL"
16:29 fdobridge: <k​arolherbst🐧🦀> same
16:29 fdobridge: <g​fxstrand> Cool
16:30 fdobridge: <g​fxstrand> Just making sure. 😅
16:30 fdobridge: <k​arolherbst🐧🦀> I still have to figure out how to manage sync obs properly, because atm I'm leaking all of them 🥲
16:31 fdobridge: <!​DodoNVK (she) 🇱🇹> That's a new acronym
16:32 fdobridge: <k​arolherbst🐧🦀> yes, because `nouveau` is just too confusing as a gl driver name, the new one is going to be called NGL
16:33 fdobridge: <r​edsheep> Seems like a good acronym, not gonna lie
16:33 fdobridge: <m​arysaka> petition to call the old driver "ancien" and the new one "nouveau"
16:33 fdobridge: <k​arolherbst🐧🦀> I mean that's why it's called NGL: nouveau GL
16:34 fdobridge: <!​DodoNVK (she) 🇱🇹> What architectures will it support?
16:34 fdobridge: <k​arolherbst🐧🦀> good question
16:37 fdobridge: <t​om3026> You cant make nouveau2 that supports only turing and up and drop all old stuff? 😄
16:38 fdobridge: <k​arolherbst🐧🦀> mhh
16:38 fdobridge: <k​arolherbst🐧🦀> for that you can also just use zink
16:40 fdobridge: <!​DodoNVK (she) 🇱🇹> So could nouveau GL be pre-Kepler only? :nouveau:
16:40 fdobridge: <k​arolherbst🐧🦀> no
16:40 fdobridge: <k​arolherbst🐧🦀> that's cursed
16:40 fdobridge: <k​arolherbst🐧🦀> I mean...
16:40 fdobridge: <k​arolherbst🐧🦀> in theory yes
16:40 fdobridge: <k​arolherbst🐧🦀> but it's still a bit cursed
16:41 fdobridge: <k​arolherbst🐧🦀> supporting a bit more than fermi is not _that_ much work
16:41 fdobridge: <k​arolherbst🐧🦀> but anyway.. this will be interesting once somebody write NGL
16:42 fdobridge: <r​edsheep> Are you talking about actually making a GL driver that's separate from nvc0, not just an update to it?
16:42 fdobridge: <!​DodoNVK (she) 🇱🇹> So is Vulkan possible on Fermi too? I think I've seen some testing of that
16:51 fdobridge: <!​DodoNVK (she) 🇱🇹> https://gitlab.freedesktop.org/drm/nouveau/-/issues/335 :nouveau:
17:10 fdobridge: <i​llwieckz> there is already `nouveau_vieux` 🧐
17:14 fdobridge: <i​llwieckz> Actually a nouveau-ng driver being named `renouveau` would have been fun, but the name was already taken by some nouveau reverse-engineering tool if I'm right
17:17 fdobridge: <!​DodoNVK (she) 🇱🇹> Yes (I don't think anyone uses it anymore)
19:15 fdobridge: <t​om3026> was looking at opengpu driver, nvidia-settings etc. seems their tools uses the closed source nvml library and does some blackmagic fetching from the driver from what i can tell
19:16 fdobridge: <t​om3026> so wont be that easy to "scrape" for a half lost meme generator like me
19:54 fdobridge: <w​aelunix> @tiredchiku did the hibernate patch get merged through?
19:58 fdobridge: <S​id> yes, kernel 6.7.9 and 6.8-rc7
19:58 fdobridge: <S​id> @waelunix
19:59 fdobridge: <w​aelunix> Oof, I guess i'll still have to compile with patches on. NixOS still on 6.7.4 AFAIK 🥲
19:59 fdobridge: <w​aelunix> Thanks for the response, sorry for pinging you
20:00 fdobridge: <S​id> no worries
20:00 fdobridge: <S​id> nixpkgs unstable should have the kernels
20:01 fdobridge: <w​aelunix> Yes but it's not recommended to use main, just `nixos-unstable` which is different from `nixpkgs-unstable`/main AFAIK
20:02 fdobridge: <S​id> :\
20:02 fdobridge: <S​id> welp
20:02 fdobridge: <S​id> soon™
20:09 fdobridge: <a​irlied> @gfxstrand does burning modifiers actually matter?
20:10 fdobridge: <a​irlied> If we are saying you need latest GL in the compositor side, and legacy GL is always reading metadata and ignoring modifiers but is only on the client side
20:11 fdobridge: <a​irlied> We still need to set the metadata from either ngl/zink which means nvk needs to set it
20:11 fdobridge: <a​irlied> Legacy GL will never render to linear I don't think
20:13 fdobridge: <k​arolherbst🐧🦀> I wished we could say that, but sadly it's hypothetical. I'm all for requiring newest mesa all the time, but sadly users on ubuntu LTS are a thing
20:13 fdobridge: <k​arolherbst🐧🦀> and I'm in no mood wasting more time with debian/ubuntu devs, because they don't backport things we need for things to work
20:14 fdobridge: <w​aelunix> living on ubuntu lts 20 is pain TT. curse you vendor lock in ✊
20:15 fdobridge: <a​irlied> So lts users running 24.x flatpaks?
20:15 fdobridge: <k​arolherbst🐧🦀> yeah
20:15 fdobridge: <k​arolherbst🐧🦀> which is actually an important use case to run updated software on distro not updating stuff 🥲 so we can't really ignore that
20:17 fdobridge: <k​arolherbst🐧🦀> and I'm kinda not in the mood having to tell users every week that their discord flatpak doesn't work because their system mesa is out of date and not supported by us
20:20 fdobridge: <J​oshie with Max-Q Design> wouldnt the old GL driver only know about old modifers so itd just fallback to linear?
20:21 fdobridge: <k​arolherbst🐧🦀> yeah.. that was the idea of creating new modifiers
20:24 fdobridge: <a​irlied> I suppose if you get invalid modifier you have to fallback to reading the metadata, but I'm pretty sure if you get a valid modifier things should work fine
20:24 fdobridge: <a​irlied> So I'm not seeing what new modifiers buy us
20:27 fdobridge: <g​fxstrand> new modifiers means that the modifier negotiation will never succeed when there's this driver mismatch.
20:28 fdobridge: <g​fxstrand> In that case, the only common modifier will be LINEAR and they'll fall back to that.
20:28 fdobridge: <g​fxstrand> If both drivers are NVK or if it's NVK and NGL, they'll be able to successfully negotiate one of the new modifiers.
20:28 fdobridge: <g​fxstrand> If both drivers are OGL, they'll negotiate the old modifiers.
20:29 fdobridge: <a​irlied> That doesn't help with when you get INVALID though
20:29 fdobridge: <g​fxstrand> They'll both support LINEAR so you'll never end up with invalid unless you're on a driver so old that it doesn't have modifiers
20:30 soreau: NGL makes sense but OGL is somewhat ambiguous.. is it Open or Old?
20:30 fdobridge: <a​irlied> A new GL with and old GL negotiating LINEAR would need some lifting on the new GL side
20:31 soreau: Though I suppose with the advent of Vulkan, might as well be s/Open/Old/ across the board :P
20:31 fdobridge: <a​irlied> Since the GL driver has no render to linear paths
20:32 fdobridge: <g​fxstrand> It doesn't? Then how does optimus work at all?
20:32 fdobridge: <a​irlied> That is a separate blit
20:32 fdobridge: <g​fxstrand> ah
20:32 fdobridge: <a​irlied> From vram to system memory
20:32 fdobridge: <a​irlied> Would suck for non prime
20:36 soreau: Is it mandatory that the old nouveau path works with new kernel modifier layout? Can't the driver just print a message to update and abort?
20:37 fdobridge: <a​irlied> I don't think the modifiers matter I think the problem case is invalid and linear modifiers anyways
20:37 fdobridge: <a​irlied> What should I render to if I have no information, and does that mean I have to read and set metadata
20:39 fdobridge: <g​fxstrand> So VM_BIND drivers can still import non-VM_BIND BOs. We just can't create them.
20:39 fdobridge: <g​fxstrand> And OGL can import linear
20:39 fdobridge: <g​fxstrand> So I think we have paths that will cover all the cases
20:39 fdobridge: <g​fxstrand> We just need to figure out a strategy so those paths get used.
20:40 fdobridge: <g​fxstrand> Not that I particularly want to import non-VM_BIND BOs into Vulkan—it's a real pain—but we can.
20:44 fdobridge: <z​mike.> @karolherbst idk if you or anyone else tracks the current nouveau (GL) baseline in git, but if you care about keeping it updated you probably want to test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28030 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28055
20:44 fdobridge: <z​mike.> I imagine that combined they a lot of the fails there
20:45 fdobridge: <k​arolherbst🐧🦀> okay, will take a look tomorrow if I don't forget, otherwise ping me or something
20:46 fdobridge: <a​irlied> OGL can't render to imported linear
20:47 fdobridge: <a​irlied> It needs the metadata
20:54 fdobridge: <k​arolherbst🐧🦀> @gfxstrand @airlied there is like one other option we have: backport VM_BIND back to the oldest mesa in use in ubuntu or something and just tell each distribution they have to pick those patches otherwise nouveau will be broken for those use cases
20:54 fdobridge: <k​arolherbst🐧🦀> though...
20:54 fdobridge: <k​arolherbst🐧🦀> not sure they would 🥲
20:54 fdobridge: <k​arolherbst🐧🦀> and I'm not sure we want to do enough testing to make sure nothing breaks
20:56 fdobridge: <k​arolherbst🐧🦀> (or we do official mesa releases...)
21:11 fdobridge: <a​irlied> considering most of those are dead upstream, it seems less likely that anyone will notice or care
21:12 fdobridge: <k​arolherbst🐧🦀> yeah....
21:12 fdobridge: <k​arolherbst🐧🦀> I just mentioned it in case we consider something even worse
21:28 fdobridge: <g​fxstrand> Ugh... We need to use "real" 3D storage images for sparse...
21:28 fdobridge: <J​oshie with Max-Q Design> that's just not gonna work out 🐸
21:29 fdobridge: <k​arolherbst🐧🦀> let me dream
21:29 fdobridge: <J​oshie with Max-Q Design> The best solution is usually the easiest one: Not care and just deal with the incompatibility 🐸
21:29 fdobridge: <k​arolherbst🐧🦀> I just want to wake up one morning and see distributions proactively backporting fixes so I won't have to tell users their mesa is out of date despite them saying it's the newest
21:30 fdobridge: <g​fxstrand> So here's a thought.... What are the chances someone's going to have a 20.04 LTS with a 6.8+ kernel that can actually run their VM_BIND flatpack?
21:30 fdobridge: <k​arolherbst🐧🦀> .... I have better things to do than to close a bugs for the rest of my life 😄
21:30 fdobridge: <k​arolherbst🐧🦀> like those people using ppas to get newest GPU drivers?
21:30 fdobridge: <k​arolherbst🐧🦀> though then they also have newest mesa...
21:30 fdobridge: <k​arolherbst🐧🦀> I hope
21:30 fdobridge: <g​fxstrand> Mesa is way easier to update than your kernel
21:31 fdobridge: <J​oshie with Max-Q Design> I mean NVK basically needs 6.7 anyway, that's a pretty big forcing factor
21:31 fdobridge: <J​oshie with Max-Q Design> So even if newer Mesa, it wouldn't work
21:31 fdobridge: <g​fxstrand> 6.6 but yea
21:31 fdobridge: <k​arolherbst🐧🦀> yeah.. but the problem is like... old GL and new GL
21:31 fdobridge: <k​arolherbst🐧🦀> but yeah...
21:31 fdobridge: <k​arolherbst🐧🦀> it needs a new kernel to even run into the issue...
21:32 fdobridge: <k​arolherbst🐧🦀> so it's then new GL on the host and some flatpak being stuck with mesa 23.1 for silly reasons
21:32 fdobridge: <g​fxstrand> That we can handle
21:33 fdobridge: <k​arolherbst🐧🦀> yeah...
21:33 fdobridge: <k​arolherbst🐧🦀> so as I said before: I'm more open to require new mesa on the host
21:33 fdobridge: <g​fxstrand> We can read the BO metadata even if we can't create a tiled BO
21:33 fdobridge: <k​arolherbst🐧🦀> well..
21:33 fdobridge: <k​arolherbst🐧🦀> which just turned into new kernel
21:33 fdobridge: <g​fxstrand> I'm reasonably okay with saying if you update your kernel to the latest and have a new flatpack, you should update your Mesa too
21:34 fdobridge: <k​arolherbst🐧🦀> yeah...
21:34 fdobridge: <k​arolherbst🐧🦀> that's usually maintained distros, so they could update mesa
21:34 magic_rb: Sorry to interupt the discussion, but ive a quick question i couldnt find the answer to anywhere
21:34 magic_rb: hi, ive just switched to nouveau after waiting for zfs to catch up, im on kernel 6.7 with a rtx 3060 mobile. The proprietary driver has a feature where if the gpu is not used itll completely shut it off, is that a thing on nouveau? I tried looking into /sys/kernel/debug but the pstate pseudofiles dont work, they report "no such device or address", so im not sure how to validate the current powerstate, thanks for any help and thanks for...
21:34 magic_rb: ... the driver, saved me from nvidia induced segfaults today
21:34 magic_rb: (I tried to post this once, nickserv told me to try avain :) )
21:34 karolherbst: magic_rb: yes, nouveau will power down the GPU if not in use
21:35 karolherbst: check the `power/runtime_status` file in sysfs for the pci device
21:35 fdobridge: <k​arolherbst🐧🦀> but yeah... new GL in a flatpak would also not use VM_BIND because of the outdated kernel... I totally didn't think of that 🙂
21:36 magic_rb: karolherbst: ah thank you, ill check the file! I also assume that if on the proprietary driver the gpu would get limited to less than half its max performance without AC being plugged in, its about the same here, if i run into any bugs ill do my best to help you people, sadly i dont speak enough C or Rust to contribute much code
21:37 karolherbst: magic_rb: sooo with nouveau you'll need to use GSP to get proper power management on your GPU, and it's not enabled by default on the one you have (only for 40 series)
21:37 karolherbst: need to boot with "nouveau.config=NvGspRm=1"
21:37 karolherbst: and then it will adjust the power levels according
21:37 karolherbst: though
21:37 karolherbst: I have no idea if it's handling AC power as of today
21:38 karolherbst: airlied: any ideas?
21:38 karolherbst: on some laptops we got a GPIO set by the firmware if the AC gets removed which indicates the driver to throttle, but I have no idea if GSP handles this on its own
21:39 magic_rb: i have the GSP enabled already, arma jumped from 10 to 30 fps, otherwise runs great, the text looks weird in some situations but thats minor
21:39 karolherbst: okay
21:39 karolherbst: then I guess you could unplug the AC and see if the perf throttles a bit or a lot
21:40 magic_rb: ill try now, i was curious if you people did anything and if you did what
21:41 magic_rb: ill learn as much as possible by observing the discussions here, same as ive been doing with zfs for a year now
21:46 magic_rb: the GSP indeed handles that, unplugging AC halfs my fps
21:47 karolherbst: yeah.. that sounds like properly handling it
21:47 magic_rb: yep, the game did crash when unmapped and remapped (x11) but thats a minor detail
22:33 fdobridge: <g​fxstrand> Ugh...
22:34 fdobridge: <g​fxstrand> TILE_WIDTH_IN_GOBS seems to do nothgin
22:39 fdobridge: <g​fxstrand> There's a GOB3D bit but IDK what that does
22:53 fdobridge: <g​fxstrand> I wonder if I need to start poking reserved bits
22:58 fdobridge: <m​arysaka> how do you currently setup the header?
22:59 fdobridge: <m​arysaka> I don't think you need to set gob3d from the top of my memory :aki_thonk:
23:00 fdobridge: <g​fxstrand> nil_image_tic.c
23:07 fdobridge: <r​edsheep> I'm so puzzled by what I'm seeing with performance in the witness and Talos again. While Talos got very noticably faster in the last few days, or with the latest rc kernels, whatever is making it faster seems to make the witness slower.
23:08 fdobridge: <r​edsheep> That same trade-off I was seeing with the weird build/ situation where you either have fast Talos or fast witness has continued, and gotten even more exaggerated
23:10 fdobridge: <g​fxstrand> Okay, looks like `TILE_WIDTH_IN_GOBS` is what I want, I just don't fully know what it does yet
23:10 fdobridge: <m​arysaka> oh you were using the other one then
23:10 fdobridge: <m​arysaka> GOBS_PER_BLOCK_WIDTH?
23:10 fdobridge: <g​fxstrand> I was playing with both
23:11 fdobridge: <m​arysaka> GOBS_PER_BLOCK_WIDTH should always be 0 (aka 1 gob) if I remember correctly
23:11 fdobridge: <g​fxstrand> But `TILE_WIDTH_IN_GOBS` doesn't seem to behave quite like the `GOBS_PER_BLOCK_FOO` fields.
23:11 fdobridge: <g​fxstrand> Good thing I have a solid test to RE all this nonsense. 😅
23:18 fdobridge: <k​arolherbst🐧🦀> yeah.. that one just flips between the pre kepler format and the kepler+ one
23:18 fdobridge: <k​arolherbst🐧🦀> or well.. one of those do
23:18 fdobridge: <k​arolherbst🐧🦀> but the values are documented
23:19 fdobridge: <m​arysaka> right it's a bit different:
23:19 fdobridge: <m​arysaka> for height you would have `GOBS_PER_BLOCK_HEIGHT * BLOCK_HEIGHT`
23:19 fdobridge: <m​arysaka> but for width you have `(GOB_SIZE / bpp) * BLOCK_WIDTH` I think
23:19 fdobridge: <m​arysaka> with GOB_SIZE being 64
23:19 fdobridge: <k​arolherbst🐧🦀> `NV85B5_SET_DST_BLOCK_SIZE_GOB_HEIGHT_GOB_HEIGHT_FERMI_8`
23:19 fdobridge: <k​arolherbst🐧🦀> ohh wait
23:19 fdobridge: <k​arolherbst🐧🦀> it was tesla/fermi
23:19 fdobridge: <k​arolherbst🐧🦀> 😄
23:19 fdobridge: <g​fxstrand> Wait... width is affected by bpp?
23:19 fdobridge: <g​fxstrand> WTH?
23:19 fdobridge: <k​arolherbst🐧🦀> `NV85B5_SET_DST_BLOCK_SIZE_GOB_HEIGHT_GOB_HEIGHT_TESLA_4`
23:19 fdobridge: <k​arolherbst🐧🦀> is the other value
23:20 fdobridge: <m​arysaka> If my memory is correct yes 🙃
23:21 fdobridge: <g​fxstrand> *ugh*...
23:24 fdobridge: <g​fxstrand> Even when I set it to `THIRTYTWO_GOBS` it seems to do nothing in this test
23:24 fdobridge: <g​fxstrand> I know I saw it do *something* in a different test
23:24 fdobridge: <g​fxstrand> But maybe the hardware is clamping it? It likes to do that...
23:29 fdobridge: <g​fxstrand> Yeah, it's the HW clamping
23:29 fdobridge: <k​arolherbst🐧🦀> do we know the exact rules when it's clamping?
23:29 fdobridge: <g​fxstrand> I'm working on figuring that out
23:29 fdobridge: <k​arolherbst🐧🦀> ahh, cool
23:50 fdobridge: <g​fxstrand> I think I found the right rule
23:51 fdobridge: <g​fxstrand> Instead of clamping down to the next power of two at least as large as the LOD, the moment any dimension of the LOD is smaller than a level0 tile, width smashes to 0