00:03 fdobridge: <g​fxstrand> @zmike. It's a zink bug. I'm fairly sure `lower_sparse` is just bogus
00:04 fdobridge: <z​mike.> 🤔
00:04 fdobridge: <g​fxstrand> Why does it only show up for TG4? 🤷🏻‍♀️
00:05 fdobridge: <g​fxstrand> In the SPIR-V, I'm getting `OpImageSparseGather` but nothing is using the texel residency code
00:05 fdobridge: <g​fxstrand> It's definitely not dead in the GLSL
00:05 fdobridge: <g​fxstrand> But it's dead in the SPIR-V that gets handed to NVK
00:08 fdobridge: <z​mike.> what's an example nir shader?
00:08 fdobridge: <z​mike.> ZINK_DEBUG=nir
00:09 fdobridge: <z​mike.> ^
00:10 fdobridge: <z​mike.> well, I guess I'll untangle it tomorrow
00:10 fdobridge: <z​mike.> thanks for digging in
00:11 fdobridge: <g​fxstrand> Actually, I think it's lower_sparse_and that's busted
00:13 fdobridge: <g​fxstrand> Yeah, it's `lower_sparse_and`
00:14 fdobridge: <g​fxstrand> The whole sparse residency code thing is such a massive hack in GLSL
00:20 fdobridge: <a​irlied> btw blue heaven seems MSAA related
00:21 fdobridge: <a​irlied> looks fine on ultra/extreme with no-msaa, any msaa brings the blue flickers
00:33 fdobridge: <g​fxstrand> @zmike. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28123
00:33 fdobridge: <g​fxstrand> It probably needs more testing and I need supper but I think that's the right idea.
00:34 fdobridge: <g​fxstrand> @airlied Just survived a 36-thread run with no ReBar and user BAR mappings re-enabled. There's a few tests that failed which I'll look into tomorrow and then I think we can turn on user BAR mappings always.
00:35 fdobridge: <a​irlied> @gfxstrand btw since you are back on 36-threads keep an eye out for https://gitlab.freedesktop.org/drm/nouveau/-/issues/274
00:35 fdobridge: <a​irlied> let me know if you see it again
00:43 fdobridge: <z​mike.> Happily, there are zero other users of sparse_and that I'm aware of outside CTS, and there are zero other vk drivers which can run the CTS tests besides NV
00:43 fdobridge: <z​mike.> So if this works and you're happy with it, that's the only testing that matters
01:28 fdobridge: <g​fxstrand> Lmao
01:28 fdobridge: <g​fxstrand> If it doesn't regress anything then I'm happy with it, yeah.
01:29 fdobridge: <g​fxstrand> I can kick off a run with just one GPU. The runs today were sharded across two identical 3060s
01:32 fdobridge: <g​fxstrand> So a good multi threaded hammer but not banging on contended resources as badly as you might think.
01:33 fdobridge: <g​fxstrand> I guess that means I should run CI on it... I'll kick that off when I get home.
02:14 fdobridge: <z​mike.> radv and anv both support sparse, but I don't think either of them can run these tests
02:14 fdobridge: <z​mike.> base sparse texture doesn't exercise these features
03:16 fdobridge: <g​fxstrand> I tried to put a pile of MRs together but I'm hitting MSAA all over
08:37 fdobridge: <r​edsheep> I have discovered that all the games that recently became unplayable for me are games where I need to explicitly turn off dxvk nvapi. Seems proton 9 enabled it by default. Since nobody on protondb is complaining about these games I have to assume it's related to running on nvk.
08:42 HdkR: Maybe that is also what I recently saw about NVAPI being used with NVK
08:50 fdobridge: <t​om3026> that might be hitting some corner cases with nvida reflex, dlss or physx. oh nvidia gpu. and hitting not implented things heh
08:52 fdobridge: <r​edsheep> Well one of them, deep rock galactic, does implement reflex I believe. I have no idea what tower unite could be using nvapi for. Does UE4 use physx? I dunno.
08:54 fdobridge: <r​edsheep> DRG also has dlss come to think of it. Anyway, disabling it works. Maybe this is something already solved in dxvk now? https://github.com/doitsujin/dxvk/commit/0414bbe2d5d5ee0df027731a91f251312ca84cf4
08:54 fdobridge: <S​id> only kinda
08:55 fdobridge: <S​id> dxvk only provides config option and applies to some games
08:55 fdobridge: <S​id> still have to manually disable for the others
08:56 fdobridge: <r​edsheep> Hmm. So it sounds like I need to report these games so dxvk knows to have overrides?
08:56 fdobridge: <S​id> tbh, not worth it yet
08:57 fdobridge: <S​id> since we might implement some nvapi things
08:58 fdobridge: <r​edsheep> Well... yeah but probably not be the time 24.1 is tagged and a whole load of people start having nvk who didn't have it before
08:58 fdobridge: <r​inlovesyou> In the first place, can't you just disable nvapi for the time being if it's on by default?
08:59 fdobridge: <r​inlovesyou> There should be an env var you can just set to 0
08:59 fdobridge: <r​edsheep> Yes I am setting PROTON_DISABLE_NVAPI=1
08:59 fdobridge: <S​id> I'm just saying it'd be better for early adopters to use workarounds instead of increasing noise on dxvk, but that's just me
09:00 fdobridge: <r​inlovesyou> Mhm
09:00 fdobridge: <!​DodoNVK (she) 🇱🇹> This isn't the first NVK-specific change in DXVK
09:02 fdobridge: <r​edsheep> The environment variable works but if I have to have a workaround that means broken games for new nvk users. If we don't want to make a bunch of noise for dxvk and cause stuff to get disabled that we might implement later maybe an issue on the mesa tracker where we list known workarounds for games would be nice? We're getting to the point where basically anything dxvk works
09:02 fdobridge: <S​id> well
09:02 fdobridge: <r​edsheep> Games with workarounds might be nice to keep tabs on
09:03 fdobridge: <S​id> ideally right now nvapi should do for nvk what it does for radv
09:03 fdobridge: <S​id> by default
09:03 fdobridge: <S​id> which is pretend to be pascal
09:04 fdobridge: <S​id> but I think Philip and the other dxvk/nvapi guys believe differently and wanna already start adding game specific options
09:06 fdobridge: <r​inlovesyou> Nice intentions but certainly premature
09:06 fdobridge: <S​id> wait I have it wrong
09:06 fdobridge: <S​id> Philip is of the same mindset
09:06 fdobridge: <S​id> it's proton that's force enabling it
09:07 fdobridge: <S​id> so things have to change in proton
09:07 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1217036253904769144/Screenshot_20240312-143600.png?ex=66029056&is=65f01b56&hm=c3090b2fd6c92be741d27404d3d2f6cf40003a80c24fcfd3da99d5c80a9a3a15&
09:08 fdobridge: <S​id> japanese nick is Philip, dxvk dev
09:08 fdobridge: <p​ac85> Is Philip doit's name?
09:09 fdobridge: <!​DodoNVK (she) 🇱🇹> It's actually German
09:10 fdobridge: <r​inlovesyou> German written in katakana?
09:10 fdobridge: <S​id> dxvk is already disabling by default for nvk
09:10 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1217037095026036827/Screenshot_20240312-144047.png?ex=6602911e&is=65f01c1e&hm=ec6b4123c33c7edba96d0ea5f5b3ed6dab61c8eb1f9a9c3b20cca43751cc012e&
09:10 fdobridge: <!​DodoNVK (she) 🇱🇹> I guess
09:11 fdobridge: <s​aancreed> There is also the idea of allowing dxvk-nvapi to initialize with NVK but that would require some QA in that area and I'm not really in place to ensure nothing explodes when we do that… at least not yet.
09:12 fdobridge: <S​id> yes
09:12 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1217037375763382362/Screenshot_20240312-144118.png?ex=66029161&is=65f01c61&hm=8d4e132004462b93871fd8140673f8fec0694db43abcc59f0888faa3d60b43ea&
09:12 fdobridge: <r​inlovesyou> let me get the katakana sheet then.. sec
09:12 fdobridge: <S​id> tbh I also think we should hold off on that until nvk is less... volatile, for the lack of a better word
09:13 fdobridge: <S​id> doing stuff for such a nascent driver doesn't make sense to me personally
09:13 fdobridge: <S​id> though
09:13 fdobridge: <S​id> I'm always up for QA :>
09:14 fdobridge: <s​aancreed> Yeah, it's just that until then, we are stuck with yet another flavor of nvapi hack 😦
09:14 fdobridge: <S​id> sadly
09:15 fdobridge: <S​id> but yes, proton needs to change
09:15 fdobridge: <S​id> and not force nvapi on nvk
09:15 fdobridge: <t​om3026> does nvk have a logo? btw
09:15 fdobridge: <S​id> dxvk is already doing it
09:17 fdobridge: <r​inlovesyou> it says "german person"
09:18 fdobridge: <r​inlovesyou> "do i tsu" -> "Deutsch" -> "German" and the last is the kanji for "person" apparently
09:18 fdobridge: <t​om3026> the logo doesnt come in a .png or similiar format somewhere? 😛
09:20 fdobridge: <r​edsheep> I mean experimental has been dropped. It's not really a nascent driver anymore, it's going to start actually shipping soon. In the next few months unwitting users will start installing linux and won't have a broken system on nvidia, and so they might never know to or bother to install the nvidia drivers.
09:20 fdobridge: <r​inlovesyou> :triangle_nvk:
09:21 fdobridge: <r​inlovesyou> https://cdn.discordapp.com/emojis/1033490011179454494.webp
09:21 fdobridge: <S​id> I have it hang on
09:21 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1217039684048257094/NVK-Logo_onBlack_RGB.png?ex=66029388&is=65f01e88&hm=75c26ef45f28911d5b3f495378f6c59ac48e4b36d3aefb3d42544491ea3c7d5e&
09:21 fdobridge: <S​id> yes but re: nvapi we're still unstable
09:21 fdobridge: <S​id> not experimental, but unstable
09:22 fdobridge: <S​id> and again, I agree with you, things should Just Work
09:22 fdobridge: <S​id> but this is a problem proton is causing
09:22 fdobridge: <t​om3026> thanks 🙂
09:23 fdobridge: <S​id> proton is forcing nvapi, not dxvk
09:24 fdobridge: <S​id> if anything, dxvk is already disabling by default, but proton overrides that
09:27 fdobridge: <r​edsheep> Yeah. Either the proton people need to be made aware not to force it on nvk, or fixing basic nvapi to match radv needs to happen before 24.1
09:28 fdobridge: <S​id> the former is easier to achieve
09:28 fdobridge: <S​id> I'll go bother remi
09:28 fdobridge: <S​id> or gofman
09:28 fdobridge: <S​id> idk
09:29 fdobridge: <S​id> or maybe make a PR for it myself
09:34 fdobridge: <S​id> proton's just a python script anyway
09:48 fdobridge: <S​id> are you on proton 9 beta, or on proton experimental
09:51 fdobridge: <r​edsheep> I always run proton experimental
09:51 fdobridge: <S​id> because:
09:51 fdobridge: <S​id> - proton does not force it, it only enables it by default
09:51 fdobridge: <S​id> - dxvk already reports nvk to be an amd gpu to the game
09:51 fdobridge: <S​id> which should be enough for it to not be enabled
09:52 fdobridge: <S​id> could you switch to the bleeding-edge branch and verify please and thank you
09:52 fdobridge: <S​id> proton experimental is also always a bit behind git/master
09:52 fdobridge: <r​edsheep> I did try bleeding edge too
09:52 fdobridge: <S​id> interesting
09:53 fdobridge: <S​id> when, and what game, if I may ask
09:53 fdobridge: <S​id> bleeding edge, that is
09:53 fdobridge: <r​edsheep> Tower unite and deep rock galactic dx11 mode
09:53 fdobridge: <r​edsheep> Tower unite crashes after loading the world, deep rock during load
09:53 fdobridge: <S​id> when though
09:53 fdobridge: <S​id> as in, when did you try bleeding edge
09:54 fdobridge: <r​edsheep> An hour ago?
09:54 fdobridge: <S​id> extra interesting
09:55 fdobridge: <r​edsheep> I will try again to be certain. I can also get you proton logs if you like to prove it's the cause.
09:55 fdobridge: <r​edsheep> It spams about nvapi for tens of thousands of lines and then dies
09:55 fdobridge: <S​id> > Tldr is that dxvk currently shows nvk as a AMD GPU so unless a game wants to mess with nvapi anyway it shouldn't hurt.
09:55 fdobridge: <S​id> > Unless it sees a Nvidia GPU through wine and not dxgi ofc and decides to so stuff based on that 🐸
09:56 fdobridge: <r​edsheep> Dunno if either of these games have debug to tell where it's getting it
09:57 fdobridge: <S​id> yeah, that's okay
09:57 fdobridge: <S​id> just passing info along
09:57 fdobridge: <S​id> did ask if we could set WINE_HIDE_NVIDIA_GPU by default for nvk, let's see how that goes
09:58 fdobridge: <r​edsheep> Is that an environment variable? I can try it
09:58 fdobridge: <r​edsheep> Just confirmed, set my proton experimental to bleeding edge and I got the crash
09:59 fdobridge: <S​id> PROTON_HIDE_NVIDIA_GPU=1
10:01 fdobridge: <r​edsheep> That is also effective at preventing the crash
10:01 fdobridge: <r​edsheep> I can load with only that variable set
10:01 fdobridge: <S​id> so the games are detecting nvidia gpu via wine
10:01 fdobridge: <S​id> and trying to load nvapi that way
10:01 fdobridge: <r​edsheep> Seems so, yeah.
10:02 fdobridge: <S​id> thanks for testing, I'll bother ivyl to work on this <3
10:06 fdobridge: <r​edsheep> Just confirmed in DRG as well, yeah hiding the nvidia gpu does the trick
10:06 fdobridge: <S​id> games being naughty and detecting nvidia via wine then
10:10 fdobridge: <r​edsheep> I wonder if this was caused by the recently improved device names in nvk. Games aren't likely to understand AD102, but they'll know what a NVIDIA GeForce RTX 4090 is.
10:10 fdobridge: <r​edsheep>
10:10 fdobridge: <r​edsheep> If they're using that and NVK has started showing the same names as nvidia that's probably going to cause confusion.
10:11 fdobridge: <r​edsheep> Not that we should have bad names by default lol... Just means games need workarounds not to know if they're likely to be dumb about it.
10:11 fdobridge: <S​id> I imagine they detect vendor ids
10:11 fdobridge: <S​id> I imagine both paths detect vendor ids
10:11 fdobridge: <S​id> dxgi and wine
10:14 magic_rb: Joining this room has been the best decision ive made in weeks, im learning so much from you people, thanks!
10:15 fdobridge: <S​id> heh, glad our ramblings are of help :)
10:15 fdobridge: <S​id> you're always free to ask any questions you have
10:16 magic_rb: Once i feel like im able to formulate a meaningful question, i will :)
10:16 magic_rb: Last time i realized the answer while typing the question
10:16 fdobridge: <r​edsheep> magic_rb: You were going to join the discord, right?
10:16 fdobridge: <S​id> no such thing as a dumb question
10:17 magic_rb: redsheep: yeah, i fell asleep yesterday before i managed to do so
10:17 fdobridge: <S​id> https://discord.gg/vXqMgfUpGe
10:17 magic_rb: Sid: I wanted to ask about how nvapi gets called, but i guess its just a library the same way mesa gets packaged up into a shared lib, libgl for opengl
10:17 magic_rb: Sid: got it already yesterday but thanks again
10:18 fdobridge: <S​id> nvapi is a dll, it's loaded via wine
10:18 fdobridge: <S​id> I'm not aware of any native nvapi.so
10:18 fdobridge: <S​id> it may or may not exist, but afaik, it's a .dll that's loaded via wine
10:19 fdobridge: <S​id> and even then, proton/linux-gaming does not use the official dll
10:19 fdobridge: <r​edsheep> I don't think there is one, all the nvapi games I have played with use proton
10:19 fdobridge: <S​id> we use a re-implementation of nvapi based on dxvk: https://github.com/jp7677/dxvk-nvapi
10:20 magic_rb: Yeah so its a dll, as i expected, how does physx tie into it, how low level is nvapi?
10:20 fdobridge: <S​id> it is fairly low level, I'd say, since it works on the same level dxvk does
10:21 magic_rb: So physx is implemented inside the game (its own dll)
10:22 fdobridge: <S​id> physx is implemented in the game engine
10:22 fdobridge: <S​id> the game then queries the gpu for physx capabilities
10:23 fdobridge: <S​id> dxvk-nvapi just provides the required entrypoints to supply gpu information by querying from vulkan
10:24 fdobridge: <S​id> or at least that's how I understand it, I could be wrong
10:24 fdobridge: <S​id> take everything I say with a grain of salt I'm just a silly physics major who likes testing things
10:25 fdobridge: <r​edsheep> "just a silly physics major" is a funny phrase but ok
10:25 fdobridge: <S​id> well, I am very much out of my domain when it comes to driver/API/libraries
10:26 fdobridge: <S​id> though it's funny how I understand things better than my CS peers do e-e
10:26 fdobridge: <S​id> magic_rb: from the dxvk-nvapi readme: Note that DXVK-NVAPI does not implement DLSS, Reflex or PhysX. It mostly forwards the relevant calls.
10:41 fdobridge: <S​id> @redsheep could you test the crash with PROTON_FORCE_NVAPI=1
10:42 fdobridge: <r​edsheep> Isn't that certain to crash? I'll try
10:42 fdobridge: <S​id> it is not
10:42 fdobridge: <S​id> it is certain to work, in fact
10:42 fdobridge: <S​id> will explain why later
10:44 fdobridge: <r​edsheep> That does not crash... How???
10:46 fdobridge: <S​id> pretends to be Pascal
10:46 fdobridge: <S​id> with driver version 999.99
10:46 fdobridge: <r​edsheep> That works in DRG too
10:46 fdobridge: <S​id> which is also what amd gpus use to load nvapi
10:47 fdobridge: <S​id> pascal allows loading nvapi for physx
10:47 fdobridge: <S​id> but doesn't support dlss and all that fluff
10:47 fdobridge: <S​id> meaning games can happily load it without using the fluffy paths
10:47 fdobridge: <S​id> and hence, not crash
10:47 fdobridge: <r​edsheep> So it's not that dxvk nvapi doesn't work, it's that these games were finding out that the card is newer than pascal and doing illegal things?
10:48 fdobridge: <S​id> yes
10:49 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1217061796230201354/image.png?ex=6602a820&is=65f03320&hm=53b3f78c256206ccb538c4109818c9d7472316c6fca62ed79a7f4ee1e245c36a&
10:49 fdobridge: <S​id> not illegal things, just currently unsupported things
10:49 fdobridge: <S​id> but yes, proton might soon disable nvapi/hide nvidia gpu by default on nvk
10:49 fdobridge: <S​id> and give us a toggle to enable it for dev/testing purposes
10:50 fdobridge: <S​id> dxvk's already doing it, wine side is left, which ivyl is trying to do now
10:50 fdobridge: <S​id> :>
10:51 fdobridge: <r​edsheep> Well, good to know, and sounds like the people who need to patch that up are aware then
10:51 fdobridge: <S​id> yes ivyl is one of the proton maintainers
10:52 fdobridge: <t​om3026> im soon gonna ask for food recipies then 😄
10:52 magic_rb: Sid: thanks for the explanation, i disappeared cause i was running late to a meeting :)
10:53 fdobridge: <S​id> no worries, and you're always welcome
10:53 fdobridge: <S​id> sure, as long as you don't ask for butter chicken I'm tired of sharing that one
10:55 fdobridge: <t​om3026> the nvk food group :>
10:56 Sid127:peeks
11:00 fdobridge: <r​edsheep> Here at the buffer buffet we have multiple samples available, and if you're on a diet we have recently added sparse options to the menu. Stack your plate high, just be sure not to overflow it.
11:01 fdobridge: <t​om3026> @redsheep dont worry we have disabled overflow exceptions
11:03 fdobridge: <r​edsheep> The list of available crossover between food and graphics driver puns is pretty short, I take what I can get.
11:04 fdobridge: <t​om3026> just gotta convine mike to rename zink to tomato, kopper to garlic and soon we can make pizza toppings puns
11:05 fdobridge: <t​om3026> just gotta impress him with the memes and it might happen! 😄
11:07 fdobridge: <r​edsheep> Anyway, once proton is patched to also prevent games seeing nvidia when they shouldn't we're really looking good in terms of dxvk game compatibility. I've really struggled to find any left that are outright broken.
11:08 fdobridge: <S​id> sea of thieves
11:08 fdobridge: <S​id> runs into an mmu fault (dmesg)
11:09 fdobridge: <r​edsheep> I don't have that one, also I don't see an open issue. Have you tried that on the latest kernel with Dave's new patch?
11:09 fdobridge: <r​edsheep> I've yet to see dmesg output from any games at all on 6.8 stable with the patch on top
11:10 fdobridge: <S​id> nope
11:10 fdobridge: <S​id> I borked my drives e-e
11:10 fdobridge: <S​id> and in the process exposed a severe bcachefs bug that kent is now working on
11:10 fdobridge: <S​id> which is why I can't do much for a while
11:11 fdobridge: <S​id> waiting for that to be sorted before I go back to usual shenanigans
11:11 fdobridge: <r​edsheep> There's a reason I went back to ext4. BTRFS ate some of my data and I am not likely to try novel filesystems again for a few more years.
11:11 fdobridge: <S​id> though, you mean dave's patch that solved issues for faith?
11:11 fdobridge: <r​edsheep> Yeah
11:11 fdobridge: <S​id> tried it with sea of thieves, yes
11:12 fdobridge: <S​id> mmu fault still
11:12 fdobridge: <S​id> but ext4 won't let me pool my storage or have transparent compression 🙃
11:12 fdobridge: <r​edsheep> I mean there have been a ton of patches that fit that description
11:12 fdobridge: <S​id> and, well, this bug was purely my own fault
11:13 fdobridge: <S​id> well, last time I tried was somewhere around this
11:14 fdobridge: <S​id> but yes I'll try this one once I have my drives back
11:14 fdobridge: <S​id> ideally within the next 24h
11:17 fdobridge: <r​edsheep> Yeah https://lore.kernel.org/dri-devel/20240311072037.287905-1-airlied@gmail.com/T/#u
11:17 fdobridge: <r​edsheep>
11:17 fdobridge: <r​edsheep> He said elsewhere that patch and 6.8 tag is the place to be. Seems really solid.
11:30 Sid127: neato
11:52 fdobridge: <t​om3026> btrfs or bcachefs? now you made me scared :p
12:01 magic_rb: im running zfs which is also why i cant really test new kernels :( i am testing mesa git, so if that can help somehow, hit me up
12:02 magic_rb: *running mesa-git
12:06 fdobridge: <S​id> bcachefs
12:06 fdobridge: <S​id> because I accidentally formatted a pool member before evacuating and removing it first
12:07 fdobridge: <t​om3026> okay good, im on btrfs heh
12:09 fdobridge: <S​id> like I said
12:09 fdobridge: <S​id> 100% user error
12:21 fdobridge: <t​om3026> and yeah compression is ❤️ im so far ~700gb used of 2tb and 120gb is saved by compressing
12:23 fdobridge: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1217085662600106094/Screenshot_20240312-175311.png?ex=6602be5a&is=65f0495a&hm=0672bdd803a6a6d0ed7e35afd994404d2765d0a0d559be2433f209aa2fc6f91e&
12:24 fdobridge: <s​aancreed> To be precise, this was less about the game seeing an architecture that should support NVNGX stuff and more about dxvk-nvapi by default refusing to load altogether when there are no Vulkan physical devices driven by NV proprietary driver.
12:24 fdobridge: <S​id> that makes more sense
12:24 fdobridge: <S​id> thanks saancreed <3
12:24 fdobridge: <s​aancreed> Wine and DXVK were telling them that yes, this is and Nvidia GPU, while NVAPI was saying "can't initialize, there are no Nvidia GPUs on this system".
12:25 fdobridge: <s​aancreed> 🐸❤️
12:25 fdobridge: <s​aancreed> Wine and DXVK were telling them that yes, this is an Nvidia GPU, while NVAPI was saying "can't initialize, there are no Nvidia GPUs on this system". (edited)
12:26 fdobridge: <!​DodoNVK (she) 🇱🇹> Or Dziękuję 🇵🇱
12:26 fdobridge: <S​id> can someone remind me to DM liz about prog rock after this class kthx
12:26 fdobridge: <S​id> 1h
12:29 fdobridge: <s​aancreed> Seems like there is not a single server I share with you where I won't be stigmatized based on my nationality 😩
12:29 fdobridge: <S​id> https://tenor.com/view/bonz-eyes-gif-21697009
12:30 fdobridge: <!​DodoNVK (she) 🇱🇹> I actually visited both Latvia and Poland
12:32 fdobridge: <t​om3026> 🇸🇪
12:32 fdobridge: <s​aancreed> I mean, cool, but can we stick to English please? Switching languages does not bring relevant value, just makes the discussion harder to understand for outsiders.
12:33 fdobridge: <!​DodoNVK (she) 🇱🇹> My dad goes to it for work 👷
12:33 fdobridge: <t​om3026> wait how do you get the flack in the name?
12:33 fdobridge: <t​om3026> eh flag
12:33 fdobridge: <!​DodoNVK (she) 🇱🇹> It's just emoji
12:33 fdobridge: <S​id> paste emoji unicode
12:34 fdobridge: <t​om3026> oh i see :>
12:39 fdobridge: <S​id> @redsheep are you up for some more testing
12:40 fdobridge: <r​edsheep> Always
12:40 fdobridge: <S​id> http://ivyl.gg/hide-nvk.tar.zst
12:40 fdobridge: <S​id> > @./Sid.she http://ivyl.gg/hide-nvk.tar.zst and try with WINE_HIDE_NVK=1 We can then make it the default in proton script.
12:40 fdobridge: <S​id> even I dunno what the archive is so you'll have to tell me what's in it, in case you're confused by it
12:41 fdobridge: <S​id> I *am* downloading it, but
12:41 fdobridge: <S​id> slow network
12:41 fdobridge: <r​edsheep> I am certainly confused by it. I haven't messed with proton too much.
12:41 fdobridge: <S​id> contents please :D
12:42 fdobridge: <!​DodoNVK (she) 🇱🇹> https://tenor.com/view/ip-grabber-ip-grabber-thanos-gif-21846609
12:49 fdobridge: <i​vyl> it's a proton build
12:49 fdobridge: <S​id> figured, also hello 👋
12:49 fdobridge: <i​vyl> redistributable one, just drop it into compatibilitytools.d
12:49 fdobridge: <i​vyl> hi hi
12:49 fdobridge: <S​id> yup, that's what we're doing in #gayming
12:50 fdobridge: <S​id> I don't have the affected game(s), neither do I have access to my drives atm :P
12:53 fdobridge: <S​id> I really should start checking if important people are in this server already before playing the messenger
13:02 fdobridge: <z​mike.> I tested this just now and it doesn't work
13:02 fdobridge: <z​mike.> maybe I'm holding it wrong
13:05 fdobridge: <S​id> @gfxstrand someone just asked if we'd be open to suffixing `(NVK GA107)` to GPU names like their AMD one does `(RADV NAV21)`, to make it consistent with other mesa drivers, since intel does it too `Intel(R) UHD Graphics (TGL GT1)`
13:10 magic_rb: that would also maybe solve the problem of the games looking at the gpu name and going of that no?
13:11 Sid127: I don't think any game does that
13:11 Sid127: they look for gpu vendor/device PCI ids, either via dxgi or via winevulkan
13:13 magic_rb: ah
13:59 fdobridge: <g​fxstrand> We certainly could. It's a one line change to do that. It'd also make NVK results in gpuinfo distinguishable.
14:00 fdobridge: <g​fxstrand> It definitely worked for me in the one test. I wouldn't be surprised if it fails for some others.
14:01 fdobridge: <S​id> am aware it's a one line change, I just also wanted to run it by you first 😅
14:12 fdobridge: <g​fxstrand> Sure. Feel free to make the MR of you want
14:14 fdobridge: <S​id> will do once am less sick (and have my drives back) <3
14:16 fdobridge: <t​om3026> have you sent them off for repair? 😄
14:17 fdobridge: <S​id> they're still in my hardware, the data's just inaccessible
14:18 fdobridge: <S​id> kent's working on the fix, said it's ready but needs testing
14:21 fdobridge: <S​id> I'd test it, but
14:21 fdobridge: <S​id> there's a 50/50 chance it'll blow up, so
14:21 fdobridge: <S​id> I'd rather not take the gamble
14:24 fdobridge: <t​om3026> ah okay
14:26 fdobridge: <t​om3026> btrfs snapshots, backups. and i can pretty much restore things in an hour or two heh
14:26 fdobridge: <S​id> I have backups, but
14:26 fdobridge: <S​id> they're a month old
14:26 fdobridge: <S​id> and my dad put some data on the drives since then
14:27 fdobridge: <S​id> and, well, if me waiting results in bcachefs becoming a bit more resilient
14:27 fdobridge: <S​id> worth it
14:39 magic_rb: Ill still keep recommended people stick to zfs, it has a proven track record and is not tied to kernel versions, which is my primary concern with btrfs
14:41 Sid127: I'm not on btrfs though
15:00 fdobridge: <t​om3026> @airlied friendly reminder gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff 8-10 lines in dmesg when it goes from d3cold to D0, if it only displayport probe debug message
15:03 fdobridge: <t​om3026> @gfxstrand ❤️ im ingame in bg3 with everything at ultra 2560x1600 a bit slower then blob but it runs!
15:06 fdobridge: <r​edsheep> What kind of fps are you looking at? Mine was running at 12 fps
15:07 fdobridge: <t​om3026> uhm does it have an ingame counter
15:08 fdobridge: <m​ohamexiety> steam has one. not sure if gog galaxy does
15:08 fdobridge: <r​edsheep> I just have mine on in the steam overlay, you can also install mangohud and do mangohud %command% for launch options
15:08 fdobridge: <S​id> DXVK_HUD=fps
15:08 fdobridge: <r​edsheep> Oh gog, yeah no idea
15:08 fdobridge: <t​om3026> i have the galaxy one
15:09 fdobridge: <S​id> assuming you've set up dxvk for it
15:10 fdobridge: <p​homes_> vulkan or the other one?
15:10 fdobridge: <t​om3026> the other one
15:10 fdobridge: <t​om3026> never got the vulkan one running even on blob so heh
15:12 fdobridge: <p​homes_> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28096 seems to help for me on vulkan
15:13 fdobridge: <p​homes_> but then it hits a new problem that looked potentially related to rebar. I am on a 2080 so no rebar support for me
15:15 fdobridge: <r​edsheep> Isn't that the issue addressed on here? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27798
15:15 magic_rb: Sid: well bcachefs is also mostly tied to kernel versions, being able to update zfs without bumping my kernel is nice (tho mostly im waiting to bump the kernel because of zfs)
15:15 fdobridge: <S​id> fair, if it works for you, it works for you :)
15:15 magic_rb: :)
15:16 magic_rb: i just got this fun error while trying to play minecraft
15:16 magic_rb: MESA: error: ZINK: vkQueueSubmit failed (VK_ERROR_DEVICE_LOST)
15:16 magic_rb: MESA: error: zink: DEVICE LOST!
15:16 magic_rb: MESA: error: zink: DEVICE LOST!
15:16 fdobridge: <S​id> I was on zfs but I moved away since I need to run -rc kernels
15:16 fdobridge: <S​id> oh
15:16 magic_rb: yeah fair, thats not really an option on zfs
15:16 fdobridge: <S​id> what kernel version
15:16 magic_rb: 6.7
15:16 magic_rb: 6.7.9 to be precise
15:16 fdobridge: <S​id> ...huh
15:16 fdobridge: <S​id> strange
15:17 magic_rb: i unmapped the window and ran glxgears to check something, somewhere in between all that it froze
15:17 fdobridge: <S​id> zink and nvk versions?
15:18 magic_rb: will mesa commit be enough? or how can i get the versions
15:18 fdobridge: <S​id> commit it plenty
15:18 fdobridge: <p​homes_> Let me retest with the combination of that and 28096
15:18 fdobridge: <S​id> typo...
15:19 magic_rb: ill try digging the commit out of nixos
15:19 fdobridge: <t​om3026> https://ibb.co/gWdGCyD 25-30 oddly enough changing gfx settings upped it to 27-31 so its hitting some bottleneck 😛
15:20 fdobridge: <p​homes_> 27798 fixes the issues I have with Transport Fever 2. 27784 fixes X4 Foundations, and if BG3 works then I am out of vulkan native games that do not work 🙂
15:20 fdobridge: <t​om3026> and yeah vsync is off im getting 170+ in loading screen
15:20 fdobridge: <t​om3026> xD
15:20 fdobridge: <S​id> DOOM
15:20 fdobridge: <S​id> oh, you meant you personally 😅
15:21 fdobridge: <r​edsheep> Sounds like bg3 is probably another game where pixel throughput is the issue then, as I am at 4k. There are a good few games like that where 4k really kills it.
15:22 magic_rb: 1bcb7f1eb820edb0625bd4f7d0e4022978486b3a that should it
15:22 fdobridge: <r​edsheep> Which doom? Doom eternal works fine, though I believe it has a rendering bug, and it's probably the slowest currently working game I know of.
15:23 magic_rb: bg3 on my laptop runs awfully even on proprietary, seems to be linked very heavily to resolution, idk what they did
15:23 fdobridge: <r​edsheep> I was often at 6 fps while testing doom eternal
15:23 magic_rb: i remember doom eternal having issues on proprietary on release that nvidia had to fix, the only way for me to run it was at 640x480 and even then i got barely playable framerates xD
15:24 fdobridge: <r​edsheep> On the prop driver I can get like 270 fps, even with raytracing on. They've got it working pretty well these days.
15:25 magic_rb: Sid: it did the detach again :)
15:25 magic_rb: ill try not unmapping the window7
15:26 fdobridge: <r​edsheep> Doom eternal is easily the largest ratio of prop performance to nvk that I have found so far, it's probably 50x faster on average on the prop driver
15:26 fdobridge: <t​om3026> @tiredchiku yay runpm working, d3cold. 12w idle draw. bg3 runs. im permanently switched heh
15:27 magic_rb: its not the unmap, it just detaches for some reason (the zink error still)
15:28 magic_rb: [16140.154327] nouveau 0000:01:00.0: gsp: mmu fault queued
15:28 magic_rb: [16140.155225] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:32 type:31 scope:1 part:233
15:28 magic_rb: [16140.155229] nouveau 0000:01:00.0: fifo:c00000:0004:0020:[java[55340]] errored - disabling channel
15:28 magic_rb: [16140.155233] nouveau 0000:01:00.0: java[55339]: channel 32 killed!
15:29 magic_rb: nouveau 0000:01:00.0: gsp:msg fn:76 len:0x68/0x48 res:0x0 resp:0x0
15:29 magic_rb: there is some hex code after it
15:29 fdobridge: <S​id> DOOM, the reboot
15:29 fdobridge: <S​id> yippee
15:30 fdobridge: <S​id> I couldn't get DOOM's vulkan renderer going with nvk
15:30 fdobridge: <S​id> sad, since it's my favorite franchise
15:30 fdobridge: <S​id> I didn't try opengl renderer with ziNVK thougg
15:30 fdobridge: <p​homes_> bg3 is still broken with 28096 + 27798 for me
15:33 fdobridge: <r​edsheep> So doom 2016? Let me give it a try
15:34 fdobridge: <S​id> yup
15:35 fdobridge: <p​homes_> heh. According to steam I have 20.3 hours of "play time" on bg3. That is all just repeatedly running the intro scene and shader cache generation.
15:38 fdobridge: <S​id> I'm gonna take a short nap...
15:41 fdobridge: <z​mike.> I have 300+ hours logged in tomb raider (2013) from running the benchmark
15:45 magic_rb: any more info i can give in relation to the detachment?
16:06 fdobridge: <t​om3026> i have 6.8 + https://patchwork.freedesktop.org/patch/582273/ applied, mesa with 28106 28115 28096 27798 applied
16:07 fdobridge: <t​om3026> here it runs :p
16:12 fdobridge: <t​om3026> @sid which doom?
16:12 fdobridge: <t​om3026> @tiredchiku
16:12 fdobridge: <t​om3026> oh 2016
16:13 fdobridge: <r​edsheep> I downloaded it and yeah it randomly crashes and spits an mmu fault in dmesg
16:17 fdobridge: <t​om3026> dishonored 2 for some reason
16:17 fdobridge: <t​om3026> too
16:27 fdobridge:<z​mike.> gets ANVblocked trying to merge sparse fixes
17:20 TimurTabi: airlied: can you please apply https://lore.kernel.org/nouveau/20240210002900.148982-1-ttabi@nvidia.com/T/ ? kernel-test-robot keeps complaining about the comments and I really would like it to stop. Thanks.
18:24 fdobridge: <t​om3026> cool some trace has appeard in dmesg didnt notice when or where it came from https://gist.github.com/gulafaran/9a531fb115cf460eec7a163663755d03 heh
19:09 fdobridge: <g​fxstrand> @zmike, I started typing on a `shaderStorageImageMultisample` implementation. It's not hanging but it's also not working correctly yet. I need to spend some time tomorrow figuring out why. I'm AFK the rest of today.
19:20 fdobridge: <z​mike.> exciting
19:30 fdobridge: <z​mike.> I am again stabbing myself in the eye with dri interfaces
19:31 fdobridge: <S​id> sounds about right
20:08 fdobridge: <S​id> @airlied any idea why nouveau may not be detecting high res/rate modes on monitors that support it?
20:08 fdobridge: <a​irlied> because the code isn't written?
20:09 fdobridge: <S​id> ..huh
20:09 fdobridge: <S​id> how do we detect modes right now then
20:09 fdobridge: <S​id> because we're going up to 4k60 and not beyond
20:10 fdobridge: <S​id> https://paste.sidonthe.net/pasta/sloth-raven-frog
20:10 fdobridge: <a​irlied> lots of missing code in nouveau for lots of things
20:11 fdobridge: <S​id> hmmm
20:11 fdobridge: <S​id> still odd that whatever current logic we have gets us most of the way there
20:18 fdobridge: <S​id> wait
20:18 fdobridge: <S​id> ...nvm I have my answer even before I sent the ques
21:11 dakr: TimurTabi, applied the patch to drm-misc-next-fixes. Make sure to add me as recipient directly if you don't want me to miss patches. :-)