00:01 fdobridge: <m​ohamexiety> ahh
03:47 fdobridge: <g​fxstrand> The modifiers MR is now passing CTS if folks want to play with it. It affects the display pipeline pretty hard so it'd be good to get a bit of testing. I'll be doing some manual testing tomorrow to make sure we're hitting all the paths.
03:48 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28843
03:48 fdobridge: <g​fxstrand> It's potentially a small perf boost but I'm honestly not too concerned about that aspect. More concerned that it doesn't screw anything up in any weird configurations.
03:50 fdobridge: <a​irlied> given it a run on kepler?
03:51 fdobridge: <S​id> will test on Turing prime ASAP
04:02 fdobridge: <g​fxstrand> I'm also reasonably happy with the compromise of smashing PTE kinds and tile modes into the BO for dedicated allocations. It's pretty non-invasive and should fix the GL problem.
04:03 fdobridge: <g​fxstrand> That's on the ToDo list for tomorrow
04:03 fdobridge: <g​fxstrand> It's good to test with prime but prime hopefully won't be hitting those paths.
04:04 fdobridge: <a​irlied> do we need to have a uapi signal to know when to use those paths?
04:05 fdobridge: <g​fxstrand> I just try to allocate a tiled BO at physical device enumeration time and only enable modifiers if that succeeds.
04:05 fdobridge: <g​fxstrand> If you'd rather have a feature bit, I'd be happy with that, too.
04:05 fdobridge: <a​irlied> ah cool, if that works it's probably just as efficient
04:06 fdobridge: <g​fxstrand> Yeah, it's a single 64k allocation. It's not going to kill our startup time
04:06 fdobridge: <a​irlied> yeah the ioctl overhead of calling a getparam won't be much different
04:07 fdobridge: <g​fxstrand> And if we backport the patch, it's a temporary measure anyway
04:07 fdobridge: <g​fxstrand> Oh, right, for those wanting to test, you'll need my updated NVK kernel branch
04:09 fdobridge: <S​id> I shall test mobile turning nvidia-only too then :3
04:10 fdobridge: <g​fxstrand> I may even play with some more entertaining combos tomorrow like Ampere + Turing and Pascal + Kepler.
04:10 fdobridge: <g​fxstrand> Those are totally gonna work, right? 😅
04:13 fdobridge: <S​id> only one way to find out
04:13 fdobridge: <S​id> :wolfFIRE:
04:53 fdobridge: <S​id> does GA107 not have GSP firmware right now? in nouveau?
04:56 fdobridge: <S​id> hm, my system says it does
05:05 fdobridge: <S​id> oh, void apparently isn't packaging GSP
05:05 fdobridge: <S​id> and Ampere mobile is not falling back to the non-GSP path
05:05 fdobridge: <S​id> or if it is, something else is blowing up
05:05 fdobridge: <S​id> @clangcat can tell more
05:08 fdobridge: <c​langcat> :P my system doesn't have the funny files.
05:08 fdobridge: <c​langcat> am trying to see if they put it in a seperate package first
05:08 fdobridge: <m​arysaka> I am on ga107 and it works fine on Fedora at least here
05:08 fdobridge: <S​id> yes that's what I found out as well
05:09 fdobridge: <S​id> ^ mary
05:09 fdobridge: <c​langcat> This is almost certainly void not packaging(perhaps out of protest) or putting it in a separate package.
05:09 fdobridge: <c​langcat> just trying to see which it is first
05:11 fdobridge: <c​langcat> @tiredchiku what is the firmaware files name for GSP at ga107?
05:11 fdobridge: <c​langcat> gonna search them to see if they packaged anywhere
05:11 fdobridge: <S​id> I already DMd them
05:13 fdobridge: <c​langcat> Hmm interesting seems like void doesn't symlink it but I also don't have ga102
05:13 fdobridge: <c​langcat> https://cdn.discordapp.com/attachments/1034184951790305330/1235821467300794398/grafik.png?ex=6635c3ee&is=6634726e&hm=ecc5994f680b7a72e30f3ec6e1eb8c2da5e23703faee3cd6747e82d6daa3e0dd&
05:13 fdobridge: <c​langcat> I think
05:13 fdobridge: <c​langcat> imma just force reinstall then symlink it
05:14 fdobridge: <S​id> I see 102 tho
05:14 fdobridge: <S​id> ga102 I mean
05:14 fdobridge: <S​id> third line in that screenshot
05:14 fdobridge: <c​langcat> wait force reinstalling fixed it.
05:14 fdobridge: <c​langcat> https://cdn.discordapp.com/attachments/1034184951790305330/1235821833014743102/grafik.png?ex=6635c445&is=663472c5&hm=ab820c4316e23a8994b25e641dd2312c107d872084bcbe50bf6893334413c6cf&
05:14 fdobridge: <S​id> ya goober, get some sleep
05:15 fdobridge: <S​id> weird
05:15 fdobridge: <S​id> wait why
05:15 fdobridge: <c​langcat> Uhhh welp guess I just reboot now
05:15 fdobridge: <S​id> what
05:15 fdobridge: <S​id> nvidia-firmware, that's
05:15 fdobridge: <S​id> that's the firmware for the current proprietary module
05:15 fdobridge: <S​id> proprietary/openrm
05:16 fdobridge: <S​id> but it fixed symlinks on linux-firmware-nvidia?
05:16 fdobridge: <S​id> wtf void linux
05:16 fdobridge: <S​id> tl;dr 535.113 firmware is part of linux-firmware, which is what nouveau uses
05:17 fdobridge: <S​id> that nvidia-firmware package you just force installed is 550.78, which is the current prop/openrm driver version
05:17 fdobridge: <S​id> but apparently that fixed the symlinks so what do I know
05:17 fdobridge: <r​edsheep> Ooo just seeing this, I will have to get testing this. I really really really hope this gets zink sessions running well, I feel like that's going to be much more ideal than nvc0 at the moment.
05:18 fdobridge: <r​edsheep> Performance might not be the idea either but I think quite a bit of my performance and stutter feels like it's in the display server so I am hoping for some big wins
05:18 fdobridge: <c​langcat> Well I have also reinstalled linux-firmware-nvidia.
05:19 fdobridge: <c​langcat> I've done both just to uhhh hope
05:19 fdobridge: <S​id> ah
05:19 fdobridge: <c​langcat> anyway brb
05:19 fdobridge: <S​id> that makes more sense
05:22 fdobridge: <c​langcat> @tiredchiku it still crashes with the same error
05:22 fdobridge: <c​langcat> :Foxy_Dead:
05:22 fdobridge: <r​edsheep> Is this the kernel to use? https://gitlab.freedesktop.org/gfxstrand/linux/-/tree/nvk?ref_type=heads
05:22 fdobridge: <c​langcat> No just 6.8 mainline
05:22 fdobridge: <S​id> cat he's asking about the kernel to use with modifiers MR
05:22 fdobridge: <r​edsheep> https://discord.com/channels/1033216351990456371/1034184951790305330/1235804971023466508
05:23 fdobridge: <S​id> I'm at a loss then
05:23 fdobridge: <c​langcat> Guess I can give it a go. Worst case it still doesn't boot.
05:23 fdobridge: <S​id> this is with you have the firmware actually installed correctly and GSP enabled with the commandline option, yeah?
05:23 fdobridge: <c​langcat> Although I am not trying to use Nvk persay
05:24 fdobridge: <r​edsheep> You're not?
05:24 fdobridge: <r​edsheep> Why mess with 535 firmware then?
05:25 fdobridge: <c​langcat> Yes the one Mary told me about
05:25 fdobridge: <c​langcat> ```
05:25 fdobridge: <c​langcat> [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.8.8_1 root=UUID=07446cd1-9d60-4ca3-8562-e82720d73d79 ro modprobe.blacklist=nouveau loglevel=4 module_blacklist=nvidia nouveau.config=NvGspRm=1 quiet splash
05:25 fdobridge: <c​langcat> ```
05:25 fdobridge: <c​langcat> my kernel cmd line
05:25 fdobridge: <c​langcat> Because I am just trying to get Nouveau to work
05:25 fdobridge: <S​id> the kernel module
05:25 fdobridge: <c​langcat> Like I like the idea of Nouveau and I want to use an open source module if I can.
05:26 fdobridge: <c​langcat> But it's struggling. As Gsp is failing which I don't even care about but. it doesn't fall back to a non GSP version of the driver and just crashes
05:26 fdobridge: <S​id> the kmod is crashing on her system with or without GSP enabled
05:26 fdobridge: <S​id> void linux
05:26 fdobridge: <c​langcat> Mhmmmm
05:27 fdobridge: <c​langcat> do I have a USB round here
05:27 fdobridge: <c​langcat> Gonna flash idk Arch just to see if it crashes
05:29 fdobridge: <c​langcat> oh even more perfect it's the same kernel version
05:29 fdobridge: <c​langcat> https://cdn.discordapp.com/attachments/1034184951790305330/1235825536740364308/grafik.png?ex=6635c7b8&is=66347638&hm=148e40b413fa768892499889e7d78fb338e2c066e33d33a3882c29d57f167143&
05:32 fdobridge: <!​DodoNVK (she) 🇱🇹> How about Kosovo?
05:33 fdobridge: <r​edsheep> So I have just looked through the convo more carefully, you're saying that a release kernel with no special parameters, not even gsp, and the regular ol void linux package for linux-firmware is crashing? That's really weird
05:34 fdobridge: <r​edsheep> That should be like... the most well tested configuration possible
05:34 fdobridge: <c​langcat> I can't tell if you being sarcastic.
05:35 fdobridge: <c​langcat> Anyway
05:35 fdobridge: <r​edsheep> No sarcasm
05:35 fdobridge: <c​langcat> Gonna test arch iso it's the same kernel version
05:35 fdobridge: <c​langcat> and in theroy it should also crash
05:35 fdobridge: <c​langcat> in theroy
05:35 fdobridge: <a​irlied> pre GSP ampere doesn't always initialise properly
05:40 fdobridge: <c​langcat> Any suggestions on what I can do to fix it? Worth noting it is also a laptop version of the 3050.
05:41 fdobridge: <c​langcat> But Arch boots.
05:41 fdobridge: <r​edsheep> Using gsp would avoid what he's referring to but you were already testign that on void
05:41 fdobridge: <r​edsheep> Did the arch iso use gsp?
05:42 fdobridge: <c​langcat> Yea it loaded ga107 gsp fine.
05:42 fdobridge: <c​langcat> @airlied do you happen to know if the firmware needs to be on certain partition type or filesystem
05:43 fdobridge: <c​langcat> Because all I can think of right now is that my root is XFS.
05:43 fdobridge: <r​edsheep> I know in my case my working configuration has gsp inside my ext4 /boot partition
05:44 fdobridge: <S​id> I've used EXT4 root, btrfs root, amd xfs root just fine
05:44 fdobridge: <c​langcat> Though I suppose that's a question of maybe if the XFS driver is loading after Nouveau. Although I would think it would have to be loaded as the Nouveau kernel module is located on the xfs partition.
05:45 fdobridge: <S​id> not necessarily
05:45 fdobridge: <S​id> initrd could be loading nouveau before xfs
05:45 fdobridge: <c​langcat> It's not though as I have Nouveau blacklisted on boot and am manually starting it with modprobe
05:45 fdobridge: <S​id> ah
05:46 fdobridge: <c​langcat> Here's the dmesg if anyone wants to read it cmdline is at the top and nouveau is right at the bottom
05:46 fdobridge: <c​langcat> https://cdn.discordapp.com/attachments/1034184951790305330/1235829823566254110/log?ex=6635cbb6&is=66347a36&hm=5758e225c3ca434f759d07d9ec63e76b02e4227b9b03a1b3544531c7ec52e8ca&
05:46 fdobridge: <r​edsheep> Sid you were saying you were able to modprobe up nouveau to switch modules back and forth without reboot right?
05:48 fdobridge: <c​langcat> Man all this cause I wanted to test my code on Nouveau
05:48 fdobridge: <c​langcat> that was 3 hours ago :(
05:48 fdobridge: <S​id> yes, but only if I had modesetting disabled
05:48 fdobridge: <S​id> ya goober you could just
05:48 fdobridge: <S​id> give it to me
05:48 fdobridge: <c​langcat> Yes
05:48 fdobridge: <S​id> I've tested your code before too
05:49 fdobridge: <c​langcat> but I don't want to have get someone else to test my code for me all the time
05:49 fdobridge: <c​langcat> I'd like to be able to atleast run Nouveau
05:49 fdobridge: <c​langcat> I don't care if it has GSP or not.
05:50 fdobridge: <r​edsheep> GSP is the better place to be, IIUC at this point it should work better in addition to being faster, even just with opengl
05:51 fdobridge: <r​edsheep> (generally)
05:51 fdobridge: <S​id> it could also be void's kernel doing something goofy
05:51 fdobridge: <c​langcat> Yea I don't really care about speed though. I just care about knowing "oh my code works"
05:51 fdobridge: <c​langcat> Yea it could be
05:51 fdobridge: <c​langcat> Cause I am not sure whatelse it can be at this point
05:52 fdobridge: <S​id> you can always send me stuff to do, I don't mind
05:52 fdobridge: <S​id> :myy_winkKawaii:
05:52 fdobridge: <c​langcat> Yea but I wanna be able to test stuff locally you know
05:52 fdobridge: <r​edsheep> Testing locally is nice. Have you tested with modesetting off?
05:53 fdobridge: <S​id> issue seems to be with the gpu initialization
05:53 fdobridge: <S​id> so modesetting won't change anything
05:53 fdobridge: <c​langcat> Yea it's not even getting to modesetting is the thing
05:53 fdobridge: <r​edsheep> Ah.
05:53 fdobridge: <S​id> actually... do you have any PCI power management rules set on void?
05:54 fdobridge: <S​id> via udev or something
05:54 fdobridge: <S​id> I know they broke rebar for me because the GPU did PCIe ASPM before the driver probed the device for BAR size, and defaulted to small BAR
05:55 fdobridge: <c​langcat> Nope just look through them.
05:56 fdobridge: <a​irlied> turn off CONFIG_SG_DEBUG or grab Lyude's patches to fix that
05:57 fdobridge: <c​langcat> Okay sure I'll get test once kernel compile is done.
05:58 fdobridge: <a​irlied> CONFIG_DEBUG_SG might be the one
06:01 fdobridge: <S​id> how is that affecting firmware load? /gen
06:02 fdobridge: <c​langcat> I mean all the same I am just configuring the kernel build for this. gotta make sure to turn this on
06:02 fdobridge: <c​langcat> https://cdn.discordapp.com/attachments/1034184951790305330/1235833914736513024/grafik.png?ex=6635cf85&is=66347e05&hm=4f0e565a455af8d19532be5d555f1824af75599846fb4914f7f635008cfd86a7&
06:03 fdobridge: <c​langcat> And turn off all the drivers I don't need like Stinky Matrox G200 module
06:03 fdobridge: <i​509vcb> do a bunch of stuff like use the mouse, plug in external drives, use wifi/ethernet, etc and generate a local config,
06:04 fdobridge: <i​509vcb> it will build far faster
06:04 fdobridge: <r​edsheep> I saved quite a bit of time by just not building amdgpu
06:05 fdobridge: <c​langcat> Yes but amd is my only fallback if Nouveau fails
06:05 fdobridge: <a​irlied> the fw loading code has a bug, the debug setting finds it
06:05 fdobridge: <c​langcat> `sg_init_one` I assume
06:05 fdobridge: <c​langcat> I may have poked around Nouveaus code.
06:05 fdobridge: <S​id> interesting
06:06 fdobridge: <a​irlied> https://patchwork.freedesktop.org/patch/591858/?series=132966&rev=2
06:06 fdobridge: <S​id> yup
06:06 fdobridge: <S​id> that is it
06:07 fdobridge: <c​langcat> Yea that is what's breaking
06:07 fdobridge: <S​id> it should be in 6.9 then, yeah?
06:09 fdobridge: <a​irlied> gonna need to tag it for 6.8 once it lands in Linus tree
06:09 fdobridge: <S​id> sweet
06:09 fdobridge: <c​langcat> I was gonna offer to try and fix it. But neat it's already being fixed.
06:09 fdobridge: <S​id> so cat will soon not have to compile her own kernel on void
06:09 fdobridge: <c​langcat> I was just trying to 100% make sure it was the driver
06:10 fdobridge: <c​langcat> and not just me being dumb
06:10 fdobridge: <c​langcat> Ehhhh welll
06:10 fdobridge: <c​langcat> you see
06:10 fdobridge: <c​langcat> void is still on 6.6 by default
06:10 fdobridge: <c​langcat> I had to go out of my way to install 6.8
06:10 fdobridge: <S​id> yeah but you can install 6.8.8 via the packages
06:10 fdobridge: <S​id> so
06:11 fdobridge: <c​langcat> Yea
06:11 fdobridge: <S​id> it's still easier than building your own
06:11 fdobridge: <c​langcat> Yea that's certainly true
06:11 fdobridge: <c​langcat> and I hope I compressed it correctly
06:11 fdobridge: <c​langcat> otherwise this is gonna be big
06:12 fdobridge: <c​langcat> that's something I remember about custom kernels they can easily be massive if you don't do them right.
06:12 fdobridge: <c​langcat> Though did turn off all non Amd/Nvidia gpu drivers cause no reason to build any others really
06:14 fdobridge: <S​id> mhm
06:15 fdobridge: <c​langcat> But it has been like a year since I built my own custom kernel so hopefully I remember what I am doing.
06:15 fdobridge: <c​langcat> Allthough if it ends up being chunky I can just fix it later.
06:16 fdobridge: <c​langcat> It's okay atleast it's not LLVM
06:16 fdobridge: <c​langcat> https://cdn.discordapp.com/attachments/1034184951790305330/1235837366485254166/grafik.png?ex=6635d2bc&is=6634813c&hm=59c561f83b88f1ae86437c17aeefc6af055d1a01f7ed13c67b8cde2eab1c4e6d&
06:16 fdobridge: <c​langcat> if it was LLVM I would be having OOM issues
06:50 fdobridge: <!​DodoNVK (she) 🇱🇹> Could nouveau cause `sync_file` leaks in KWin? 🍩
06:55 fdobridge: <c​langcat> @airlied thank you the patch from Lyude fixed my GPU.
06:55 fdobridge: <c​langcat> :D
06:56 fdobridge: <c​langcat> Well uhhh actually should probably test it "works" but it doesn't crash
06:56 fdobridge: <c​langcat> so
06:56 fdobridge: <c​langcat> awesome
07:17 fdobridge: <a​irlied> @gfxstrand https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29032 just wanted to get it started after talking to Ben before, just running through CTS here, but I'm gonna guess it will have some issues
07:22 fdobridge: <m​arysaka> hmm for async graphics queue doesn't that need some fancy unknown magic around?
07:24 fdobridge: <m​arysaka> I think I saw some magic values being set around `SET_SCG_GRAPHICS_SCHEDULING_PARAMETERS` and `SET_SCG_COMPUTE_SCHEDULING_PARAMETERS` depending of the queue
07:34 fdobridge: <a​huillet> somebody called me? :)
07:34 fdobridge: <a​huillet> I wanted to type "magic is my middle name" but it felt a bit too much.
07:36 fdobridge: <m​arysaka> So from the little I gathered some time ago, SCG (Simultaneous Compute and Graphics) = Async Compute (can be found on Ampere white paper)
07:36 fdobridge: <a​huillet> yes
07:36 fdobridge: <m​arysaka> And this thing appears to control the partitioning of SM in some way :aki_thonk:
07:37 fdobridge: <m​arysaka> So I suppose the values set in the compute async queue change priority of stuffs maybe
07:37 fdobridge: <k​arolherbst🐧🦀> yeah.. that would actually make sense
07:37 fdobridge: <a​huillet> try 0x10
07:38 fdobridge: <a​huillet> I would not worry too much about that particular method, at first glance it's setting some thresholds for heuristics, nothing needed for correct operation
07:38 fdobridge: <a​huillet> I would not worry too much about that particular method, at first glance it's setting some thresholds for heuristics, nothing needed for correct operation of SCG (edited)
07:39 fdobridge: <a​huillet> ~~try 0x10~~ignore that (edited)
07:52 fdobridge: <!​DodoNVK (she) 🇱🇹> Does Maxwell v2 support it?
07:54 fdobridge: <a​irlied> @mohamexiety this is just a transfer queue
07:54 fdobridge: <a​irlied> async compute is a whole other set of fun
07:54 fdobridge: <a​irlied> but I think there are apps that could use transfer queues now
07:56 fdobridge: <k​arolherbst🐧🦀> wouldn't the idea of transfer queues be to either use async dma-copy functionality or async compute if the transfer is ran in a compute shader?
07:58 fdobridge: <k​arolherbst🐧🦀> but yeah.. maybe submitting them as different things is already good enough
08:00 fdobridge: <r​edsheep> Back in the maxwell/pascal era I remember lots of discussion where the gist of it was one or both of them exposed it but didn't tend to benefit
08:00 fdobridge: <!​DodoNVK (she) 🇱🇹> Will extra queues increase NVK performance?
08:01 fdobridge: <c​langcat> Well it works now but gsp mmu fault
08:01 fdobridge: <c​langcat> ```
08:01 fdobridge: <c​langcat> [ 710.717578] nouveau 0000:01:00.0: gsp: mmu fault queued
08:01 fdobridge: <c​langcat> [ 710.720548] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:16 type:31 scope:1 part:233
08:01 fdobridge: <c​langcat> [ 710.720557] nouveau 0000:01:00.0: fifo:c00000:0002:0010:[sway[3759]] errored - disabling channel
08:01 fdobridge: <c​langcat> [ 710.720563] nouveau 0000:01:00.0: sway[3759]: channel 16 killed!
08:01 fdobridge: <c​langcat> [ 710.731902] sway[3759]: segfault at 559000000000 ip 00007f5f4957d13e sp 00007fff88a906e0 error 4 in libdrm_nouveau.so.2.0.0[7f5f4957c000+5000] likely on CPU 8 (core 4, socket 0)
08:01 fdobridge: <c​langcat> ```
08:01 fdobridge: <S​id> is that sway with the vulkan renderer
08:01 fdobridge: <S​id> or is it the old opengl drive
08:01 fdobridge: <S​id> driver*
08:01 fdobridge: <S​id> or are you using zink
08:01 fdobridge: <r​edsheep> What version of mesa?
08:01 fdobridge: <c​langcat> Opengl but it's a gsp mmu fault.
08:01 fdobridge: <r​edsheep> I think some older versions had more of these end up getting kicked up
08:02 fdobridge: <S​id> gsp complains about userspace faults
08:02 fdobridge: <c​langcat> mesa-24.0.5_1
08:02 fdobridge: <S​id> and opengl driver is technically unsupported now
08:02 fdobridge: <c​langcat> Oh cursed
08:03 fdobridge: <S​id> unsure, it might help in programs that actually use multiple queues for parallelization
08:03 fdobridge: <r​edsheep> I haven't tested yet but running sway on zink on mesa from Faith's MR and kernel is probably best, if it works at all
08:03 fdobridge: <S​id> though the first thing we need to do is figure out how to have separate compute-only and GFX-only queues
08:03 fdobridge: <c​langcat> It might help but yea programs have to put in the effort
08:03 fdobridge: <S​id> why not sway with the vulkan renderer
08:04 fdobridge: <c​langcat> Yea I just need to apply Lyude's patch to Faiths kernel.
08:04 fdobridge: <c​langcat> Assuming faith hasn't already
08:05 fdobridge: <S​id> oh wait
08:05 fdobridge: <r​edsheep> Didn't know it had one. Yeah, that then. But also, set /etc/environment to set zink should be good regardless, if it works
08:05 fdobridge: <S​id> WLR_RENDERER=vulkan required drm modifiers
08:05 fdobridge: <r​edsheep> Yeah so use modifiers branch, and probably zink. Except... is the idea with this MR that modifiers should work between nvk and nvc0?
08:06 fdobridge: <r​edsheep> This reads like it should https://discord.com/channels/1033216351990456371/1034184951790305330/1235803766834462791
08:06 fdobridge: <S​id> :revshrug:
08:20 fdobridge: <j​oobei> Guys today is a milestone in my life. I was finally able to play my favorite game on GNU/Linux. I am ecstatic 🙂 This is from steam hardware info, does this mean that my system is running mesa/nouveau? (edited)
08:20 fdobridge: <j​oobei> https://cdn.discordapp.com/attachments/1034184951790305330/1235711184230027264/image.png?ex=66355d38&is=66340bb8&hm=7bbe2a575cec5c0dbf188ac08fe509dd5120fb9711f92d1776a22c617c0236c5&
08:21 fdobridge: <j​oobei> Steam asks that you install a 32-bit driver so I went ahead and did that just to be safe.
08:22 fdobridge: <j​oobei> Ah so despite Steam's HWinfo reporting "Mesa" when the game runs it might be using Nvidia blob? I see.
08:30 fdobridge: <m​ohamexiety> there's a getparam for the change in v2 of the kernel patch but not sure if that's what you mean
08:31 fdobridge: <m​agic_rb.> No, steam is only running using software rendering according to that screenshot you sent
08:31 fdobridge: <m​agic_rb.> So its running the opengl/vulkan code on the cpu fully
08:35 fdobridge: <m​ohamexiety> have to go for something in a bit but will be re-testing with gamescope and seeing how it works
08:41 fdobridge: <j​oobei> Ah so despite Steam's HWinfo reporting "Mesa", when the game runs it might be using Nvidia blob? I see. (edited)
08:42 fdobridge: <j​oobei> If Steam is using the software renderer then so is everything else in my system? No way I'm getting this awesome performance with a software renderer. Anyway I am a bit of a mesa/driver noob so I guess that's why I don't understand it.
08:42 fdobridge: <S​id> it's not easy to say
08:42 fdobridge: <S​id> steam only really picks the first driver it finds
08:43 fdobridge: <S​id> the hardware info, that is
08:43 fdobridge: <m​agic_rb.> Steam is 32 bit, most other things are 64bit its yes, it can be that 32bit is only software
08:43 fdobridge: <m​agic_rb.> Steam is 32 bit, most other things are 64bit, so yes, it can be that 32bit is only software (edited)
08:44 fdobridge: <m​agic_rb.> Run `vulkaninfo` and in that output itll list known drivers/gpus, so you can figure it out from there
08:45 fdobridge: <S​id> use `vulkaninfo --summary`
13:42 fdobridge: <m​ohamexiety> :thonk:
13:42 fdobridge: <m​ohamexiety> ```
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34325241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34325241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34325258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34325258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34324241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34324241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34324258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x34324258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x36314752 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x3231564E (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x48344241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x48344258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x38344241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x38344258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x30334241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x30334258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x30335241 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x30335258 (VkResult: 0)
13:42 fdobridge: <m​ohamexiety> ```
13:42 fdobridge: <m​ohamexiety> let's dig in
14:15 fdobridge: <g​fxstrand> Probably
14:16 fdobridge: <g​fxstrand> What patch is that? I'm happy to pull stuff in if it helps folks
14:16 fdobridge: <S​id> https://patchwork.freedesktop.org/patch/591858/?series=132966&rev=2
14:18 fdobridge: <g​fxstrand> Uh... That's fun... I was afraid we might hit something like that
14:59 fdobridge: <z​mike.> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29041 should fix this
15:28 fdobridge: <g​fxstrand> Ugh... Why doesn't gears find a device...
15:37 fdobridge: <g​fxstrand> Hrm... explicit sync blows up
15:37 fdobridge: <g​fxstrand> Something else to debug, I guess
15:38 fdobridge: <!​DodoNVK (she) 🇱🇹> That's ironic because NVIDIA driver really likes explicit sync
16:00 fdobridge: <g​fxstrand> Okay, modifiers is now doing WSI now. Linear render even works. Thanks, @mohamexiety
16:00 fdobridge: <g​fxstrand> I had to fix it up a bit but it's working now
16:02 fdobridge: <m​ohamexiety> yep, it works! \o/
16:02 fdobridge: <m​ohamexiety> https://cdn.discordapp.com/attachments/1034184951790305330/1235984808363167754/image.png?ex=66365c0d&is=66350a8d&hm=6d2ec6d599592f8ca1c58c4891a2ebbfe3dd8ab271a7218600836c1438de989d&
16:13 fdobridge: <g​fxstrand> Still working out kinks
16:52 fdobridge: <g​fxstrand> Ugh... my computer hates me...
16:53 fdobridge: <g​fxstrand> One of my GPUs keeps going down mid-CTS-run
17:05 fdobridge: <h​untercz122> better than proprietary drivers already? o.o
17:58 fdobridge: <g​fxstrand> Does the tile mode end up in the page tables anywhere or just kind?
18:09 fdobridge: <g​fxstrand> Ugh... VM_BINDing all images is making hash of my CTS times. 😭
20:56 fdobridge: <g​fxstrand> I wonder if ESO hosed Kepler...
21:37 fdobridge: <g​fxstrand> I wonder if Maxwell is equally hosed..
21:38 fdobridge: <g​fxstrand> Pascal is fine
21:45 fdobridge: <m​ohamexiety> I can test Pascal. Maxwell B (GTX 9xx) is _probably_ safe to assume to be same as Pascal. Maxwell A though (GTX 750/750Ti) is unknown
21:48 fdobridge: <g​fxstrand> Well, now I have a fail on Pascal
22:18 fdobridge: <g​fxstrand> I should try Turing+Ampere and see if that works
22:41 fdobridge: <g​fxstrand> Yeah, Turing+Ampere doesn't work, either. That's actually good news in a way. This might be a repro for the horrible MMU faults we've been fighting.
22:47 fdobridge: <g​fxstrand> @airlied I'm seeing faults when using modifiers on BOs which are shared with other GPUs. If you run the modifiers MR with the compositor on one GPU and the app on the other, it faults instantly.
22:48 fdobridge: <g​fxstrand> The only thing the modifier controls is PTE kind and tiling and I verify the PTE kind is what NIL would have used anyway so it's really just tiling. Even that's no different from what we normally use.
22:49 fdobridge: <g​fxstrand> So the only thing that makes sense to me is that forcing it into system ram breaks stuff.
22:53 fdobridge: <g​fxstrand> I should try Ampere+Ampere
23:03 fdobridge: <g​fxstrand> Yeah, I can repro with Ampere+Ampere. In that case, literally no different code paths are taken in userspace when I switch GPUs but the one that ends up putting the BO in system RAM faults.
23:03 fdobridge: <g​fxstrand> I think that makes it @airlied 's problem. 🙂
23:04 fdobridge: <g​fxstrand> If it really is a system RAM vs. VRAM issue, that could explain some of the faults we've seen.
23:04 fdobridge: <g​fxstrand> That's a good way to wrap up my Friday, I think. Talk to y'all later!
23:06 fdobridge: <m​ohamexiety> good find. nice work and have a good weekend o/
23:43 Lyude: [455099.846697] nouveau 0000:01:00.0: gsp: intr 00008000 ← huh. everything seems fine, wonder where that came from