02:16 fdobridge: <r​inlovesyou> I think once nvk gets competitive in terms of performance Nvidia will eventually have to contribute to nouveau/nvk
02:16 fdobridge: <r​inlovesyou> Other than people who rely on cuda, I'm sure many people will switch
02:16 fdobridge: <r​inlovesyou> I know i will
02:48 fdobridge: <S​id> I rely on cuda
02:48 fdobridge: <S​id> I will still switch
02:48 fdobridge: <S​id> can always load nvidia if/when I need it
05:17 fdobridge: <r​inlovesyou> True
05:17 fdobridge: <r​inlovesyou> https://cdn.discordapp.com/attachments/1034184951790305330/1221326962941755402/voice-message.ogg?ex=66122c5f&is=65ffb75f&hm=e72c03832d9e7557053e8bebd9443d9b82a428c92f1da7ef5f165da9e7bed86d&
08:03 fdobridge: <d​jdeath3483> Welcome to the XeSS club : https://www.phoronix.com/news/NVK-Vendor-ID-Workaround
08:10 fdobridge: <v​alentineburley> Thanks, I hate it.
08:10 fdobridge: <v​alentineburley> Couldn't we fake the driver version instead for the odd native games? Everything else should be handled in Proton anyway.
08:10 fdobridge: <v​alentineburley> Unless there's some native games where the problem isn't simply the lower driver version in Mesa than the blob.
08:13 fdobridge: <d​adschoorse> I think it's funny that a lot of people complain about vulkan extensions, while d3d has all those terrible driver specific libraries
08:13 fdobridge: <d​adschoorse> or maybe it's more depressing than funny
11:07 fdobridge: <v​alentineburley> On NVK it's not about driver specific libraries but just the driver version being lower than the blob
11:07 fdobridge: <v​alentineburley> 24.0 vs 550.67
11:08 fdobridge: <v​alentineburley> Which is why I still think we should be overriding the driver version rather than vendor ID until we find a native game that actually needs that
11:22 fdobridge: <d​adschoorse> maybe for that one game, but nvk will have nvapi related issues
11:23 fdobridge: <d​adschoorse> even the nv driver has issues with it
11:23 fdobridge: <v​alentineburley> What native games are affected?
11:24 fdobridge: <d​adschoorse> why does it matter if a game is native?
11:24 fdobridge: <v​alentineburley> Because otherwise it's a Proton or dxvk_nvapi problem
11:24 fdobridge: <v​alentineburley> not NVK problem imo
11:24 fdobridge: <d​adschoorse> XeSS isn't native either
11:25 fdobridge: <v​alentineburley> And I'm not a fan of faking the driver id there in the driver id either, but I'm sure they have a reason
11:25 fdobridge: <v​alentineburley> And I'm not a fan of faking the driver id there in the driver either, but I'm sure they have a reason (edited)
11:26 fdobridge: <p​ac85> My take is that it is a trivial thing and I wouldn't think too hard about it
11:26 fdobridge: <v​alentineburley> Yeah fair
12:17 fdobridge: <l​eopard1907> Nah, XeSS situation is different.
12:18 fdobridge: <l​eopard1907> Unless you claim ANV is not the official driver for Linux of Intel, then yes.
12:18 fdobridge: <l​eopard1907> Same thing.
12:21 fdobridge: <l​eopard1907> I really can't compare NVK vs ANV and say "oh ye, they are the same in that regard because reasons" while one is the official driver of the said company.
13:04 fdobridge: <p​ixelcluster> I don't think it is
13:05 fdobridge: <p​ixelcluster> (i don't think it's different)
13:06 fdobridge: <p​ixelcluster> the fundamental issue in both cases is that windows games expect windows-driver-specific libraries to be available when running a gpu from the respective vendor
13:07 fdobridge: <p​ixelcluster> the proprietary nv linux driver just happens to expose (roughly) the same api as well, so you get lucky and can make a translation layer forwarding the api calls, thus avoiding the issue
13:53 fdobridge: <l​eopard1907> NVK is a third party, unofficial driver so it blowing up because of incompat with components that expects NV blob is expected and understandable.
13:53 fdobridge: <l​eopard1907> ANV is the official Linux driver from Intel so that being judged in the same way like NVK is not fair imo.
13:54 fdobridge: <l​eopard1907> Not fair to NVK.
13:58 fdobridge: <p​ixelcluster> I'm not "judging" any driver, and I don't think it makes any sense to do that
14:44 fdobridge: <l​eopard1907> Well people do compare things to reach a judgment/conclusion 🐸
14:44 fdobridge: <l​eopard1907> Even if you didn't , convo was purely about that
14:47 fdobridge: <l​eopard1907> I'm just saying "welcome to XeSS club" saying should have a very different interpretation here because "reasons why they get those issues" are coming from two different places, even if end result is the same aka adding workarounds to make things work.
14:48 fdobridge: <l​eopard1907> One is Intel failure ( imo ) , other is not exactly a NVK failure
15:00 fdobridge: <p​ac85> I don't know if it is an Intel failure though
15:01 fdobridge: <p​ac85> Like the core issue is non standard libraries that bypass the driver. Nvidia and Intel have done the same here
15:01 fdobridge: <p​ac85> So neither anv or nvk should be blamed and both Intel and nvidia should be maybe?
15:26 fdobridge: <l​eopard1907> Something that company did provide causes a mess here with no fix. It is Intel fault due to that.
15:26 fdobridge: <l​eopard1907>
15:26 fdobridge: <l​eopard1907> Just like how before dxvk-nvapi happened dxvk had to spoof nearly everything to AMD due to that being NV's fault.
15:31 fdobridge: <l​eopard1907> Bottomline is ; ANV and NVK being treated the same way is wrong.
15:31 fdobridge: <l​eopard1907>
15:31 fdobridge: <l​eopard1907> One would think since XeSS is an Intel lib, Intel would be able to solve it instead of working around.
15:31 fdobridge: <l​eopard1907>
15:31 fdobridge: <l​eopard1907> NVK being an unofficial driver would make certain things passable like workarounds above, but same being said for ANV is just ignoring the problem imo.
15:51 fdobridge: <!​DodoNVK (she) 🇱🇹> I wonder if this is actually a nouveau bug: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/38
15:54 fdobridge: <k​arolherbst🐧🦀> obviously not, because it's filed against Arch, case closed 😛
15:54 fdobridge: <k​arolherbst🐧🦀> but anyway
15:54 fdobridge: <k​arolherbst🐧🦀> that's userspace domain
15:54 fdobridge: <k​arolherbst🐧🦀> the kernel driver do not care a tiny bit about any of this
15:55 fdobridge: <k​arolherbst🐧🦀> @asdqueerfromeu starting a clean session?
15:55 fdobridge: <k​arolherbst🐧🦀> *considered
15:56 fdobridge: <!​DodoNVK (she) 🇱🇹> I didn't make that bug report (I noticed this when looking for any new major bugs on Arch)
15:56 fdobridge: <k​arolherbst🐧🦀> ahh
17:07 fdobridge: <d​jdeath3483> Just noting not only Anv will have issues with XeSS, obviously different reasons
17:10 fdobridge: <l​eopard1907> 👍
17:25 fdobridge: <d​adschoorse> I kind of hoped that XeSS could work with matrix acceleration on anv when ms releases sm6.8, but now microsoft removed wmma from that
17:30 fdobridge: <p​avlo_it_115> This firmware still needs to be extracted from driver. I tried, but in vain
17:30 fdobridge: <p​avlo_it_115> Damn, I don't even know what to do = )
17:31 fdobridge: <m​agic_rb.> couldnt we capture it? say if we ran the driver from a vm?
17:31 fdobridge: <p​avlo_it_115> I'm desperate
17:31 fdobridge: <m​agic_rb.> or is that even worse than extraction
17:31 fdobridge: <p​avlo_it_115> idk
17:31 fdobridge: <p​avlo_it_115> i`m not specialtist for this
17:32 fdobridge: <m​agic_rb.> yeah me neither, im a nixos developer and haskell programmer lol
17:36 fdobridge: <!​DodoNVK (she) 🇱🇹> <https://www.youtube.com/watch?v=ox0rH8mX6B8>
17:38 fdobridge: <p​avlo_it_115> I'm generally new to programming :-P
17:40 fdobridge: <m​agic_rb.> not bad
17:40 fdobridge: <m​agic_rb.> stick with it
17:40 fdobridge: <p​avlo_it_115> Generally speaking, I think it's hopeless :-R. I just can't imagine the amount of work. I can't take it out alone. I'd like to ask for help here, but no one cares about it but you
17:41 fdobridge: <p​avlo_it_115> Generally speaking, I think it's hopeless :-R. I just can't imagine the amount of work. I can't take it out alone. I'd like to ask for help here, but no one cares about it but you @magic_rb. (edited)
17:43 fdobridge: <m​agic_rb.> to be fair, the moment i can afford a new gpu, ill get something newer than a 1060, but it would be nicer to not have to ig
17:43 fdobridge: <m​agic_rb.> and it would be legally very dubious, dont know if i want to go down that road now
17:46 fdobridge: <p​avlo_it_115> Generally speaking, I think it's hopeless :-R. I just can't imagine the amount of work. I can't take it out alone. I'd like to ask for help here, but no one cares about it but you and me @magic_rb. (edited)
17:47 fdobridge: <m​ohamexiety> what's the issue with XeSS and anv? no Vk support?
18:07 fdobridge: <l​eopard1907> No VK, not open sauce and makes games blow up on ANV because XeSS has two paths
18:07 fdobridge: <l​eopard1907> Intel specific and generic one
18:07 fdobridge: <l​eopard1907> It tries to take former path if it sees intel and boom
18:37 fdobridge: <p​avlo_it_115> @magic_rb. Would you like to join effort on pascal reclocking? Like create a team
18:37 fdobridge: <p​avlo_it_115> Like, You and I are going to do this
18:38 fdobridge: <p​avlo_it_115> Are you not interested in this?
18:38 fdobridge: <m​agic_rb.> No i wouldnt currently, im broke and dont have time
18:38 fdobridge: <p​avlo_it_115> okay..
18:39 fdobridge: <m​agic_rb.> And the moment i have the money ill buy a 2060 and wont care anymore
18:39 fdobridge: <m​agic_rb.> Since unfortunately ive had to learn to value my time
18:39 fdobridge: <p​avlo_it_115> https://tenor.com/view/jetstream-sam-my-beloved-gif-22029076
21:16 fdobridge: <d​jdeath3483> it's even more stupid than that, old version tries to look up the driver dll, which is not there in proton, and so just crashes...
21:21 fdobridge: <l​eopard1907> Lol