00:01 gfxstrand[d]: Oh, and one other thing... (I'm gonna go comment this one on gitlab)
00:03 mhenning[d]: skeggsb9778[d]: Thanks, that helps
00:04 gfxstrand[d]: I'm about to sign off but I'll be around tomorrow morning (US time)
04:57 tiredchiku[d]: oh yeah I finished work on this last year :P
04:57 tiredchiku[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31518
06:43 tiredchiku[d]: :hmmmg:
06:43 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1344922853975261194/Ev6dwy8.png?ex=67c2ac83&is=67c15b03&hm=5c96e7dda7ab2bd0ba911a892ca27f163b5c3d7c1c9e17f1420aa9aca46870ce&
06:43 tiredchiku[d]: disco elysium too
06:43 tiredchiku[d]: wonder if it's still MSAA related
06:45 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1344923430138679327/EVKYWwl.png?ex=67c2ad0d&is=67c15b8d&hm=11bbf9aadc0186ce691f84c75306b072e8e11dfeab179fc3c2d2620305d97dfc&
06:45 tiredchiku[d]: not using gamescope makes it better here:
06:46 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1344923550582181969/S5Nl4YT.png?ex=67c2ad29&is=67c15ba9&hm=83547d51a55e1e9fedf05b8823c5cdd7cacfbe20e9c026e9950c598326080ea8&
06:46 tiredchiku[d]: and additionally turning AA off helps a lot more again
06:46 tiredchiku[d]: and more than doubles the framerate
06:47 redsheep[d]: I realized that hexcells not launching was me being silly and forgetting I had set it to launch with gamescope when I didn't mean to. It works fine without it. Still, gamescope should be working
06:48 tiredchiku[d]: tiredchiku[d]: maybe even more actually there appears to be some forced vsync going on
07:31 tiredchiku[d]: holy shit
07:32 tiredchiku[d]: turning AA from 8x to off in disco elysium takes it from 90 fps to 200
07:32 tiredchiku[d]: everything else maxed
07:36 redsheep[d]: MSAA is hard, and without zcull and color compression and tiled cache it's harder
07:36 tiredchiku[d]: I see
08:04 mohamexiety[d]: It’s more so compression because it shoots up bandwidth usage _a lot_ which is specifically what compression addresses
08:06 redsheep[d]: Doesn't msaa mean bigger depth buffer and therefore also zcull impact?
08:53 redsheep[d]: I have absolutely no clue why but moving my second monitor to another displayport eventually worked to make both operate on my wayland session. There's surely still a bug, but it's unclear where. Almost certainly not a bug with nvk or zink though, I would think. So, probably nothing to report there anymore
08:54 redsheep[d]: What's more bizarre is that now that both of my displays work discord flicker is like 99% gone, to the point I can actually type this here with it right now and I don't see it happening. Something is almost certainly still wrong but I can't begin to give good replication steps for this at this point, so I don't really know how I could file an issue that will do any good.
08:57 rinlovesyou[d]: i haven't been able to launch a kde wayland session with zink lately
08:57 rinlovesyou[d]: well, technically it launches
08:57 redsheep[d]: My issues basically fixing themselves one the one hand seems nice, but if it means I can't actually consistently get anything in a state that is having a reportable issue it kinda sucks
08:58 rinlovesyou[d]: rinlovesyou[d]: black screen only though the cursor works at least
08:59 redsheep[d]: rinlovesyou[d]: Per Sid, put this at the bottom of /etc/profile
08:59 redsheep[d]: ```if [ ! -e /dev/nvidiactl ]; then
08:59 redsheep[d]: export NOUVEAU_USE_ZINK=1
08:59 redsheep[d]: export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nouveau_icd.x86_64.json:/usr/share/vulkan/icd.d/nouveau_icd.i686.json
08:59 redsheep[d]: export KWIN_FORCE_SW_CURSOR=1
08:59 redsheep[d]: fi
08:59 rinlovesyou[d]: thank you will give that a go later!
09:00 redsheep[d]: There are bugs in qt and plasma that have to be worked around to get things going
09:00 redsheep[d]: Actually the broken hardware cursor might not be their fault, not clear on that one
09:01 tiredchiku[d]: you only need VK_ICD_FILENAMES and KWIN_FORCE_SW_CURSOR if you have nvidia installed alongside
09:02 rinlovesyou[d]: well i need `NOUVEA_USE_ZINK` as well since it's not the default
09:02 tiredchiku[d]: yes
09:02 rinlovesyou[d]: oh right, you meant that i need those two only if i have nvidia prop as well
09:02 tiredchiku[d]: correct
09:03 rinlovesyou[d]: i read that as "you *only* need those two"
09:03 tiredchiku[d]: ah, no 😅
09:03 rinlovesyou[d]: but yeah i do, more convenient to just blacklist the nvidia module with kernel params as a second boot option
09:04 redsheep[d]: tiredchiku[d]: That seems really strange, you're saying the hardware cursor works with nvk+zink+plasma wayland when you don't have nvidia installed???
09:04 redsheep[d]: :confused:
09:05 rinlovesyou[d]: i mean the cursor itself worked fine (it was about the only thing actually working)
09:05 rinlovesyou[d]: even shake to grow worked haha
09:05 tiredchiku[d]: redsheep[d]: yes
09:06 tiredchiku[d]: rinlovesyou[d]: yeah then you need to specify the vulkan ICD
09:06 redsheep[d]: Maybe I will try without the cursor workaround, maybe that got fixed
09:08 tiredchiku[d]: redsheep[d]: https://tenor.com/view/gif-gif-24919915
09:13 redsheep[d]: ??? I just locked up on a soft reboot after disabling cursor workaround and my mouse is fine, but now I'm back to only one working monitor, and it's the other one, the one that used to not work. Even stranger, massive discord flicker is back
09:14 redsheep[d]: I don't understand what's going on here at all. At the very least zink is causing us to tread over some gsp or kernel code that blows up my system way more often when modesetting, even if that probably isn't a zink bug
09:16 redsheep[d]: The discord issue seems entangled with the state where it's sort of trying to drive two displays but failing. I don't understand what's going on here at all.
09:25 redsheep[d]: Alright, I give up for the night. I don't feel like I understand this well enough to start opening issues with any confidence. If anyone else has two displays they can test nvk+zink plasma Wayland with it would help my sanity to know this isn't just me
09:29 redsheep[d]: For a minute there i had what seemed like a perfectly functional session, it's just a very fragile state.
09:46 rinlovesyou[d]: redsheep[d]: Yeah i got two displays and will report back
11:17 tiredchiku[d]: I believe `[gamescope] [Error] vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x3231564E (VkResult: 0)` is something for us to do on NVK?
11:18 tiredchiku[d]: format appears to be NV12
11:18 tiredchiku[d]: so it's.. uhh
11:18 tiredchiku[d]: YUV420
12:37 tiredchiku[d]: just had libgallium segfault out of nowhere
12:40 tiredchiku[d]: but I'm on GSP 570, would filing bugs be valid :doomthink:
12:42 tiredchiku[d]: oh, zink
12:51 asdqueerfromeu[d]: tiredchiku[d]: I don't think GSP affects CPU-side segfaults
14:40 gfxstrand[d]: redsheep[d]: Yeah, it's probably impacted by both. I'm not sure how MSAA and ZCULL interact, though.
14:43 gfxstrand[d]: tiredchiku[d]: Ugh... I wish those format numbers made some sort of sense.
14:43 tiredchiku[d]: I cross checked with drm_info
14:43 tiredchiku[d]: and it corresponds to NV12
14:44 gfxstrand[d]: Okay. We probably can report modifiers for some of those. I'll have to look into it.
14:45 gfxstrand[d]: Right now we just bail on anything YCbCr.
14:45 tiredchiku[d]: source: https://drmdb.emersion.fr/snapshots/0f4161ba12dc
14:45 gfxstrand[d]: But to we'll need to fix that for video use cases anyway.
14:45 tiredchiku[d]: did a ctrl+F for the format number 😅
14:47 gfxstrand[d]: I have no idea how good the modifiers+YCbCr testing situation is.
14:53 redsheep[d]: Seems like it could be hurting gamescope performance, I'd think? My gamescope issue turned out to be a years old bug, likely due to sddm using x and gamescope faceplanting on that same socket or whatever
14:54 redsheep[d]: So, not something to do with nvk or zink, so far as I can tell
14:56 tiredchiku[d]: yeah, that was goofy
14:56 tiredchiku[d]: https://github.com/ValveSoftware/gamescope/issues/431
14:56 tiredchiku[d]: G
14:59 redsheep[d]: https://tenor.com/view/goofys-trial-murder-ill-do-it-again-gif-15434208
14:59 karolherbst[d]: having a steam user session is a good idea actually
15:56 fooishbar[d]: gfxstrand[d]: ```python
15:56 fooishbar[d]: >>> [chr(x) for x in int(0x3231564E).to_bytes(4, byteorder='little')]
15:56 fooishbar[d]: ['N', 'V', '1', '2']
15:59 mohamexiety[d]: I would never have guessed 😮
16:00 gfxstrand[d]: Heh
16:01 gfxstrand[d]: I figured it was something like that but I couldn't purse the hex in my head
16:06 gfxstrand[d]: But yeah, we can do modifiers for YCbCr. We just need to follow the video rules and use the same modifier for all the planes.
16:06 gfxstrand[d]: I think
16:07 gfxstrand[d]: That modifier choice will end up depending on size and I'm not sure how that'll work.
16:07 gfxstrand[d]: Actually, ugh... I'm not sure if that's allowed.
16:14 gfxstrand[d]: It's fine for YUYV. And I think it's fine for any 2-plane format where uv is 2x1 subsampled.
16:15 gfxstrand[d]: But NV12 is 2x2 subsampled so we might be sunk unless we go for the minimum tile size. 😭
16:19 fooishbar[d]: it's not just the video rules - you only ever get one modifier per image, you don't get to differ per-plane
16:20 fooishbar[d]: if you have disjoint planes you want to tile differently, you'd have to define a modifier which could express that
17:26 gfxstrand[d]: fooishbar[d]: Oh, that's fine. That's literally "the video rules" for Nvidia. The video hardware has a single tiling specifier for both planes.
17:28 gfxstrand[d]: The big problem is that the hardware auto-adjusts tiling of the LOD is too small. This means that if we use too big a tiling in our modifier, it might end up funky.
17:29 gfxstrand[d]: But maybe we can get away with it for 2D images? I've got to give it a think and maybe play with video first before I'll know for sure.
17:29 gfxstrand[d]: gfxstrand[d]: This normally isn't a problem. The hardware is programmed consistently in all drivers. The big problem is if that hardware adjustment happens differently per-plane.
18:22 tiredchiku[d]: day #1 of maining NVK: finished Alan Wake 1's both DLCs with no issues, also started Alan Wake's American Nightmare
18:22 tiredchiku[d]: one random librewolf crash, one random sigsegv in zink that took the whole desktop down
18:24 bigsmarty[d]: How is performance? Havent Seen any new Benchmarks lately and didnt get around to setting it up myself yet
18:28 tiredchiku[d]: _really_ depends
18:29 tiredchiku[d]: tho I like to play most my games capped to 60fps and crank settings up high
18:29 tiredchiku[d]: but depending on the game/scene you can expect anywhere between a 30%-99% performance difference w/ nvidia prop
18:31 bigsmarty[d]: tiredchiku[d]: Yeah uh my old laptop has a mobile GTX 1650 im happy if i get 60 on 720p in YouTube 😂😂
18:31 tiredchiku[d]: you'll get that pretty easily
18:31 tiredchiku[d]: software decode though
18:31 tiredchiku[d]: :3
18:32 mhenning[d]: tiredchiku[d]: what card do you have, out of curiosity?
18:32 tiredchiku[d]: 3070
18:32 tiredchiku[d]: 1440p display
18:33 tiredchiku[d]: supposed to be 180hz but nouveau doesn't detect that mode and drops me down to 165
18:44 redsheep[d]: tiredchiku[d]: And then you have to drop to 120 when you play audio cuz wiggles
18:45 tiredchiku[d]: nope, I just use front panel 3.5mm jack instead of the one on the monitor
18:57 rinlovesyou[d]: redsheep[d]: this certainly did get plasma running under zink
18:57 rinlovesyou[d]: but now steam isn't loving it: `MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
18:57 rinlovesyou[d]: `
18:59 rinlovesyou[d]: glxgears works fine and i don't see any issues with the plasma session either so this is very weird
19:00 tiredchiku[d]: check for rogue configs, maybe passed to steam, that set a conflicting VK_ICD_FILENAME
19:01 tiredchiku[d]: `VK_ERROR_INCOMPATIBLE_DRIVER` means zink is trying to invoke a driver not meant for the nouveau kernel module
19:01 rinlovesyou[d]: weirdd idek where to look
19:01 tiredchiku[d]: I'd start with the .desktop file
19:02 tiredchiku[d]: kickoff > right click steam > edit application
19:02 rinlovesyou[d]: yeah i did check that but i don't see anything interesting there
19:02 rinlovesyou[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1345108918988443708/image.png?ex=67c359cd&is=67c2084d&hm=57495af5f0ec387b6d37016bd3bacef8638f79d241f5d3be95665161ea64370d&
19:02 rinlovesyou[d]: looks normal enough
19:04 tiredchiku[d]: well, check if official steam client launches
19:04 tiredchiku[d]: steam native runtime is unofficial, so
19:05 rinlovesyou[d]: no sam result with just steam
19:11 tiredchiku[d]: check .profile/.bash_profile/whatever shell's profile?
19:11 tiredchiku[d]: since those are applied at runtime
19:12 tiredchiku[d]: er, at login
19:13 rinlovesyou[d]: but why would that influence only steam
19:14 tiredchiku[d]: because steam's one of the few apps that directly queries vulkan devices on launch
19:14 tiredchiku[d]: the rest are all EGL/GLX
19:14 tiredchiku[d]: so if you have an env var somewhere that changes the vk icd post login..
19:15 tiredchiku[d]: check vkcube/vulkaninfo while you're at it c:
19:15 tiredchiku[d]: or just run `env` to get a list of all env vars
19:15 tiredchiku[d]: and grep through your system to find where you've set it
19:15 tiredchiku[d]: many ways to skin a cat or something
19:18 rinlovesyou[d]: the only place i can see nvidia even mentioned is `LIBVA_DRIVER_NAME`
19:18 rinlovesyou[d]: nouveau is still properly set in `VK_ICD_FILENAMES`
19:18 rinlovesyou[d]: vkcube runs fine using nvk as well
19:20 tiredchiku[d]: :doomthink:
19:20 tiredchiku[d]: try unsetting LIBVA_DRIVER_NAME I suppose
19:20 tiredchiku[d]: I can't think of any other reason steam would fail to launch
19:20 tiredchiku[d]: just `unset LIBVA_DRIVER_NAME`
19:20 tiredchiku[d]: and run steam in the same terminal
19:21 rinlovesyou[d]: yeah that doesn't have an impact as i thought
19:24 tiredchiku[d]: weird
19:24 tiredchiku[d]: iirc you've got a 3070 too, right?
19:24 rinlovesyou[d]: 2070 super
19:26 tiredchiku[d]: shouldn't be an issue then
20:04 redsheep[d]: rinlovesyou[d]: I know you'd probably rather keep it long term but if you uninstall the nvidia driver does that fix the error?
20:16 airlied[d]: gfxstrand[d]: It's literally 21VN 🙂
20:17 airlied[d]: Oh Daniels already pointed that out 🙂
20:38 rinlovesyou[d]: right so
20:39 rinlovesyou[d]: i was missing `/usr/share/vulkan/icd.d/nouveau_icd.i686.json`
20:39 rinlovesyou[d]: i only locally build x86_64
20:39 tiredchiku[d]: mfw no multilib driver for multilib app
20:40 tiredchiku[d]: glad you got it sorted tho
20:40 rinlovesyou[d]: yeah the band-aid was just installing the nouveau vulkan packages but ig i'll have to build both locally in the future
21:39 rinlovesyou[d]: by the by you wouldn't happen to have a pkgbuild for 570 gps? 👉👈 meant to test some things with that
22:56 gfxstrand[d]: Why is bindgen generating a binding for `u_printf_info`?!?
22:56 gfxstrand[d]: Oh, maybe NIR pulls it in
23:33 redsheep[d]: I still don't know what is messing up my wayland session, but I will say a few hours into using the x11 session on zink, it seems like it pretty much just works, actually. Even the doom 2016 gl renderer is working pretty well now
23:35 redsheep[d]: I wonder if it is worth making a project of doing a massive update to the game tracker, given most of the results are nearing a year old. Maybe though things are actually at the point where the tracker isn't really relevant?
23:38 gfxstrand[d]: I'd say do a quick spot-check and if you find a bunch of stuff that was broken and now works, it's probably worth revisiting some things.
23:38 gfxstrand[d]: If things seem about the same, don't bother.
23:39 gfxstrand[d]: I think stuff has probably been fixed but without testing, we don't know.
23:40 redsheep[d]: I can update my entries, but those only make up maybe 10%
23:40 gfxstrand[d]: That's okay
23:40 mhenning[d]: Also worth noting anything that's worse than before
23:40 gfxstrand[d]: Yeah, if anything broke, please file a bug.
23:44 redsheep[d]: So regressions are for sure issue worthy, but old problems maybe not. Makes sense
23:44 mhenning[d]: The tracker was pretty useful when I was fixing a rendering issue in BG3 - I could see that the tracker said it had previously worked correctly, and I was able to bisect pretty quickly thanks to that
23:45 redsheep[d]: Oh that's cool. I'm glad to hear it's made some difference
23:49 gfxstrand[d]: Yeah, any time we can bisect, it's way easier than if we're fixing a bug blind.
23:50 gfxstrand[d]: `git bisect` is one of the most powerful dev tools ever
23:50 redsheep[d]: In that case it sounds like keeping all of the previous entries for the same game on the same api is probably good? Just add new ones?
23:51 redsheep[d]: Hurts readability a bit but if it helps bisect that's worth it
23:55 gfxstrand[d]: <a:shrug_anim:1096500513106841673>
23:55 gfxstrand[d]: If it's a regression, it's good to be able to bisect it. If it's fixed, IDK how much I care what fixed it.
23:55 gfxstrand[d]: But it would be good to add a git SHA of what mesa version was used.
23:55 redsheep[d]: Always
23:59 redsheep[d]: Hmm. I wish I had better tools to diagnose display server stuff not working. I am pretty sure my games are only actually displaying 60 fps, even though my main monitor is running at 120. In fact, the only time I see the cursor move like it's 120 is when there's nothing else on the screen. As soon as I pull something up it looks a lot like it is displaying 60, but the pattern isn't every other
23:59 redsheep[d]: frame, it's two consecutive frames, then skip two, then repeat