01:23 fdobridge: <r​edsheep> I have one of those exact same displays. It can be made to work with an X session with:
01:23 fdobridge: <r​edsheep>
01:23 fdobridge: <r​edsheep> ```xrandr --newmode "3840x2160_120" 1067.5735 3840 3888 3922 4002 2160 2164 2170 2223 +HSync -VSync
01:23 fdobridge: <r​edsheep> xrandr --addmode DP-1 "3840x2160_120"```
01:24 fdobridge: <r​edsheep> Naturally where you're using sway that isn't exactly what you want but it gives a useful way to test. For wayland sessions my understanding is you need to generate an override edid and load it with a kernel parameter.
01:25 fdobridge: <S​id> no the thing is, why does our existing mode detection code get us most of the way there
01:26 fdobridge: <r​edsheep> As far as I can tell the issue getting the best mode to work on nouveau is that nouveau is being too conservative somewhere, as that mode I sent is well outside the limits of a the normal cvt standard. Why it works to force it through, I don't know.
01:26 fdobridge: <S​id> it should either not work at all or detect all modes correctly
01:26 fdobridge: <S​id> hm
01:26 fdobridge: <S​id> I'll poke around to see where we do that, should be a fun adventure
01:26 fdobridge: <r​edsheep> That is similar to a cvt-rbv2 modeline, I am not sure it even fits that exactly either though. That monitor goes right up to the absolute limit of displayport.
01:27 fdobridge: <r​edsheep> Well, to the limit of DP HBR3 anyway
01:30 fdobridge: <S​id> mhm
01:48 fdobridge: <g​fxstrand> I'm gonna see if Maxwell can survive a CTS run now. Ya'know... Just for grins. 😅
01:48 TimurTabi: dakr: thanks, will do that from now on
01:59 fdobridge: <g​fxstrand> deqp-runner says it's going to take 8h because everything sparse is crashing. 🤡
01:59 fdobridge: <g​fxstrand> Looks like reserving sparse VA ranges just doesn't work on Maxwell.
02:00 fdobridge: <g​fxstrand> dakr, @airlied is there a reason for this?
02:03 fdobridge: <a​irlied> not sure, a quick glance at the code seems to suggest some maxwell like 1 << 17 sparse page size
02:05 fdobridge: <a​irlied> beyond that my maxwell related motivation is pretty low
02:07 fdobridge: <g​fxstrand> Whelp... That didn't last long. 😂
02:07 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1217292823146008627/message.txt?ex=66037f49&is=65f10a49&hm=850ba21e44a627cd30bce6ce6a4aeb1cfeece2ce62c962757e46e019926b91de&
02:07 fdobridge: <g​fxstrand> That's annoying...
02:07 fdobridge: <g​fxstrand> Yeah, mine too. I was just hoping that maybe now that things are more stable I could finally get a decent baseline for folks who wanted to hack on it.
02:07 fdobridge: <g​fxstrand> But given the fact that it just totally blew up, I don't think that's happening. 😅
02:09 fdobridge: <g​fxstrand> Back to my double ampere setup
02:10 fdobridge: <a​irlied> yeah maxwell will need someone who wants to dig into the kernel code I expect
02:11 fdobridge: <a​irlied> did you do single ampere 36-threads?
02:14 fdobridge: <g​fxstrand> Yeah, I did a couple. Takes 1h20 but succeeds
02:16 fdobridge: <g​fxstrand> Closed the bug
02:16 fdobridge: <g​fxstrand> I'll try and come up with a BAR patch I'm happy with tomorrow
02:17 fdobridge: <a​irlied> https://paste.centos.org/view/87b79c48 was the hack I ran locally
02:19 fdobridge: <g​fxstrand> That's not a bad patch. I'd call it `bar_heap`, personally.
02:19 fdobridge: <g​fxstrand> Care to make it an MR?
02:19 fdobridge: <g​fxstrand> I should re-boot my machine and re-enable ReBAR
02:20 fdobridge: <g​fxstrand> But maybe after I test that patch
02:20 fdobridge: <g​fxstrand> Yeah, I'll play around with that patch tomorrow and then re-enable ReBAR
02:21 fdobridge: <a​irlied> okay I'll clean up and MR it
02:24 fdobridge: <a​irlied> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28144
03:48 fdobridge: <g​fxstrand> Left you a comment. Also, I just threw it at the CTS.
03:48 fdobridge: <g​fxstrand> Results will be done in an hour or so but I'm headed to bed so I'll look in the morning.
06:01 fdobridge: <a​irlied> hmm appears 2080ti isn't working with gsp
06:20 Sid127: huh
06:21 Sid127: what's the issue
06:41 fdobridge: <a​irlied> something something runlist
06:42 fdobridge: <a​irlied> just never enable acceleration
06:57 fdobridge: <a​irlied> looks copy engine related
13:53 fdobridge: <g​fxstrand> Yeah, @prop_energy_ball was complaining about his 2080 super
13:53 fdobridge: <g​fxstrand> Yeah, @prop_energy_ball was complaining about their 2080 super (edited)
13:57 fdobridge: <J​oshie with Max-Q Design> 2060 Super
14:00 fdobridge: <S​id> seems like turing has a lot of trouble
14:01 fdobridge: <S​id> afaik first Rin's 2070S had issues
14:01 fdobridge: <S​id> now Joshie's 2060S
14:01 fdobridge: <S​id> and apparently 2080Ti as well
14:01 fdobridge: <g​fxstrand> I've not swapped in my 2060 Founder's edition but that one didn't work last I tried.
14:01 fdobridge: <S​id> ...are the GTX Turings the only turings with no issues or am I too much of a prime render offload user to notice
14:01 fdobridge: <g​fxstrand> I've not swapped in my 2060 Founder's edition in a while but that one didn't work last I tried. (edited)
14:02 fdobridge: <S​id> actually, no, I've driven external displays with my 1660Ti Mobile
14:02 fdobridge: <S​id> funky
14:04 fdobridge: <S​id> though, I guess it kinda makes sense since 535 was still marked alpha-quality on openrm, though idk if that is any indication of how feature complete the GSP was
14:05 fdobridge: <S​id> but then again, openrm was alpha-quality for all geforce and workstation cards, so probably not an indication of GSP completeness at all
14:07 fdobridge: <S​id> also, just a heads up, @gfxstrand, proton is going to be enabling nvapi on nvk with proton 9 by default: https://github.com/jp7677/dxvk-nvapi/pull/168
14:08 fdobridge: <S​id> so we *might* get bug reports about missing nvapi functionality once 24.1 is out
14:18 fdobridge: <p​homes_> GSP seems to work fine on my RTX 2080
14:46 fdobridge: <v​alentineburley> Did anyone have some time to check out https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28033 ? Is it correct to lock it to Volta+?
16:28 fdobridge: <g​fxstrand> More specifically, it should be locked to `nvk_use_nak()`
16:29 fdobridge: <g​fxstrand> I don't trust codegen
16:29 fdobridge: <g​fxstrand> Not for something that hairy, anyway.
16:30 fdobridge: <n​eils1130> GSP also works fine on my 2070
16:34 fdobridge: <m​henning> Yeah, codegen doesn't even attempt to reconverge control flow on volta+. It's definitely broken there
16:54 fdobridge: <v​alentineburley> I added the NAK check but I still haven't seen it on earlier gens so I kept it Volta+ for now, let me know if I should drop that
16:56 fdobridge: <g​fxstrand> By the time NAK is complete for Maxwell, it'll support uniform control-flow as well.
16:56 fdobridge: <g​fxstrand> There's no reason I know of why Maxwell can't do it.
16:59 fdobridge: <v​alentineburley> Done, thank you!
17:05 fdobridge: <g​fxstrand> I'm going to kick off a CTS run just to make sure it doesn't blow anything up
17:05 fdobridge: <g​fxstrand> Otherwise, looks good
17:58 kisak: Hi folks, so it doesn't sneak up on anybody, https://github.com/ValveSoftware/Proton/commit/e1ee8227c8f10dbd33ee2c43a549675ea05d59d4 https://github.com/ValveSoftware/wine/commit/febbad5b6d551348e0981042cf69dd6e0b9cca9b#diff-a8a36ab36748c031d7a9df9e204b1690c7c7a8037cd4da19f55e4307fae9fd22R443
17:59 kisak: Proton's going to be lying to games that the GPU is an AMD RX 6700XT when NVK is added to the mix so that it doesn't have to deal with the vendor-specific code paths.
17:59 Sid127: hi kisak, thanks for the heads up, but we were the ones that got ivyl to make those patches ^^'
18:00 Sid127: which is also going to be reverted soon after a discussion with ivyl, gofman, saancreed, and jens: https://github.com/jp7677/dxvk-nvapi/pull/168
18:02 Sid127: reasoning being it'd be better to make dxvk-nvapi enable it by default and allow bug reports to directly go under either nvk or dxvk-nvapi, through organic testing
18:02 Sid127: instead of adding yet another vendor workaround to the stack
18:03 kisak: Groovy, I figured it was worth mentioning instead of someone finding it as an unpleasant surprise.
18:06 Sid127: yeah, much appreciated :)
18:41 fdobridge: <g​fxstrand> @zmike. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28159
18:42 fdobridge: <g​fxstrand> I'm not 100% sure I'm happy with that implementation (it doesn't interact great with the fun descriptor extensions) but it'll get us going for now.
18:42 fdobridge: <z​mike.> heroic
18:42 fdobridge: <z​mike.> nice work
18:44 fdobridge: <r​inlovesyou> can we do this from mesa directly as well? what if a native game makes assumptions based on nvidia gpu?
18:45 fdobridge: <r​inlovesyou> surely nothing big or critical, but Sodium (minecraft mod) makes nvidia specific assumptions that are likely to deal with the proprietary driver rather than nvk
18:45 fdobridge: <r​inlovesyou> https://cdn.discordapp.com/attachments/1034184951790305330/1217544149516156999/image.png?ex=6604695a&is=65f1f45a&hm=bb6584f0b450f89c74037174d02a2541c1a6c08e2278c17b409aeb2419fd7d17&
18:46 fdobridge: <g​fxstrand> Easier than debugging sparse tests. 😂
18:46 fdobridge: <g​fxstrand> Easier than debugging GL sparse tests. 😂 (edited)
18:46 fdobridge: <z​mike.> :stressheadache: :hypertensionheadache: :fullheadache:
18:49 fdobridge: <z​mike.> yes, please fit every single test case into a single test
18:50 fdobridge: <S​id> tbf they should update sodium for it instead. though, afaik, threaded_opts is a proprietary driver env var which will likely not do anything on nvk
18:50 fdobridge: <S​id> either way, spoofing the gpu from the driver is not something we should do by default
18:52 fdobridge: <r​inlovesyou> i don't mean default
18:52 fdobridge: <r​inlovesyou> i want to know if we can do this with an env var
18:52 fdobridge: <r​inlovesyou> *just in case* something does have nvidia specific fixes that completely wrecks us for some reason
18:53 fdobridge: <r​inlovesyou> unlikely, but would be nice to know
18:53 fdobridge: <g​fxstrand> I have no idea WTF NVIDIA is doing for shaderStorageImageMultisample. The shader they emit is craziness.
18:53 fdobridge: <g​fxstrand> This is what makes me think we actually can beat them in perf one day.
18:53 fdobridge: <r​inlovesyou> that would be awesome to see
18:54 fdobridge: <g​fxstrand> For fairly normal things, their compiler is awesome. The moment they start doing workarounds, they emit utter insanity.
18:54 fdobridge: <g​fxstrand> Subgroups are nuts
18:54 fdobridge: <r​inlovesyou> i'm so ready to get rid of the proprietary drivers, i've already been running nouveau/nvk when i'm not playing a heavy game just to enjoy the no-nvidia-bs wayland experience
18:54 fdobridge: <g​fxstrand> MSAA storage images are 🤯
19:04 fdobridge: <S​id> I think driconf had something for it but I'm not sure
19:51 fdobridge: <!​DodoNVK (she) 🇱🇹> How crazy is that shader?
19:54 fdobridge: <g​fxstrand> Well, they're definitely reading and parsing image descriptors from the shader.
19:55 fdobridge: <g​fxstrand> But they're, like, reading most of it?!? you don't need nearly that much. You need like 1 thing.
19:55 fdobridge: <g​fxstrand> I'm very confused
19:56 fdobridge: <g​fxstrand> @karolherbst What is IGN in the context of a surface op?
19:56 fdobridge: <g​fxstrand> Does that mean it ignores bounds checking?
19:57 fdobridge: <g​fxstrand> If so, that could explain what they're doing
19:58 fdobridge: <g​fxstrand> Hrm... We're setting IGN, too
19:59 fdobridge: <k​arolherbst🐧🦀> @gfxstrand yes, it's the behavior on OOB accesses. `.IGN` for ignore, `.NEAR` for the nearest value (it's the default behavior) and `.TRAP` for trapping
19:59 fdobridge: <g​fxstrand> Oh, so IGN means "throw away the store"?
19:59 fdobridge: <k​arolherbst🐧🦀> yes
19:59 fdobridge: <g​fxstrand> Okay, yeah, IDK what they're doing
20:00 fdobridge: <k​arolherbst🐧🦀> on OOB that is
20:00 fdobridge: <k​arolherbst🐧🦀> but yeah
20:01 fdobridge: <g​fxstrand> Okay then I have no idea what they're doing
20:19 fdobridge: <g​fxstrand> Actually, maybe they're not reading the actual descriptor. Looking at `imageSamples()` and `imageSize()`, it looks like they have some sort of wide descriptor they're uploading somewhere.
20:19 fdobridge: <g​fxstrand> IDK why. I can do it all by burning 4 of the top 12 bits of the image handle
20:23 fdobridge: <r​edsheep> You already managed it with fp64 in vkpeak, so yeah clearly the Nvidia drivers are not perfect
21:05 fdobridge: <n​ishii_ko> hey i'm trying to get reclocking to run on my 2060, but gsp doesn't seem to be working/activating at all. i've enabled nouveau support and gsp support in my kernel, and i've also added ``nouveau.modeset=1 nouveau.config=NvGspRm=1`` to both grub and the inbuilt kernel cmdline
21:05 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217579214430146620/image.png?ex=66048a02&is=65f21502&hm=2345e18721e6acab5a342a8873bdf89df6e8e4cd1f55829ec21cfc6f042ca553&
21:08 fdobridge: <k​arolherbst🐧🦀> mind uploading your kernel logs? (via `dmesg` or `journalctl --dmesg --no-hostname`
21:11 fdobridge: <n​ishii_ko> here you go
21:11 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217580774484611172/nouveau.log?ex=66048b76&is=65f21676&hm=4ec014d8efcaeb37b49352f12cf71715cd48258ce48480166ea741891aee33d5&
21:15 fdobridge: <n​ishii_ko> here you go
21:15 fdobridge: <n​ishii_ko> ``journalctl --dmesg --no-hostname`` (edited)
21:15 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217580774484611172/nouveau.log?ex=66048b76&is=65f21676&hm=4ec014d8efcaeb37b49352f12cf71715cd48258ce48480166ea741891aee33d5&
21:19 fdobridge: <k​arolherbst🐧🦀> `nouveaUwU` :ferrisUwU:
21:20 fdobridge: <n​ishii_ko> uwu
21:20 fdobridge: <k​arolherbst🐧🦀> @nishii_ko anyway, everything looks in order
21:20 fdobridge: <k​arolherbst🐧🦀> so maybe just drivers being slow?
21:21 fdobridge: <k​arolherbst🐧🦀> why do you think gsp isn't loading?
21:21 fdobridge: <n​ishii_ko> my performance in games is the exact same as without the kernel setting on for me
21:22 fdobridge: <k​arolherbst🐧🦀> with GL or vulkan?
21:22 fdobridge: <n​ishii_ko> gl i think? i'm not sure, i think that's what osu runs on
21:23 fdobridge: <k​arolherbst🐧🦀> I wouldn't be surprised if the GL driver has weird limits... maybe try with nvk + zink and see if that runs better?
21:25 fdobridge: <n​ishii_ko> i've never actually tried nvk afaik, i assume i just grab it from here then recompile my mesa with zink?
21:25 fdobridge: <n​ishii_ko> https://github.com/maierfelix/nvk
21:26 fdobridge: <g​fxstrand> That's some JavaScript thing. It has nothing to do with open-source NVIDIA drivers.
21:26 fdobridge: <n​ishii_ko> o
21:26 fdobridge: <g​fxstrand> Just build mesa with `-Dvulkan-drivers=nouveau` and you'll get NVK.
21:27 fdobridge: <n​ishii_ko> oh i didn't read that, oops
21:27 fdobridge: <n​ishii_ko> alright
21:30 fdobridge: <n​ishii_ko> oh and, with zink would be? sorry for the questions twt
21:32 fdobridge: <k​arolherbst🐧🦀> a gallium-driver
21:32 fdobridge: <k​arolherbst🐧🦀> no idea how to enable that in gentoo
21:32 fdobridge: <k​arolherbst🐧🦀> ohh `USE=zink`
21:33 fdobridge: <S​id> `-Dgallium-drivers=zink`
21:33 fdobridge: <k​arolherbst🐧🦀> and then `MESA_LOADER_DRIVER_OVERRIDE=zink`
21:33 fdobridge: <k​arolherbst🐧🦀> when running stuff
21:33 fdobridge: <n​ishii_ko> okedoke
21:35 fdobridge: <n​ishii_ko> i assume i just use nouveau-experimental instead?
21:35 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217586932054360214/image.png?ex=66049132&is=65f21c32&hm=260f43aa2c1a7b484874e2367d05639b00b6b201d42d47bb678ac58210fa64a6&
21:36 fdobridge: <n​ishii_ko> and zink doesn't look to be an option either
21:37 fdobridge: <n​ishii_ko> this is from the mesa github mirror
21:37 fdobridge: <n​ishii_ko> https://github.com/Mesa3D/mesa
21:38 fdobridge: <k​arolherbst🐧🦀> I mean you can just use the ebuild, no?
21:38 fdobridge: <k​arolherbst🐧🦀> it's all there
21:38 fdobridge: <k​arolherbst🐧🦀> no need to build it yourself
21:38 fdobridge: <k​arolherbst🐧🦀> well..
21:38 fdobridge: <k​arolherbst🐧🦀> you'd build either way
21:38 fdobridge: <k​arolherbst🐧🦀> you know what I mean
21:38 fdobridge: <n​ishii_ko> tru, i'll use the ebuild
21:38 fdobridge: <k​arolherbst🐧🦀> use make sure that the `zink` `USE` flag is enabled
21:39 fdobridge: <n​ishii_ko> yeye
21:39 fdobridge: <n​ishii_ko> i'm just not sure if nvk is included since it's not put in there as a use flag
21:39 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217587987546767361/image.png?ex=6604922d&is=65f21d2d&hm=a9735a2b1399bb687720f97dfd6dfdedf1fa6959c2d3408eefc89cad0b43b0e8&
21:41 fdobridge: <k​arolherbst🐧🦀> ohh pain..
21:41 fdobridge: <k​arolherbst🐧🦀> it's not even in the `9999` ebuild yet
21:41 fdobridge: <k​arolherbst🐧🦀> https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/mesa/mesa-9999.ebuild#n335
21:41 fdobridge: <k​arolherbst🐧🦀> add a `vulkan_enable video_cards_nouveau nouveau`
21:42 fdobridge: <n​ishii_ko> okedoke
21:42 fdobridge: <n​ishii_ko> i'll force it to use the 9999 ebuild too
21:42 fdobridge: <k​arolherbst🐧🦀> yeah
21:42 fdobridge: <k​arolherbst🐧🦀> for nvk you should use main 😄
21:42 fdobridge: <k​arolherbst🐧🦀> I think on 24.0 it was still `nouveau-experimental`
21:43 fdobridge: <n​ishii_ko> ye
21:43 fdobridge: <n​ishii_ko> btw not 100% sure here, as a useflag or in my make.conf with video_cards?
21:44 fdobridge: <k​arolherbst🐧🦀> it will trigger on the video_cards thing
21:44 fdobridge: <k​arolherbst🐧🦀> `video_cards_nouveau` is just the expanded use flags from `VIDEO_CARDS`
21:44 fdobridge: <k​arolherbst🐧🦀> so `VIDEO_CARDS=nouveau` will set `USE=video_cards_nouveau`
21:44 fdobridge: <k​arolherbst🐧🦀> that's how those flags work
21:46 fdobridge: <n​ishii_ko> sorry i'm kinda dense -w- will that mean i don't need to add video_cards_nouveau as a useflag? and where should i still put the other two?
21:47 fdobridge: <k​arolherbst🐧🦀> nah, if you have `VIDEO_CARDS=nouveau` set, you won't have to change anything after adding that `vulkan_enable` line to the ebuild
21:48 fdobridge: <k​arolherbst🐧🦀> well..
21:48 fdobridge: <k​arolherbst🐧🦀> maybe add the vulkan stuff if you haven't already
21:48 fdobridge: <k​arolherbst🐧🦀> `USE=vulkan`
21:48 fdobridge: <n​ishii_ko> i'll add vulkan as a useflag
21:50 fdobridge: <k​arolherbst🐧🦀> you'll need it anyway for proton and other things
21:50 fdobridge: <n​ishii_ko> mhm
21:51 fdobridge: <n​ishii_ko> oh wait, gsp is proprietary isn't it? would i have to compile with ``USE=proprietary-codecs``
21:51 fdobridge: <k​arolherbst🐧🦀> no
21:51 fdobridge: <k​arolherbst🐧🦀> that's something else
21:52 fdobridge: <n​ishii_ko> oh wait yeah i just looked at it nvm
21:52 fdobridge: <k​arolherbst🐧🦀> that's for video codecs, like h.264
21:52 fdobridge: <k​arolherbst🐧🦀> which... we don't really support for now anyway
21:52 fdobridge: <n​ishii_ko> mhm
21:53 fdobridge: <k​arolherbst🐧🦀> anyway, once it's all done, there should be a `nouveau_icd.x86_64.json` (and `i686`) file inside `/usr/share/vulkan/icd.d/`
21:55 fdobridge: <n​ishii_ko> err, i've added zink to the useflags but it still says -zink when i'm about to compile it
21:55 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217591781043208312/image.png?ex=660495b6&is=65f220b6&hm=35d6befb8b47415a782e87c6e12e1532f4d842a7cf05984aa1975b8590296893&
21:55 fdobridge: <k​arolherbst🐧🦀> ohh.. that's masked...
21:55 fdobridge: <k​arolherbst🐧🦀> uhh
21:55 fdobridge: <k​arolherbst🐧🦀> how did that part work...
21:55 fdobridge: <k​arolherbst🐧🦀> you'd need to overwrite the profile mask
21:56 fdobridge: <n​ishii_ko> uhh lemme figure out how
21:57 fdobridge: <k​arolherbst🐧🦀> `echo "-zink" >> /etc/portage/profile/use.mask`
21:57 fdobridge: <k​arolherbst🐧🦀> ehh wait
21:57 fdobridge: <k​arolherbst🐧🦀> yeah..
21:57 fdobridge: <n​ishii_ko> oh ty lol
21:57 fdobridge: <k​arolherbst🐧🦀> that's the right thing
21:57 fdobridge: <k​arolherbst🐧🦀> I used to run gentoo with `USE=-*` :ferrisCluelesser:
21:58 fdobridge: <n​ishii_ko> yee zink is enabled now
21:58 fdobridge: <n​ishii_ko> i've been curious about running gentoo with that but i've only been using gentoo very recently -w-
21:59 fdobridge: <n​ishii_ko> waiting for it to compile nojw
21:59 fdobridge: <n​ishii_ko> does it even matter which profile you select if you're running that? xd
22:02 fdobridge: <a​irlied> hmm devinit_disable turns off the first copy engine
22:03 fdobridge: <k​arolherbst🐧🦀> don't.. your `/etc/portage` will be 100kB
22:03 fdobridge: <k​arolherbst🐧🦀> though
22:03 fdobridge: <k​arolherbst🐧🦀> if you want to learn a lot...
22:03 fdobridge: <k​arolherbst🐧🦀> yeah.. need to unmask use flags :ferrisUpsideDown:
22:04 fdobridge: <k​arolherbst🐧🦀> but yeah.. at this point the saner option would be a custom profile
22:04 fdobridge: <k​arolherbst🐧🦀> maybe
22:04 fdobridge: <n​ishii_ko> mesa has been compiled, gonna reboot rq
22:08 fdobridge: <n​ishii_ko> same framerate in osu -w-
22:08 fdobridge: <n​ishii_ko> and also kitty suddenly doesn't want to open for some reason
22:08 fdobridge: <S​id> some games don't perform well, yes
22:08 fdobridge: <k​arolherbst🐧🦀> what's glxinfo saying?
22:09 fdobridge: <n​ishii_ko> that explains it
22:09 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217595330145816587/image.png?ex=66049904&is=65f22404&hm=0d07ce44a9c2a73c21eb9371bbab819aa3848063952315dfd13de74fb27c546f&
22:09 fdobridge: <S​id> doom eternal runs at single digit framerates, even on a 4090, for example
22:09 fdobridge: <n​ishii_ko> err 1 sec
22:10 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217595752499511438/glxinfo.txt?ex=66049969&is=65f22469&hm=8ee506fd78dcd82f73dee7ea5b29481fdfda54ea52d05d9eee063b7e08ce507f&
22:11 fdobridge: <k​arolherbst🐧🦀> @nishii_ko ^^
22:11 fdobridge: <k​arolherbst🐧🦀> as an env variable
22:11 fdobridge: <n​ishii_ko> oh shoot oops
22:12 fdobridge: <S​id> yeah you'll have to set that in /etc/environment or wherever
22:12 fdobridge: <S​id> so make everything use zink
22:12 fdobridge: <n​ishii_ko> yeye
22:12 fdobridge: <k​arolherbst🐧🦀> maybe not
22:12 fdobridge: <k​arolherbst🐧🦀> because your destkop might not start 🥲
22:12 fdobridge: <S​id> yeah
22:12 fdobridge: <S​id> you know
22:12 fdobridge: <S​id> 50/50
22:12 fdobridge: <k​arolherbst🐧🦀> I wouldn't trust it to run the desktop yet 😄
22:12 fdobridge: <n​ishii_ko> tty has my back we're all good :p
22:13 fdobridge: <k​arolherbst🐧🦀> 😄
22:13 fdobridge: <k​arolherbst🐧🦀> the gentoo life is real
22:15 fdobridge: <n​ishii_ko> kitty still no worky :( and osu framerate still the same
22:15 fdobridge: <k​arolherbst🐧🦀> 😢
22:15 fdobridge: <k​arolherbst🐧🦀> is your CPU being busy or something?
22:16 fdobridge: <n​ishii_ko> cpu under 5%, and fps in osu increases to my regular refresh rate when i exit fullscreen and tile the window which is an interesting discovery
22:17 fdobridge: <n​ishii_ko> hitting 144 comfy too
22:18 fdobridge: <n​ishii_ko> gonna have to set alacritty as my term for now -w- kitty no worky
22:18 fdobridge: <n​ishii_ko> having multiple terminals installed for no reason turned out to pay off after all
22:20 fdobridge: <n​ishii_ko> huh, disabling the frame tearing windowrule makes my fps go to my refresh rate
22:20 fdobridge: <n​ishii_ko> erm...
22:20 fdobridge: <p​avlo_it_115> show ```MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo | grep OpenGL``` please
22:21 fdobridge: <k​arolherbst🐧🦀> pain 😄
22:21 fdobridge: <k​arolherbst🐧🦀> so it's working?
22:21 fdobridge: <k​arolherbst🐧🦀> anyway.. users report that games kinda run faster with zink
22:22 fdobridge: <k​arolherbst🐧🦀> so your work wasn't for nothing!
22:22 fdobridge: <n​ishii_ko> ```
22:22 fdobridge: <n​ishii_ko> MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
22:22 fdobridge: <n​ishii_ko> glx: failed to create drisw screen
22:22 fdobridge: <n​ishii_ko> failed to load driver: zink```
22:22 fdobridge: <n​ishii_ko> that, but a lot
22:22 fdobridge: <k​arolherbst🐧🦀> mhhhh
22:22 fdobridge: <S​id> zink needs swrast, I think
22:23 fdobridge: <S​id> not sure
22:23 fdobridge: <p​avlo_it_115> try ``` NVK_I_WANT_A_BROKEN_VULKAN_DRIVER MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo | grep OpenGL```
22:23 fdobridge: <k​arolherbst🐧🦀> nah.. that's on turing
22:23 fdobridge: <p​avlo_it_115> try ``` NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1 MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo | grep OpenGL``` (edited)
22:23 fdobridge: <k​arolherbst🐧🦀> should be okay
22:23 fdobridge: <k​arolherbst🐧🦀> @nishii_ko `vulkaninfo` does print tons of pages?
22:23 fdobridge: <n​ishii_ko> i am on turing
22:23 fdobridge: <S​id> try building both zink and swrast gallium drivers
22:23 fdobridge: <k​arolherbst🐧🦀> yeah.. might have to enable `swrast` as a video card...
22:24 fdobridge: <n​ishii_ko> this but lots again
22:24 fdobridge: <n​ishii_ko> ```MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
22:24 fdobridge: <n​ishii_ko> glx: failed to create drisw screen
22:24 fdobridge: <n​ishii_ko> failed to load driver: zink```
22:24 fdobridge: <n​ishii_ko> don't have the command
22:24 fdobridge: <k​arolherbst🐧🦀> ehh wait
22:24 fdobridge: <n​ishii_ko> video_cards?
22:24 fdobridge: <k​arolherbst🐧🦀> it's always enabled
22:24 fdobridge: <p​avlo_it_115> https://packages.gentoo.org/packages/dev-util/vulkan-tools
22:24 fdobridge: <S​id> no I remember trying to build only zink as a gallium driver on arch and it spit an error at me at build time
22:24 fdobridge: <n​ishii_ko> ty
22:25 fdobridge: <k​arolherbst🐧🦀> yeah.. I guess something is messed up with your vulkan config...
22:25 fdobridge: <k​arolherbst🐧🦀> or so...
22:25 fdobridge: <k​arolherbst🐧🦀> dunno
22:25 fdobridge: <k​arolherbst🐧🦀> make simple vulkan thing work
22:26 fdobridge: <n​ishii_ko> ```:3 nishi@gentoo ~ $ vulkaninfo
22:26 fdobridge: <n​ishii_ko> WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Received return code -3 from call to vkCreateInstance in ICD /usr/lib64/libvulkan_dzn.so. Skipping this driver.
22:26 fdobridge: <n​ishii_ko> ERROR: [Loader Message] Code 0 : terminator_CreateInstance: Found no drivers!
22:26 fdobridge: <n​ishii_ko> Cannot create Vulkan instance.
22:26 fdobridge: <n​ishii_ko> This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
22:26 fdobridge: <n​ishii_ko> ERROR at /var/tmp/portage/dev-util/vulkan-tools-1.3.275/work/Vulkan-Tools-vulkan-sdk- failed with ERROR_INCOMPATIBLE_DRIVER```
22:26 fdobridge: <p​avlo_it_115> @nishii_ko ls /usr/share/vulkan/icd.d/
22:27 fdobridge: <n​ishii_ko> ```:3 nishi@gentoo ~ $ ls /usr/share/vulkan/icd.d/
22:27 fdobridge: <n​ishii_ko> dzn_icd.i686.json dzn_icd.x86_64.json```
22:27 fdobridge: <k​arolherbst🐧🦀> huh...
22:27 fdobridge: <p​avlo_it_115> nvk not installed
22:27 fdobridge: <k​arolherbst🐧🦀> where is the nouveau file..
22:27 fdobridge: <k​arolherbst🐧🦀> sure you used your local ebuild?
22:27 fdobridge: <k​arolherbst🐧🦀> oh uhh. mhhh
22:27 fdobridge: <n​ishii_ko> yeah
22:28 fdobridge: <k​arolherbst🐧🦀> mhhhhh
22:28 fdobridge: <n​ishii_ko> ```:3 nishi@gentoo ~ $ emerge --search mesa
22:28 fdobridge: <n​ishii_ko>
22:28 fdobridge: <n​ishii_ko> [ Results for search key : mesa ]
22:28 fdobridge: <n​ishii_ko> Searching...
22:28 fdobridge: <n​ishii_ko>
22:28 fdobridge: <n​ishii_ko> * dev-ruby/paramesan
22:28 fdobridge: <n​ishii_ko> Latest version available: 1.0.1-r1
22:28 fdobridge: <n​ishii_ko> Latest version installed: [ Not Installed ]
22:28 fdobridge: <n​ishii_ko> Size of files: 5 KiB
22:28 fdobridge: <n​ishii_ko> Homepage: https://github.com/jpace/paramesan
22:28 fdobridge: <n​ishii_ko> Description: Parameterized tests in Ruby
22:28 fdobridge: <n​ishii_ko> License: MIT
22:28 fdobridge: <n​ishii_ko>
22:28 fdobridge: <n​ishii_ko> * media-libs/mesa
22:28 fdobridge: <n​ishii_ko> Latest version available: 9999
22:28 fdobridge: <n​ishii_ko> Latest version installed: 9999
22:28 fdobridge: <n​ishii_ko> Size of files: 0 KiB
22:28 fdobridge: <n​ishii_ko> Homepage: https://www.mesa3d.org/ https://mesa.freedesktop.org/
22:28 fdobridge: <n​ishii_ko> Description: OpenGL-like graphic library for Linux
22:28 fdobridge: <n​ishii_ko> License: MIT SGI-B-2.0
22:28 fdobridge: <n​ishii_ko>
22:28 fdobridge: <n​ishii_ko> * media-libs/mesa-amber
22:28 fdobridge: <n​ishii_ko> Latest version available: 21.3.9-r1
22:28 fdobridge: <n​ishii_ko> Latest version installed: [ Not Installed ]
22:28 fdobridge: <n​ishii_ko> Size of files: 16,219 KiB
22:28 fdobridge: <n​ishii_ko> Homepage: https://docs.mesa3d.org/amber.html
22:28 fdobridge: <n​ishii_ko> Description: OpenGL-like graphic library for Linux
22:28 fdobridge: <n​ishii_ko> License: MIT SGI-B-2.0
22:28 fdobridge: <n​ishii_ko>
22:28 fdobridge: <n​ishii_ko> * x11-apps/mesa-progs
22:28 fdobridge: <n​ishii_ko> Latest version available: 8.5.0
22:28 fdobridge: <n​ishii_ko> mesa-amber?
22:28 fdobridge: <k​arolherbst🐧🦀> do you have build logs?
22:28 fdobridge: <n​ishii_ko> err were to find?
22:28 fdobridge: <n​ishii_ko> err where to find? (edited)
22:29 fdobridge: <k​arolherbst🐧🦀> no idea 🙂
22:29 fdobridge: <k​arolherbst🐧🦀> but nvk depends on rust and stuff... so I wouldn't be surprised if it's actually not built
22:30 fdobridge: <n​ishii_ko> gonna go through this then recompile mesa again... -w-
22:30 fdobridge: <n​ishii_ko> https://wiki.gentoo.org/wiki/Portage_log
22:30 fdobridge: <k​arolherbst🐧🦀> it should have aborted the build or so.. it's a bit surprising it actually compiled
22:31 fdobridge: <k​arolherbst🐧🦀> but yeah.. I think you'll have to wait until it's officially supported as I doubt it's a non trivial change
22:32 fdobridge: <k​arolherbst🐧🦀> https://github.com/gentoo/gentoo/pull/35658
22:32 fdobridge: <k​arolherbst🐧🦀> or just use that?
22:33 fdobridge: <k​arolherbst🐧🦀> sounds like it's the proper way of enabling it 🙂
22:33 fdobridge: <n​ishii_ko> err i'm not sure how to build github pull requests -w-
22:33 fdobridge: <k​arolherbst🐧🦀> you could just download the modified files
22:34 fdobridge: <k​arolherbst🐧🦀> and add it to your local tree
22:34 fdobridge: <n​ishii_ko> oh true
22:34 fdobridge: <n​ishii_ko> would i have to add it back after emaint sync?
22:35 fdobridge: <k​arolherbst🐧🦀> ehh... depends on how you do it
22:36 fdobridge: <k​arolherbst🐧🦀> if you have a proper local repository, then no
22:36 fdobridge: <n​ishii_ko> i'm not exactly sure how to make a local repo -w- i'll just throw it into gentoo repo for now and figure that out later
22:36 fdobridge: <k​arolherbst🐧🦀> https://wiki.gentoo.org/wiki/Creating_an_ebuild_repository apparently
22:37 fdobridge: <n​ishii_ko> oh ty
22:37 fdobridge: <a​irlied> okay got a hack for 2080Ti , not sure what the right answer is
22:37 fdobridge: <n​ishii_ko> i'll do that whenever i feel like it for now -w-
22:37 fdobridge: <n​ishii_ko> just gonna cp into gentoo repo directly
22:37 fdobridge: <k​arolherbst🐧🦀> fair 😄
22:39 fdobridge: <n​ishii_ko> a
22:39 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217602962575200366/image.png?ex=6604a020&is=65f22b20&hm=8b8803730ae6b74e71498558cb35f63db3e90e32b58df7c396c2764b9a836cd6&
22:40 fdobridge: <n​ishii_ko> it should be this one though right?
22:40 fdobridge: <n​ishii_ko> https://cdn.discordapp.com/attachments/1034184951790305330/1217603168070926367/image.png?ex=6604a051&is=65f22b51&hm=d510cb16d637cb3f9f1941594133542d5fd256f3db691231cc9639db133546c0&
22:40 fdobridge: <k​arolherbst🐧🦀> nah, need it for the ebuild
22:40 fdobridge: <n​ishii_ko> ```DIST mesa-24.0.2.tar.xz 19989088 BLAKE2B f69e0b3edb7b8611f528a2e04104fe14b2fe8c799921be2d112dba744133813a19f90aa11d39f3f87a282e518003c7cc7966143d25e845f1f4489c461b22f661 SHA512 b975b5019ea37a2cc76c26e7a0b055a72f7c1cef888418cd654fd89ec667914c89cff5571d4c57828f2ce28a1b80ed707329cb88d60407fd875e6a6ebfaab7b3```
22:41 fdobridge: <n​ishii_ko> i've just replaced the manifest and ebuild with the ones i dled from the pull req
22:41 fdobridge: <k​arolherbst🐧🦀> ohh
22:41 fdobridge: <k​arolherbst🐧🦀> right, yeah
22:41 fdobridge: <k​arolherbst🐧🦀> need to add it back
22:41 fdobridge: <k​arolherbst🐧🦀> if you sync via git you can also use git to bring it all back, but yeah 😄
22:43 fdobridge: <n​ishii_ko> i'm just gonna emaint sync -w-
22:43 fdobridge: <n​ishii_ko> i'm just gonna emaint sync --repo gentoo -w- (edited)
22:43 fdobridge: <!​DodoNVK (she) 🇱🇹> Where is it?
22:44 fdobridge: <n​ishii_ko> you think just replacing the ebuild might work?
22:45 fdobridge: <n​ishii_ko> it in fact did not
22:47 fdobridge: <n​ishii_ko> eughh i might have to stick with blob
22:48 fdobridge: <n​ishii_ko> i have a 1660 super we haven't sold yet, do you think maybe it'll work any better?
22:51 fdobridge: <k​arolherbst🐧🦀> nah, same problem
22:51 fdobridge: <n​ishii_ko> damn TwT
22:52 fdobridge: <k​arolherbst🐧🦀> kinda need the vulkan driver if you really care about playing some games and stuff
22:53 fdobridge: <n​ishii_ko> i'll just keep using the blob for now then -w-
22:54 fdobridge: <n​ishii_ko> i'll see if i can find help on stopping the steam client from flashing intensely with the proprietary drivers
22:55 fdobridge: <n​ishii_ko> ty for your help
23:47 fdobridge: <p​homes_> "nvk: enable a mappable bar heap when rebar is disabled" is causing my computer to hang when I test games like X4 and BG3
23:48 fdobridge: <S​id> what kernel version?
23:49 fdobridge: <p​homes_> 6.8.0-rc7
23:53 fdobridge: <S​id> hmm, strange, so it's not the issue I thought it was
23:54 fdobridge: <p​homes_> https://gitlab.freedesktop.org/mesa/mesa/-/issues/10816