00:15 fdobridge_: <k​arolherbst🐧🦀> yeah, it's just an add
00:15 fdobridge_: <k​arolherbst🐧🦀> tbose mods on imad are purely declarative
00:15 fdobridge_: <m​arysaka> What does that LEA do here? :aki_thonk:
00:16 fdobridge_: <k​arolherbst🐧🦀> that `IMAD.SHL` is still just R6 * 0x4, just used instead of an actual shift
00:16 fdobridge_: <k​arolherbst🐧🦀> LEA.HI.SX32 is the weird one.. wiat a sec
00:17 fdobridge_: <k​arolherbst🐧🦀> sooo
00:18 fdobridge_: <k​arolherbst🐧🦀> @gfxstrand `.SX32` means the input in src2 has the sign of src0
00:18 fdobridge_: <k​arolherbst🐧🦀> I think...
00:18 fdobridge_: <k​arolherbst🐧🦀> or the other way around?
00:19 fdobridge_: <m​arysaka> what does LEA do in general?
00:20 fdobridge_: <k​arolherbst🐧🦀> shift and add
00:20 fdobridge_: <k​arolherbst🐧🦀> but funky
00:24 fdobridge_: <k​arolherbst🐧🦀> `LEA.HI.SX32 R4, R0, R5, 0x1e` should be... `R4 = (R0 >> (32 - 0x1e)) + R5`...
00:24 fdobridge_: <k​arolherbst🐧🦀> just R0 is sign extended in a weirdo way
00:25 fdobridge_: <k​arolherbst🐧🦀> but anyway
00:25 fdobridge_: <k​arolherbst🐧🦀> it has a 5 bit shift constant (last source)
00:25 fdobridge_: <k​arolherbst🐧🦀> the src0 is the base value and src1 gets added
00:25 fdobridge_: <k​arolherbst🐧🦀> src2 is zero here
00:26 fdobridge_: <k​arolherbst🐧🦀> src2 only really exists for `.HI` (without `.SX32`)
00:28 fdobridge_: <k​arolherbst🐧🦀> `LEA.HI(.X) d a b c shift` is basically `d = ({c, a} >> (32 - shift)) + b + carry`
00:28 fdobridge_: <k​arolherbst🐧🦀> `LEA.LO d a b 0 shift` is `d = (a << shift) + b`
00:29 fdobridge_: <k​arolherbst🐧🦀> and `.SX` means that `c` becomes the sign of `a` in the `.HI` variant
00:29 fdobridge_: <k​arolherbst🐧🦀> @gfxstrand ^^ that's basically it
05:05 mupuf: Lyude: heya! I indeed still have plenty of GPUs
05:05 mupuf: Not too sure about Kepler though, but I may be able to get one in exchange of a GTX 1060 that I am about to offer to my nephew to replace his K2000
05:18 fdobridge_: <a​irlied> uggh this race on the fences feels like an atomic that is tryiung to be a lock problem
12:53 fdobridge_: <S​id> do we support rebar on nouveau yet?
12:54 fdobridge_: <S​id> ah
12:55 fdobridge_: <S​id> karol maybe you need to mod your uefi firmware like I did :frog_gears:
12:55 fdobridge_: <k​arolherbst🐧🦀> probably
12:55 fdobridge_: <k​arolherbst🐧🦀> but the machine is technically not mine, so I'd rather not break it 😄
12:55 fdobridge_: <k​arolherbst🐧🦀> but
12:55 fdobridge_: <k​arolherbst🐧🦀> my firmware does support rebar properly
12:55 fdobridge_: <k​arolherbst🐧🦀> it just doesn't work with the nvidia GPUs here
12:55 fdobridge_: <k​arolherbst🐧🦀> no issues on AMD
12:56 fdobridge_: <S​id> right, because nvidia vbios blocker
12:56 fdobridge_: <k​arolherbst🐧🦀> yeah
12:56 fdobridge_: <k​arolherbst🐧🦀> but that's the part we might be able to just workaround kernel side
12:56 fdobridge_: <k​arolherbst🐧🦀> I'd rather have users set some kernel parameter than flashing their vbios in weird ways
12:56 fdobridge_: <S​id> which can be worked around by hardcoding the location of the pci bus into the uefi firmware
12:57 fdobridge_: <S​id> no vbios patching involved
12:57 fdobridge_: <S​id> I mean, rebar on turing is not something most people think about
12:57 fdobridge_: <S​id> but it might be helpful to patch it in on your system to facilitate developing fori t
12:57 fdobridge_: <S​id> but it might be helpful to patch it in on your system to facilitate developing for rebar (edited)
12:58 fdobridge_: <S​id> sure, turing needs weird flashing for rebar, but ampere and ada don't 😅
12:59 fdobridge_: <S​id> would be nice to figure out turing via the kernel, but until then I think we should get it working on systems that do support it
12:59 fdobridge_: <k​arolherbst🐧🦀> yeah..
13:02 fdobridge_: <S​id> I think it's more of a pci driver thing than a nouveau thing anyway? on the kernel I mean
13:03 fdobridge_: <S​id> or does the pci driver and nouveau have to agree on the bar size
13:04 fdobridge_: <S​id> hmm
13:04 fdobridge_: <S​id> https://github.com/torvalds/linux/blob/master/drivers/pci/pci.c#L3817-#L3836
13:05 fdobridge_: <k​arolherbst🐧🦀> yeah.. it's part of pci, but nouveau might have to enable rebar on the GPU
13:05 fdobridge_: <S​id> right, makes sense
13:05 fdobridge_: <k​arolherbst🐧🦀> @tiredchiku do those GPU boot with rebar support enabled?
13:05 fdobridge_: <S​id> which ones
13:05 fdobridge_: <k​arolherbst🐧🦀> like.. are the bars bigger than 256MB before nvidia loads?
13:05 fdobridge_: <S​id> oh, uh
13:05 fdobridge_: <S​id> no idea
13:06 fdobridge_: <S​id> hang on, let me check my dmesg
13:06 fdobridge_: <k​arolherbst🐧🦀> because if it's not and the driver needs to do something, we might be able to `mmiotrace` the binary driver and see what they do with the PCI subsystem on the GPU
13:07 fdobridge_: <S​id> I know for a fact that right now I have rebar working only on the proprietary driver (open kernel module)
13:07 fdobridge_: <S​id> I haven't tried proprietary kernel module, and it gives me 256mb bar even on nouveau
13:07 fdobridge_: <k​arolherbst🐧🦀> right
13:08 fdobridge_: <k​arolherbst🐧🦀> that's why I mean we probably need to do some kernel stuff to enable it on certain GPUs
13:08 fdobridge_: <S​id> if you wanna take a look at my dmesg yourself
13:08 fdobridge_: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1200064650818109450/dmesg.log?ex=65c4d24c&is=65b25d4c&hm=490e353a63b2831ebd328ac1fde1672365f0ced9d8df64256e4cbda09fcecadc&
13:09 fdobridge_: <S​id> 8gb region assigned to my gpu here
13:09 fdobridge_: <S​id> `[Thu Jan 25 18:17:30 2024] pci 0000:01:00.0: BAR 1: assigned [mem 0x4200000000-0x43ffffffff 64bit pref]`
13:09 fdobridge_: <S​id> same dmesg without the -T flag
13:09 fdobridge_: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1200064942863286303/dmesg.log?ex=65c4d292&is=65b25d92&hm=a5c9d7937bb79b82aa871c696fb770983ea3627e007404e856392e534b9deb32&
13:09 fdobridge_: <S​id> `[ 0.336264] pci 0000:01:00.0: BAR 1: assigned [mem 0x4200000000-0x43ffffffff 64bit pref]`
13:11 fdobridge_: <S​id> looks like bar is assigned by the pci driver before the initramfs is run
13:11 fdobridge_: <k​arolherbst🐧🦀> mhhh...
13:11 fdobridge_: <S​id> `[ 0.890865] Run /init as init process`
13:12 fdobridge_: <S​id> this matches what I nee on nouveau
13:12 fdobridge_: <S​id> the region is assigned correctly
13:12 fdobridge_: <S​id> https://paste.sidonthe.net/raw/otter-goat-cat but the available bar sizes aren't advertised correctly
13:12 fdobridge_: <S​id> s\/nee/see
13:14 fdobridge_: <S​id> are we allowed to look at what the open kernel module does? 🙃
13:14 fdobridge_: <k​arolherbst🐧🦀> sure
13:14 fdobridge_: <S​id> https://github.com/NVIDIA/open-gpu-kernel-modules/blob/bb2dac1f20a06f78e028c4acdc4df1c7908dd91c/kernel-open/nvidia/nv-pci.c#L180-L#204
13:14 fdobridge_: <k​arolherbst🐧🦀> yeah.. that's a weird one
13:15 fdobridge_: <k​arolherbst🐧🦀> is the `Capabilities: [bb0 v1] Physical Resizable BAR` part different on nvidia?
13:15 fdobridge_: <k​arolherbst🐧🦀> and does it change between boot and loading nvidia?
13:16 fdobridge_: <S​id> yup
13:16 fdobridge_: <S​id> https://paste.sidonthe.net/raw/snail-toad-monkey
13:16 fdobridge_: <k​arolherbst🐧🦀> okay!
13:16 fdobridge_: <S​id> let me check
13:18 fdobridge_: <k​arolherbst🐧🦀> I suspect it needs some reg writes into the `0x8c000` space
13:18 fdobridge_: <k​arolherbst🐧🦀> we never got the headers for that, but...
13:21 fdobridge_: <k​arolherbst🐧🦀> ohhh
13:21 fdobridge_: <k​arolherbst🐧🦀> all that stuff happens super early...
13:21 fdobridge_: <S​id> https://paste.sidonthe.net/raw/mouse-wolf-worm
13:21 fdobridge_: <S​id> rebar is full size even without modules controlling the gpu
13:21 fdobridge_: <S​id> now let me modprobe nouveau
13:23 fdobridge_: <S​id> ...wut
13:23 fdobridge_: <S​id> modprobe: ERROR: could not insert 'nouveau': Operation not permitted
13:23 fdobridge_: <k​arolherbst🐧🦀> ehhh
13:23 fdobridge_: <k​arolherbst🐧🦀> that bug
13:23 fdobridge_: <S​id> oh so it is a known issue, okay 😅
13:23 fdobridge_: <!​DodoNVK (she) 🇱🇹> It's `sudo` time I guess
13:23 fdobridge_: <S​id> ```
13:23 fdobridge_: <S​id> [sidpr@strogg ~]$ sudo modprobe nouveau
13:23 fdobridge_: <S​id> modprobe: ERROR: could not insert 'nouveau': Operation not permitted
13:23 fdobridge_: <S​id> [sidpr@strogg ~]$ su
13:23 fdobridge_: <S​id> Password:
13:23 fdobridge_: <S​id> [root@strogg sidpr]# modprobe nouveau
13:23 fdobridge_: <S​id> modprobe: ERROR: could not insert 'nouveau': Operation not permitted
13:23 fdobridge_: <S​id> ```
13:23 fdobridge_: <k​arolherbst🐧🦀> it's modprobe being silly
13:24 fdobridge_: <k​arolherbst🐧🦀> use `insmod` or something
13:25 fdobridge_: <k​arolherbst🐧🦀> there is some way to figure out the reason it refuses to load, but sometimes it's also just silly
13:25 fdobridge_: <S​id> ..wat `insmod: ERROR: could not load module nouveau: No such file or directory`
13:25 fdobridge_: <k​arolherbst🐧🦀> need to specify the full path
13:25 fdobridge_: <S​id> ah
13:26 fdobridge_: <S​id> `insmod: ERROR: could not insert module /usr/lib/modules/6.7.0-273-tkg-linux-caco/kernel/drivers/gpu/drm/nouveau/nouveau.ko.zst: Operation not permitted`
13:26 fdobridge_: <S​id> :cursedgears:
13:26 fdobridge_: <k​arolherbst🐧🦀> pain
13:26 fdobridge_: <k​arolherbst🐧🦀> something in `dmesg`?
13:26 fdobridge_: <S​id> blacklisting a module only prevents automatic insertion, right?
13:27 fdobridge_: <k​arolherbst🐧🦀> `insmod` ignores all of that modprobe stuff I think...
13:27 fdobridge_: <S​id> I blacklist with a kernel parameter
13:27 fdobridge_: <S​id> `module_blacklist=nouveau,nvidia` this boot
13:29 fdobridge_: <k​arolherbst🐧🦀> ohh uhm..
13:29 fdobridge_: <k​arolherbst🐧🦀> that might actually matter
13:29 fdobridge_: <S​id> ok wait I can change it to modprobe.blacklist apparently
13:29 fdobridge_: <k​arolherbst🐧🦀> 😄 yeah
13:29 fdobridge_: <k​arolherbst🐧🦀> please use that instead
13:29 fdobridge_: <k​arolherbst🐧🦀> though
13:29 fdobridge_: <k​arolherbst🐧🦀> you also have to prevent nvidia loading it anyway
13:30 fdobridge_: <k​arolherbst🐧🦀> though mhh
13:30 fdobridge_: <k​arolherbst🐧🦀> nah, should be fine
13:33 rendertheradius: Yeah well insmod is not clever enough to insert the deps, in terms of like drm.ko and such
13:34 fdobridge_: <S​id> modprobe.blacklist doesn't take a comma separated list...
13:34 fdobridge_: <S​id> reboot again!
13:38 fdobridge_: <S​id> :o
13:39 fdobridge_: <S​id> ```
13:39 fdobridge_: <S​id> Capabilities: [bb0 v1] Physical Resizable BAR
13:39 fdobridge_: <S​id> BAR 0: current size: 16MB, supported: 16MB
13:39 fdobridge_: <S​id> BAR 1: current size: 8GB, supported: 64MB 128MB 256MB 512MB 1GB 2GB 4GB 8GB
13:39 fdobridge_: <S​id> BAR 3: current size: 32MB, supported: 32MB
13:39 fdobridge_: <S​id> Kernel driver in use: nouveau
13:39 fdobridge_: <S​id> Kernel modules: nouveau, nvidia_drm, nvidia
13:39 fdobridge_: <S​id> ```
13:39 fdobridge_: <S​id> if I modprobe nouveau in manually post boot
13:39 fdobridge_: <S​id> so I think we just have to wait until the pci driver is done doing its thing before taking control of the GPU
13:39 rendertheradius: But I came to conclusion, that the procedures are not terrifying hard, once I started to understand them, but I tested in 1024 format, today I try at 1584 format, 1024 format is quite easy so far great results in handling access through queue jumping indexes or descending order, 1584 is non colliding format 32to64 as it sums into such value.
13:41 fdobridge_: <S​id> did an rmmod nouveau and it reverted
13:41 fdobridge_: <S​id> ```
13:41 fdobridge_: <S​id> Capabilities: [bb0 v1] Physical Resizable BAR
13:41 fdobridge_: <S​id> BAR 0: current size: 16MB, supported: 16MB
13:41 fdobridge_: <S​id> BAR 1: current size: 256MB, supported: 64MB 128MB 256MB
13:41 fdobridge_: <S​id> BAR 3: current size: 32MB, supported: 32MB
13:41 fdobridge_: <S​id> Kernel modules: nouveau, nvidia_drm, nvidia
13:41 fdobridge_: <S​id> ```
13:44 fdobridge_: <S​id> so I think we have to:
13:44 fdobridge_: <S​id> 1. wait for pci driver to do its thing before taking control
13:44 fdobridge_: <S​id> 2. tell pci driver to do its thing again after the module has been unloaded
13:45 fdobridge_: <S​id> ..do we even handle module unloading in nouveau or is that just left for the kernel to do
13:47 fdobridge_: <k​arolherbst🐧🦀> best effort support
13:47 fdobridge_: <k​arolherbst🐧🦀> pain...
13:47 fdobridge_: <k​arolherbst🐧🦀> so if you load nouveau later it all works out?
13:47 fdobridge_: <S​id> yup
13:47 fdobridge_: <k​arolherbst🐧🦀> mhhhh
13:48 fdobridge_: <S​id> but if you unload nouveau it reverts
13:48 fdobridge_: <k​arolherbst🐧🦀> mhhhhh
13:48 fdobridge_: <k​arolherbst🐧🦀> this is a desktop, right?
13:48 fdobridge_: <S​id> granted, I don't have a way to test how much BAR is currently being used and/or how well it is doing rebar
13:48 fdobridge_: <S​id> no, laptop
13:48 fdobridge_: <k​arolherbst🐧🦀> ahhh
13:48 fdobridge_: <k​arolherbst🐧🦀> try `nouveau.runpm=0`
13:48 fdobridge_: <k​arolherbst🐧🦀> I wonder if runpm messes it up...
13:48 fdobridge_: <S​id> kernel param?
13:49 fdobridge_: <k​arolherbst🐧🦀> yeah
13:49 fdobridge_: <S​id> ok, hang on
13:49 fdobridge_: <S​id> is it ok for me to boot with nouveau this time?
13:49 fdobridge_: <S​id> or should I manually modprobe again
13:51 fdobridge_: <S​id> going with manual modprobe
13:52 fdobridge_: <S​id> 8gb bar before modprobe ✓
13:52 fdobridge_: <S​id> 8gb bar after modprobe ✓
13:53 fdobridge_: <S​id> 8gb bar after rmmod ×
13:53 fdobridge_: <k​arolherbst🐧🦀> mhhhh...
13:53 fdobridge_: <S​id> /proc/cmdline: `initrd=\intel-ucode.img initrd=\initramfs-linux-caco.img rw root=UUID=0540cdad-e1cf-46a0-bb52-f734e97b1d9c i915.enable_fbc=1 i915.lvds_downclock=1 i915.enable_guc=2 i915.enable_psr=1 pcie_aspm=force pcie_aspm.policy=performance drm.vblankoffdelay=1 ahci.mobile_lpm_policy=1 modprobe.blacklist=nouveau pci=realloc module_blacklist=nvidia nouveau.runpm=0`
13:54 fdobridge_: <k​arolherbst🐧🦀> yeah soo.. no idea what's wrong there 🙂
13:54 fdobridge_: <S​id> fair
13:54 fdobridge_: <S​id> the rmmod thing can be fixed later tbh
13:55 fdobridge_: <k​arolherbst🐧🦀> yeah.. I'm more worried that it's kinda related to not having 8gb bars if nouveau loads on boot
13:55 fdobridge_: <S​id> ..as in?
13:55 fdobridge_: <k​arolherbst🐧🦀> maybe it makes sense to check what amdgpu is doing and copy past it?
13:55 fdobridge_: <S​id> worth a try for sure
13:55 fdobridge_: <S​id> I can test kernel patches within an hour of you giving them to me this weekend too
13:56 fdobridge_: <k​arolherbst🐧🦀> yeah, I won't have time to write kernel patches anyway
13:57 rendertheradius: I've been fiddling with this method for some years already, it all came down to getting the elimination filters and lifters to function , which took so long with my anger management issues, however full compiler has so many other details to write, that technically it's not the one man job anymore. So on the most important lifters and magic of numbers I can talk though, present how powers of two weights can be minified to smaller non colliding
13:57 rendertheradius: weights, that present the same amount of combinations.
13:57 fdobridge_: <S​id> maybe I'll write one by myself for a change :P
13:58 fdobridge_: <k​arolherbst🐧🦀> that's my hope 😄
13:59 fdobridge_: <S​id> o7
13:59 fdobridge_: <S​id> what should new kernel patches be written against btw?
13:59 fdobridge_: <S​id> linux-next?
13:59 fdobridge_: <k​arolherbst🐧🦀> `drm-misc-next` generally
13:59 fdobridge_: <S​id> got you
14:04 fdobridge_: <S​id> well, cloning that branch
14:04 fdobridge_: <S​id> ..actually, let me do a shallow clone, I don't need the full history on my drive
14:06 fdobridge_: <k​arolherbst🐧🦀> yeah... it's uhm.. huge
14:06 fdobridge_: <S​id> --depth=1 my beloved
14:06 fdobridge_: <k​arolherbst🐧🦀> my kernel tree is like 30 GB in total (with compiled binaries and stuff) 😄
14:06 fdobridge_: <S​id> *sweat*
14:06 fdobridge_: <S​id> Receiving objects: 100% (87456/87456), 241.75 MiB | 2.88 MiB/s, done.
14:06 fdobridge_: <S​id> :D
14:07 fdobridge_: <k​arolherbst🐧🦀> yeah.. shallow clone helps a lot
14:07 fdobridge_: <k​arolherbst🐧🦀> my entire `~/git` dir is apparently 150 GB :ferrissweatmegaspin:
14:08 fdobridge_: <S​id> fun
14:08 fdobridge_: <S​id> so, I have to look at... drivers/gpu/drm/amd/amdgpu, see how they do it, then try to wedge that into drivers/gpu/drm/nouveau, right?
14:09 fdobridge_: <k​arolherbst🐧🦀> yeah
14:09 fdobridge_: <S​id> just making sure I understand what I have to do here before I spend effort on it e-e
14:09 fdobridge_: <S​id> okie
14:09 fdobridge_: <k​arolherbst🐧🦀> though I have no idea what they are doing there, so they might also just do nothing 😄 dunno
14:09 fdobridge_: <k​arolherbst🐧🦀> but at least it works there
14:10 fdobridge_: <k​arolherbst🐧🦀> I don't know if `i915` or `xe` have support for rebar, but might make sense to take a look there as well
14:10 fdobridge_: <S​id> right
14:10 fdobridge_: <S​id> ok shit it's 1940 already
14:10 fdobridge_: <S​id> dinner time
14:12 fdobridge_: <!​DodoNVK (she) 🇱🇹> Hopefully you have something to eat (because WW2 happened during that time)
14:13 fdobridge_: <S​id> i915 is harder to comb through
14:13 fdobridge_: <S​id> I already found some relevant bits of what amdgpu is doing
14:14 fdobridge_: <S​id> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L1362
14:14 fdobridge_: <S​id> ope
14:14 fdobridge_: <S​id> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L1421 (edited)
14:15 fdobridge_: <S​id> anyway, dinner
14:17 fdobridge_: <S​id> only one way to find out
15:24 fdobridge_: <S​id> hm
15:24 fdobridge_: <S​id> figuring out how nouveau works and/or where this is meant to go is harder than I anticipated
16:11 fdobridge_: <c​onan_kudo> @airlied @karolherbst would either of you be mad if I merged this and built it in Rawhide? https://src.fedoraproject.org/rpms/mesa/pull-request/32#
16:12 fdobridge_: <k​arolherbst🐧🦀> as long as fedora people also help with fixing bugs, then that's fine
16:12 fdobridge_: <c​onan_kudo> uhhh
16:13 fdobridge_: <c​onan_kudo> I can't rust 😅
16:13 fdobridge_: <S​id> nvk is written in c
16:13 fdobridge_: <g​fxstrand> As long as Fedora bumps to 24.1 for the actual 40 release or as a quick hotfix (depending on release schedules), I'm fine with it.
16:13 fdobridge_: <S​id> only nak is rust
16:13 fdobridge_: <g​fxstrand> For now...
16:14 fdobridge_: <c​onan_kudo> I believe that's the plan, since 24.1 is aimed for March, right?
16:14 fdobridge_: <g​fxstrand> Roughly, yeah.
16:14 fdobridge_: <c​onan_kudo> yeah that should be okay
16:14 fdobridge_: <S​id> ~~if we want to rewrite nvk in rust, the best time to start over is yesterday~~
16:15 fdobridge_: <c​onan_kudo> Rust and I aren't on the best of terms
16:15 fdobridge_: <c​onan_kudo> but otherwise, meh
16:16 fdobridge_: <k​arolherbst🐧🦀> fun fact, today testing CL stuff I ran into this:
16:16 fdobridge_: <k​arolherbst🐧🦀> ```
16:16 fdobridge_: <k​arolherbst🐧🦀> [607000.262837] nouveau 0000:01:00.0: fifo:PBDMA0: CTXNOTVALID chid:2
16:16 fdobridge_: <k​arolherbst🐧🦀> [607000.262840] nouveau 0000:01:00.0: fifo:000000:0002:0002:[test_basic[1142354]] errored - disabling channel
16:16 fdobridge_: <k​arolherbst🐧🦀> [607000.262843] nouveau 0000:01:00.0: test_basic[1142354]: channel 2 killed!
16:16 fdobridge_: <k​arolherbst🐧🦀> ```
16:17 fdobridge_: <k​arolherbst🐧🦀> the issue: I didn't even enable nouveau for rusticl in that testing 🙃
16:17 fdobridge_: <c​onan_kudo> so, I'm going to merge this now, and I'm counting on @karolherbst and @airlied to save me from pwalter if he rages at me
16:17 fdobridge_: <k​arolherbst🐧🦀> I might look into what's the deal with that error
16:17 fdobridge_: <k​arolherbst🐧🦀> who is pwalter?
16:18 fdobridge_: <c​onan_kudo> Pete Walter is the "main" maintainer of Mesa in Fedora, and has a grudge against me since 2020.
16:19 fdobridge_: <c​onan_kudo> way back when I brought pagure into EPEL 8, there was a kerfuffle that led to him saying that I'm a bad contributor to Fedora and he'll ignore anything from me
16:19 fdobridge_: <!​DodoNVK (she) 🇱🇹> What could `[ 21.937578] nouveau 0000:0b:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x00000065` mean?
16:19 fdobridge_: <!​DodoNVK (she) 🇱🇹> Channel creation in NVK is failing for someone
16:20 fdobridge_: <S​id> this is happening on
16:20 fdobridge_: <S​id> ```
16:20 fdobridge_: <S​id> 0b:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1)
16:20 fdobridge_: <S​id> Subsystem: Gigabyte Technology Co., Ltd TU104 [GeForce RTX 2070 SUPER] [1458:4008]
16:20 fdobridge_: <S​id> Kernel driver in use: nouveau
16:20 fdobridge_: <S​id> Kernel modules: nouveau```
16:20 fdobridge_: <S​id> with gsp enabled
16:21 fdobridge_: <k​arolherbst🐧🦀> @conan_kudo though I suspect you'll roll back that change as in a week you get bug reports of random compositors not starting, because $vulkan
16:21 fdobridge_: <c​onan_kudo> only way to find out is to try it 🙂
16:22 fdobridge_: <c​onan_kudo> nvk won't be used unless you have a NV 40 series anyway by default
16:22 fdobridge_: <!​DodoNVK (she) 🇱🇹> Do you mean GSP?
16:22 fdobridge_: <k​arolherbst🐧🦀> I think you meant NV 20
16:22 fdobridge_: <c​onan_kudo> blech
16:22 fdobridge_: <k​arolherbst🐧🦀> or do we have additional restrictions? 😄
16:22 fdobridge_: <c​onan_kudo> NV RTX 40
16:23 fdobridge_: <c​onan_kudo> unless you have my non-upstream patch, Turing and Ampere won't use it by default right now
16:23 fdobridge_: <k​arolherbst🐧🦀> you mean gsp?
16:23 fdobridge_: <c​onan_kudo> since GSP is not enabled for them by default
16:23 fdobridge_: <c​onan_kudo> yes
16:23 fdobridge_: <k​arolherbst🐧🦀> sure, but NVK would still run on those
16:23 fdobridge_: <k​arolherbst🐧🦀> nvk doesn't require gsp at all
16:24 fdobridge_: <c​onan_kudo> oh welp
16:24 fdobridge_: <c​onan_kudo> then I guess the kwin people are going to be very excited 😛
16:24 fdobridge_: <k​arolherbst🐧🦀> oh fun idea
16:24 fdobridge_: <S​id> also turing and ampere can do gsp as well, it's just not enabled by default
16:24 fdobridge_: <k​arolherbst🐧🦀> make NVK report itself as a CPU impl if GSP isn't enabled :ferrisUpsideDown:
16:24 fdobridge_: <c​onan_kudo> oh god
16:24 fdobridge_: <k​arolherbst🐧🦀> roughly the same speed
16:28 fdobridge_: <S​id> @airlied
16:28 fdobridge_: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1200114872822812702/rins_gsp_adventures.log?ex=65c50112&is=65b28c12&hm=e861c2bf6c0ac2e5cc0576c7755933cc71c8c9253dc6490be8e08013f6beb142&
16:28 fdobridge_: <S​id> ..I feel like I've seen these rips before
16:28 fdobridge_: <r​inlovesyou> :')
16:28 fdobridge_: <S​id> 👋
16:29 fdobridge_: <k​arolherbst🐧🦀> :ferrisWave:
16:29 fdobridge_: <r​inlovesyou> hiya, that's my funny log, if you need any more info from me let me know, i'll return to the proprietary drivers for now though :Hehe: can't wait to give NVK a proper try though
16:30 fdobridge_: <S​id> I feel like that `nouveau-gsprm-nonstall` kernel would be helpful here
16:30 fdobridge_: <S​id> I could be wrong
16:30 fdobridge_: <k​arolherbst🐧🦀> huh, what log?
16:30 fdobridge_: <r​inlovesyou> this baby
16:30 fdobridge_: <k​arolherbst🐧🦀> ahh
16:31 fdobridge_: <S​id> anyway, now that rin's here I'm gonna go back to figuring out how nouveau works and seeing where I should wedge in some terrible rebar related code
16:38 fdobridge_: <S​id> @karolherbst ok, please correct me if I'm wrong, but whatever rebar related code I come up with would have to go into drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
16:38 fdobridge_: <S​id> trying to understand the directory tree here
16:39 fdobridge_: <S​id> what exactly is nvkm
16:41 fdobridge_: <k​arolherbst🐧🦀> uhm.. there was the idea of separating certain bits of the driver to make it simpler for virtualization and stuff, don't worry too much about it
16:42 fdobridge_: <k​arolherbst🐧🦀> I think the problem is, that at this point you are already too late to do rebar
16:42 fdobridge_: <k​arolherbst🐧🦀> and you'd need to do it inside `drivers/gpu/drm/nouveau/nvkm/engine/base.c` because I think that's where we map the bars
16:45 fdobridge_: <c​onan_kudo> huh, apparently pwalter isn't mesa maintainer anymore
16:45 fdobridge_: <S​id> ...wdym
16:45 fdobridge_: <c​onan_kudo> then the only people whose wrath I have fear are people who won't flog me 😄
16:47 fdobridge_: <k​arolherbst🐧🦀> you probably need to do the rebar thing before you even map the bar, and most of the code in `pci.c` relies on that already being done
16:47 fdobridge_: <S​id> I see
16:47 fdobridge_: <r​inlovesyou> Well it's never too late
16:47 fdobridge_: <S​id> can you tell I know nothing about how any of this works :D
16:47 fdobridge_: <r​inlovesyou> It'll just be more painful
16:48 fdobridge_: <r​inlovesyou> :clueless:
16:48 fdobridge_: <S​id> by the time I figure out where we're doing BAR related stuff, kernel 6.10 will be out
16:48 fdobridge_: <r​inlovesyou> Kek
16:49 fdobridge_: <S​id> honestly amdgpu is much easier to read as someone who doesn't know anything, the important functions are nicely commented e-e
16:50 fdobridge_: <S​id> easy
16:50 fdobridge_: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1200120541126873128/image.png?ex=65c5065a&is=65b2915a&hm=4a8afee538a5f318ce2285b39cb3cc71df0e592df016e15d90cf6885cf642bff&
16:51 fdobridge_: <S​id> 😰
16:51 fdobridge_: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1200120671339024384/image.png?ex=65c50679&is=65b29179&hm=a50aa656f4e684f56b758d3470cc5b22777c4dcc891c9259674f3a2fb68c5135&
16:51 fdobridge_: <r​inlovesyou> I often put off documenting functions until everything is stable lol
16:52 fdobridge_: <S​id> sure, nothing against it, but it's just harder for someone who's not very well versed with the code from the beginning to jump in and start contributing that way
16:53 fdobridge_: <r​inlovesyou> Oh yeah, no doubt about that
16:53 fdobridge_: <S​id> which is the position I find myself in at the moment
16:59 fdobridge_: <S​id> bleh, I'll bash my head into this tomorrow
17:10 fdobridge_: <g​fxstrand> Yeah, nouveau.ko has way more layers than is good for it, IMO
17:11 fdobridge_: <g​fxstrand> Oh, so it's IMAD.IADD simply because it's multiplying by 0 and IMAD.SHL just because it's multiplying by a power of two and adding 0?
17:13 fdobridge_: <k​arolherbst🐧🦀> yes
17:14 fdobridge_: <k​arolherbst🐧🦀> those flags don't exist in the encoding
17:14 fdobridge_: <S​id> and I imagine cleaning it out won't be easy...
17:14 fdobridge_: <k​arolherbst🐧🦀> anyway, it's part of instruction scheduling and make better use of available alu units 😄
17:15 fdobridge_: <k​arolherbst🐧🦀> there is also `IMAD.MOV`
17:25 fdobridge_: <m​arysaka> @airlied Do you have any patches for envyhooks around for video encoding/decoding?
17:27 fdobridge_: <m​arysaka> I just fixed crashes for multi-threaded commands submission in the signal handler (@dwlsalmeida needed that to make ffmpeg vulkan fork work)
17:27 fdobridge_: <m​arysaka> (also cc @gfxstrand you might want to update it as this could have caused some inconsistencies on dumps 😅)
17:31 fdobridge_: <m​arysaka> In any cases I can confirm that there is some SET_OBJECT for some NVDEC class in my dumps now
17:43 fdobridge_: <m​arysaka> ~~In any cases I can confirm that there is some SET_OBJECT for some NVDEC class in my dumps now~~ nevermind it was the DMA channel... (edited)
17:46 fdobridge_: <m​arysaka> actually no I saw one :vReiAgony:
18:36 fdobridge_: <k​arolherbst🐧🦀> mhhhhh code like this is legal: :ferrisThonk: https://godbolt.org/z/d1MnPPbPj
18:37 fdobridge_: <k​arolherbst🐧🦀> kinda never occurred to me that you can bind multiple things with internal data if you use the proper variables...
18:37 fdobridge_: <m​arysaka> Yes you totall can do that it's quite useful in certain cases
18:37 fdobridge_: <k​arolherbst🐧🦀> can also do this: https://godbolt.org/z/dq7r5PjrM
18:38 fdobridge_: <m​arysaka> if you want to have a public enum on your crate, don't forget to put a #[non_exhaustive] modifier on it
18:38 fdobridge_: <m​arysaka> that way people need to handle the `_` case
18:38 fdobridge_: <k​arolherbst🐧🦀> oh, that's just for rusticl
18:38 fdobridge_: <m​arysaka> oh right so no public API 😄
18:38 fdobridge_: <k​arolherbst🐧🦀> I kinda want to refactor quite some code
18:39 fdobridge_: <k​arolherbst🐧🦀> like currently my Memory object is the C style "let's declare all the fields for all types" and I want to use enums to reduce some of the if/else code...
18:39 fdobridge_: <k​arolherbst🐧🦀> there are like... 8? variants or something.. it's kinda wild
18:43 fdobridge_: <g​fxstrand> So, this all reduces to `ald[%lane_id][0x88]`. Woo...
18:43 fdobridge_: <g​fxstrand> I'm gonna run this new patch through the CTS
18:53 fdobridge_: <k​arolherbst🐧🦀> mhh, why do they have this more complex code then?
18:53 fdobridge_: <k​arolherbst🐧🦀> driver details?
19:52 fdobridge_: <a​irlied> @rinlovesyou Turing GPU? Fix should be in 6.7.2 maybe. It's already in 6.8-rd1
19:53 fdobridge_: <a​irlied> Didn't touch envyhooks, don't even know what it is used for 🙂
19:54 fdobridge_: <S​id> I knew I'd seen rips like those before!
19:54 fdobridge_: <S​id> I think joshua's gpu suffered the same
19:59 fdobridge_: <a​irlied> @conan_kudo not sure pwalter was every officially the maintainer, he was just the person who did it most often, I hadn't realised he's stepped back though
20:00 fdobridge_: <c​onan_kudo> well hopefully you're not mad at me for submitting the mesa build 😅
20:00 fdobridge_: <c​onan_kudo> in any case, it seems that grub + xfs borked all the tests and all updates are stuck
20:06 fdobridge_: <a​irlied> I guess we'll either see how used rawhide is or it'll be f40 crashes 😛
20:07 fdobridge_: <a​irlied> I think for 6.8 I might add kconfig to enable gsp on turing/ampere by default
20:09 fdobridge_: <S​id> yay
20:10 fdobridge_: <c​onan_kudo> that'd be great, that way I don't need a patch for it anymore like I have for my CentOS Hyperscale kernel 😅
20:11 fdobridge_: <!​DodoNVK (she) 🇱🇹> Will that Kconfig be enabled by default?
20:18 fdobridge_: <r​inlovesyou> 2070 super
20:18 fdobridge_: <r​inlovesyou> so yes i think that's turing
20:18 fdobridge_: <a​irlied> no upstream can never enable it by default, it would have to be distros doing it
20:18 fdobridge_: <r​inlovesyou> alrighty, i'll give it a try with 6.7.2 when that's out
20:20 fdobridge_: <S​id> you should be able to try linux-mainline off of the aur
20:20 fdobridge_: <S​id> or the chaotic-aur if you use that
20:20 fdobridge_: <S​id> if you don't wanna wait for .2, that is
20:21 fdobridge_: <r​inlovesyou> oh yeah chaotic aur
20:21 fdobridge_: <r​inlovesyou> i was in no mood to build linux-mainline
20:22 fdobridge_: <r​inlovesyou> oh wow it's already on 6.8rc-1
20:22 fdobridge_: <r​inlovesyou> very nice, will give that a tryy soon
20:25 fdobridge_: <g​fxstrand> I've got a theory and there seems to even be a CTS test to test it
20:27 fdobridge_: <r​inlovesyou> oh man. now i'm confused
20:27 fdobridge_: <S​id> ?
20:27 fdobridge_: <r​inlovesyou> ```
20:27 fdobridge_: <r​inlovesyou> 2 chaotic-aur/linux-mainline-v3 6.8rc1-1 [0 B 130.58 MiB] [Installed]
20:27 fdobridge_: <r​inlovesyou> The Linux Mainline kernel and modules
20:27 fdobridge_: <r​inlovesyou> 3 chaotic-aur/linux-mainline-v3-headers 6.8rc1-1 [0 B 125.23 MiB] [Installed]
20:27 fdobridge_: <r​inlovesyou> Headers and scripts for building modules for the Linux Mainline kernel
20:27 fdobridge_: <r​inlovesyou> ```
20:27 fdobridge_: <r​inlovesyou>
20:27 fdobridge_: <r​inlovesyou> it didn't prompt me to replace linux/linux-headers
20:27 fdobridge_: <r​inlovesyou> so now it says these guys are installed, but i'm still on 6.7
20:27 fdobridge_: <r​inlovesyou> :Skull:
20:27 fdobridge_: <S​id> yeah, it doesn't replace
20:28 fdobridge_: <r​inlovesyou> damn. so i just yeet linux/linux-headers
20:28 fdobridge_: <r​inlovesyou> damn. so i just yeet linux/linux-headers? (edited)
20:28 fdobridge_: <S​id> you'll have to edit your boot config to use those initrds/kernels
20:28 fdobridge_: <S​id> no
20:28 fdobridge_: <r​inlovesyou> ooh
20:28 fdobridge_: <r​inlovesyou> coolio
20:28 fdobridge_: <S​id> keep them around in case things go south
20:28 fdobridge_: <S​id> but assuming you use systemd-boot
20:28 fdobridge_: <r​inlovesyou> should just be in grub, no?
20:28 fdobridge_: <S​id> yeah, I think grub adds new kernels automatically
20:28 fdobridge_: <S​id> not sure
20:30 fdobridge_: <r​inlovesyou> it did not
20:31 fdobridge_: <S​id> did you grub-mkconfig
20:32 fdobridge_: <r​inlovesyou> yeah had to do that myself
20:32 fdobridge_: <r​inlovesyou> but i'm immediately seeing KDE not turning off 90% of the desktop effects
20:32 fdobridge_: <r​inlovesyou> so it looks like NVK is running
20:33 fdobridge_: <r​inlovesyou> yep! 6.8-rc1 has the GSP issues fixed :D
20:33 fdobridge_: <r​inlovesyou> now i can finally test out NVK
20:33 fdobridge_: <m​arysaka> pushbuf dumps 😄
20:33 fdobridge_: <m​arysaka> (by tracking actual GPFIFO submission in process memory)
20:34 fdobridge_: <a​irlied> oh I was just using the code from nvk
20:34 fdobridge_: <m​arysaka> https://gitlab.freedesktop.org/marysaka/envyhooks/
20:35 fdobridge_: <m​arysaka> my thing just do raw binary dumps and then you can use nv_push_dump to get a readeable output
20:35 fdobridge_: <S​id> yippeee
20:35 fdobridge_: <S​id> welcome :D
20:35 fdobridge_: <m​arysaka> oh so the vk layer? :aki_thonk:
20:35 fdobridge_: <S​id> we (I) post NVK gaming screenshots in #gayming
20:36 fdobridge_: <r​inlovesyou> it seems mangohud can't read GPU info
20:37 fdobridge_: <S​id> yes we don't have that set up yet
20:37 fdobridge_: <r​inlovesyou> yeah seems to depend on libnvidia
20:37 fdobridge_: <r​inlovesyou> rip
20:37 fdobridge_: <S​id> because we don't know how to expose that info from GSP
20:37 fdobridge_: <S​id> or otherwise too
20:43 fdobridge_: <g​fxstrand> @karolherbst Here's the actual fix: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27284
20:44 fdobridge_: <k​arolherbst🐧🦀> pain
20:44 fdobridge_: <g​fxstrand> Yes, but it makes sense and that makes me happy
20:44 fdobridge_: <g​fxstrand> Why NVIDIA is emitting a giant pile of crap for what should be an `iadd3`, I haven't a clue.
20:45 fdobridge_: <k​arolherbst🐧🦀> it's probably faster
20:47 fdobridge_: <k​arolherbst🐧🦀> or I dunno
20:47 fdobridge_: <g​fxstrand> No way 3 instructions is faster than iadd3
20:48 fdobridge_: <k​arolherbst🐧🦀> maybe something silly in their backend?
20:48 fdobridge_: <g​fxstrand> It's probably because of silly LLVM usage
20:48 fdobridge_: <k​arolherbst🐧🦀> mhh.. maybe...
20:49 fdobridge_: <k​arolherbst🐧🦀> I'd assume they know what they are doing, but I also know that LLVM doesn't, so that evens out
20:54 fdobridge_: <d​adschoorse> llvm considered harmful
21:10 fdobridge_: <!​DodoNVK (she) 🇱🇹> `gcc-rs` supremacy then I guess
21:49 fdobridge_: <g​fxstrand> Looks like this is the correct fix. 🥳
21:55 fdobridge_: <g​fxstrand> I should be able to pass 1.3 now if the kernel decides to play nice
21:55 fdobridge_: <S​id> 👀
22:00 fdobridge_: <a​irlied> going to try and work out a proper fix for the race next week, the last fix seems like it was overkill but should work
22:06 fdobridge_: <g​fxstrand> I'm attempting this first run without WSI
22:06 fdobridge_: <g​fxstrand> If it works, I'll try with WSI
22:07 fdobridge_: <S​id> wait did we implement VK_KHR_shader_float16_int8
22:08 fdobridge_: <g​fxstrand> the int8 part, yes
22:08 fdobridge_: <S​id> isn't that ext part of 1.2 though
22:08 fdobridge_: <S​id> will we not need it for 1.3 conformance?
22:09 pavlo: Hello. Can someone give a link to the discord server please
22:09 fdobridge_: <S​id> https://discord.gg/DwChG3qg
22:10 fdobridge_: <g​fxstrand> No, we don't. float16 is optional
22:10 fdobridge_: <p​avlo_it_115> thx
22:11 fdobridge_: <S​id> ah
22:14 Sid127: I might be an outlier but I personally prefer how simple IRC is :P
22:14 Sid127: if there was a sane way to use it for everything, I probably would
22:15 fdobridge_: <d​adschoorse> you will need float16 for roadmap 2024 though
22:16 Sid127: ..what's roadmap 2024
22:18 fdobridge_: <d​adschoorse> https://www.khronos.org/news/press/khronos-drives-industry-support-for-expanded-3d-features-with-vulkan-roadmap-2024
22:19 Sid127: oh
22:19 Sid127: thanks :>
22:20 fdobridge_: <m​arysaka> I started looking into fp16
22:26 HdkR: Increase minimum descriptor set bindings to 7. That QCom influence coming in strong :blobsweat:
22:30 fdobridge_: <r​hed0x> 7 is odd, I assume 1 gets reserved for the driver?
22:31 HdkR: I believe so. What's even weirder is older QCom hardware supports 5 with one reserved for the driver, so you get a sane number of 4 exposed to the user
22:31 HdkR: Well, as sane as a maximum of 4 gives you anyway
22:45 fdobridge_: <p​avlo_it_115> Can I ask about OpenGL here? On mesamatrix it says that the nvc0 driver supports OpenGL version 4.5, but actually glxinfo says version 4.3. What's the trouble?
22:48 fdobridge_: <k​arolherbst🐧🦀> never passed the CTS
22:48 fdobridge_: <k​arolherbst🐧🦀> though at this point it might not matter...
22:48 fdobridge_: <k​arolherbst🐧🦀> the features are implemented
22:50 fdobridge_: <p​avlo_it_115> because the transition to zink is being prepared?
22:51 fdobridge_: <k​arolherbst🐧🦀> nah, just that nobody else cared before exposing 4.4 or 4.5
22:52 fdobridge_: <k​arolherbst🐧🦀> we might as well flip the switch
22:53 HdkR: So far I've only found one or two games that complained about GL 4.5 not being available. Most everything else has switched to Vulkan
22:53 Sid127: helps that most of wine gaming these days uses/recommends dxvk or vkd3d-proton
22:56 fdobridge_: <p​avlo_it_115> Thanks for the answers. But there are still some questions. And what about the support of VAAPI or VDPAU? What does it depend on? And will there be any software implementation through the same nvk?
22:57 fdobridge_: <p​avlo_it_115> Thanks for the answers. But there are still some questions (because I do not understand this question at all). And what about the support of VAAPI or VDPAU? What does it depend on? And will there be any software implementation through the same nvk? (edited)
22:59 Sid127: VAAPI situation hasn't been figured out yet
23:04 Lyude: karolherbst: not sure if you'd know the answer to this, but in the kernel I see the trait PinnedDrop - I assume that just means "free this object without moving it in the process?"
23:05 karolherbst: probably
23:06 karolherbst: I know that there were some issues around running out of stack space and stuff
23:09 karolherbst: Lyude: right.. soo.. the issue in rust is that the impl of `drop` is literally: fn drop<T>(t: T) {} and that can lead to the compiler allocating more stack space due to $reasons
23:10 karolherbst: and you also construct heap allocations by moving the value into the actual struct (e.g. Box)
23:10 karolherbst: but all this stack stuff is a pain in the kernel
23:10 karolherbst: so there is quite some code to deal with all of that
23:13 Lyude: ahhhhh, so PinnedDrop is basically just Drop but without all of that cruft?
23:13 karolherbst: basically
23:13 Lyude: gotcha.
23:13 Lyude: fwiw: looks like the RevocableMutex code from the rust for linux branch is quite out of date, so I've been going through to try to rebase it
23:14 Lyude: (unfortunately there's nothing I could pull from asahi that I can see would fix this, asahi's branch doesn't even have RevocableMutex)
23:16 Lyude: hm. suddenly noticing Revocable -is- a lock type that can use the mutex backend
23:16 Lyude: maybe I can just adjust the device abstraction to use that instead
23:34 Lyude: wait. dakr we have two Revocable implementations in nova's branch atm lol
23:34 Lyude: this explains a lot
23:36 Lyude: rust/kernel/sync/revocable.rs and rust/kernel/revocable.rs
23:40 dakr: Lyude, oh yeah, there may be a bit of a mess currently.
23:41 Lyude: hehe, it's alright, I just think it's funny how long it took me to notice this. this explains a -lot- of the confusion I've been haing
23:41 Lyude: *having
23:41 dakr: It's still the baseline I cherry-picked from the rnvme project last year.
23:41 Lyude: ooooh ok, I was wondering where some of this was coming from
23:41 dakr: I'm currently working on getting a better baseline.
23:42 Lyude: gotcha. jfyi I assume you've been keeping up with the stuff I've been pulling into my branch right?