00:03 TimurTabi: airlied: well, I have the latest rawhide installed and the GSP firmware, nouveau is loaded, but it appears to be unused???? I even have a GUI up, but dmesg shows nothing.
00:07 TimurTabi: glxgears only shows 900fps, so it's definitely not using the GPU. I don't know how to fix this.
00:12 karolherbst: what is glxinfo showing?
00:13 TimurTabi: name of display: :0
00:13 TimurTabi: DRI3 not available
00:13 TimurTabi: failed to load driver: zink
00:13 TimurTabi: display: :0 screen: 0
00:13 TimurTabi: direct rendering: Yes
00:13 TimurTabi: server glx vendor string: SGI
00:13 karolherbst: yeah.. looks like your gl setup is toast
00:13 karolherbst: is this on X or wayland?
00:14 TimurTabi: I had to use text mode to install rawhide because the GUI wouldn't boot during installation.
00:14 TimurTabi: How can I check if X vs Wayland?
00:14 TimurTabi: I had to install GNOME afterwards. I'm not surprised it's borked.
00:15 karolherbst: echo $XDG_SESSION_TYPE
00:15 TimurTabi: tty
00:16 karolherbst: inside the desktop session?
00:16 TimurTabi: Yes
00:16 karolherbst: mhhh
00:16 karolherbst: weird
00:16 TimurTabi: I think it was the text installer.
00:16 karolherbst: probably..
00:16 karolherbst: cat /proc/cmdline
00:16 TimurTabi: Ben's driver won't boot on my GPU without GSP-RM
00:16 fdobridge: <g​fxstrand> ```
00:16 fdobridge: <g​fxstrand> Test run totals:
00:16 fdobridge: <g​fxstrand> Passed: 5969/12160 (49.1%)
00:16 fdobridge: <g​fxstrand> Failed: 0/12160 (0.0%)
00:16 fdobridge: <g​fxstrand> Not supported: 6191/12160 (50.9%)
00:16 fdobridge: <g​fxstrand> Warnings: 0/12160 (0.0%)
00:16 fdobridge: <g​fxstrand> Waived: 0/12160 (0.0%)
00:16 fdobridge: <g​fxstrand> ```
00:16 fdobridge: <g​fxstrand> Had to fix a bunch of misc bugs but I think we have a reasonable baseline now
00:17 karolherbst: TimurTabi: looks like, that you might run into the firmware bug we are trying to track down
00:17 karolherbst: Ampere or Turing?
00:17 TimurTabi: TU104
00:17 karolherbst: mhhh
00:17 karolherbst: that needs updated firmware to work anyway
00:17 karolherbst: so you kinda need a very very new iso to install
00:17 TimurTabi: updated non-GSP firmware?
00:17 karolherbst: yes
00:17 TimurTabi: is it in linux-firmware.git ?
00:17 karolherbst: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/nvidia?id=2e92a49f90f73c8edc44b25c6e669d5e70893c90
00:18 TimurTabi: I install the latest linux-firmware.git already
00:18 karolherbst: okay
00:18 karolherbst: then we'll need to figure out what's broken in your setup
00:18 karolherbst: so
00:18 karolherbst: cat /proc/cmdline
00:19 TimurTabi: BOOT_IMAGE=(hd0,gpt3)/vmlinuz-6.7.0-0.rc0.20231106gitd2f51b3516da.9.fc40.x86_64 root=UUID=7aab4e5e-483f-4ecd-8498-39ded071362d ro nomodeset rhgb qu
00:19 TimurTabi: iet console=ttyS0,115200 console=tty0 nouveau.config=NvGspRm=1 nouveau.debug=gsp=spam
00:19 TimurTabi: I'm surprised the nomodeset is there. Is that normal? That's how it was installed.
00:19 karolherbst: sudo dracut --update-kernel=ALL --remove-args="nomodeset"
00:19 karolherbst: then reboot
00:19 karolherbst: ehhh
00:19 karolherbst: wrong
00:19 karolherbst: sudo grubby --update-kernel=ALL --remove-args="nomodeset"
00:21 TimurTabi: [ 2.090175] nouveau 0000:65:00.0: gsp: firmware "nvidia/tu104/gsp/gsp-535.113.01.bin" unavailable
00:21 TimurTabi: bummer
00:21 karolherbst: heh
00:21 TimurTabi: It's there, though!
00:21 karolherbst: how did you install your linux-firmware
00:21 TimurTabi: ./copy-firmware.sh /lib/firmware
00:21 TimurTabi: # ls -l /lib/firmware/nvidia/tu104/gsp/
00:21 TimurTabi: total 23304
00:21 TimurTabi: -rw-r--r--. 1 root root 57992 Nov 8 17:46 booter_load-535.113.01.bin
00:21 TimurTabi: -rw-r--r--. 1 root root 38024 Nov 8 17:46 booter_unload-535.113.01.bin
00:21 TimurTabi: -rw-r--r--. 1 root root 4196 Nov 8 17:46 bootloader-535.113.01.bin
00:21 TimurTabi: -rw-r--r--. 1 root root 23750944 Nov 8 17:46 gsp-535.113.01.bin
00:21 karolherbst: ehh wait
00:21 karolherbst: do this:
00:21 karolherbst: sudo dracut --regenerate-all -f
00:21 karolherbst: reboot
00:22 TimurTabi: that fixes the initrd?
00:22 karolherbst: well.. maybe
00:22 karolherbst: the thing is, does nouveau report to need those files?
00:22 karolherbst: like do they appear in `modinfo nouveau`?
00:22 TimurTabi: Yes, they do.
00:23 karolherbst: okay
00:23 karolherbst: then the regenerate should include them
00:23 TimurTabi: rebooting
00:23 karolherbst: dracut is a bit "smart" here and only includes files from actively loaded drivers
00:23 TimurTabi: so I'm guessing that the text mode installer adds nomodeset to the cmdline
00:23 karolherbst: yeah
00:24 TimurTabi: it's working, kinda. nouveau loads as expected, but there's no GUI on my monitor.
00:24 karolherbst: mhhhh
00:24 karolherbst: any errors?
00:24 TimurTabi: I don't think so.
00:25 karolherbst: maybe something with gdm or soo...
00:25 TimurTabi: what's the normal way to kickstart the gui in fedora?
00:25 karolherbst: anything comming up with `journalctl --follow`?
00:25 karolherbst: systemctl start gdm
00:25 TimurTabi: that did it
00:25 karolherbst: ahh
00:25 karolherbst: then you want to enable gdm via `systemctl enable gdm`
00:27 TimurTabi: Failed to enable unit: File /etc/systemd/system/display-manager.service already exists and is a symlink to /usr/lib/systemd/system/lightdm.service.
00:27 karolherbst: interesting...
00:27 karolherbst: `systemctl disable lightdm` first then
00:27 TimurTabi: yeah, just did that.
00:27 TimurTabi: seems to work now
00:27 TimurTabi: let me reboot
00:28 TimurTabi: glxgears is at 4500fps, so that's working now.
00:28 karolherbst: cool
00:30 TimurTabi: well, I rebooted and it's still not starting the GUI automatically, but I don't care about that. I just wanted to make sure that my linux-firmware.git change worked, and it does.
00:30 TimurTabi: karolherbst: thanks mucho for your help.
00:30 karolherbst: np
00:31 karolherbst: we have regularly users coming in and not having nouveau loaded for various reasons :D so I'm kinda used to this kinda stuff
00:31 karolherbst: (often due to nvidia installer leaving files behind)
00:31 TimurTabi: stupid nvidia installer :-)
04:32 fdobridge: <t​heevilskeleton> https://nouveau.freedesktop.org/CodeNames.html looks like this:
04:32 fdobridge: <t​heevilskeleton> https://cdn.discordapp.com/attachments/1034184951790305330/1172030944237072384/image.png?ex=655ed5e0&is=654c60e0&hm=794020d085729b0ca523ce28ea469449025cf0388106ba8737a7f951f4c50bad&
04:32 fdobridge: <t​heevilskeleton> https://cdn.discordapp.com/attachments/1034184951790305330/1172030996770730044/image.png?ex=655ed5ec&is=654c60ec&hm=dd02142afa8fb4ae659763f84dd6a5615dfed3d24d411033cb9b3fa6ba6dd0bf&
05:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> So will Arch merge this soon?
05:40 fdobridge: <b​enjaminl> opened a couple nak sm50 MRs against the new branch: https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/254 https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/255
05:42 fdobridge: <b​enjaminl> both of them involve ALU ops that I implemented without `encode_alu`, but I'm not sure if the way I did it is how we would want to do it long-term
14:21 fdobridge: <k​arolherbst🐧🦀> reading comments be like `My boot partition is also 500mb, and it's giving me a lot of trouble as it's barely enough for 2 kernels only. ` :ferrisUpsideDown:
14:22 fdobridge: <m​ohamexiety> honestly yeah
14:22 fdobridge: <m​ohamexiety> my 1GB boot is full already
14:22 fdobridge: <m​ohamexiety> granted I did have to hop between multiple kernels a while ago but even when cleaned up it won't really be enough
14:23 fdobridge: <k​arolherbst🐧🦀> yeah..
14:23 fdobridge: <k​arolherbst🐧🦀> if you don't have FDE set up, don't bother with a `/boot` partition
14:23 fdobridge: <m​ohamexiety> FDE?
14:23 fdobridge: <k​arolherbst🐧🦀> full disk encryption
14:23 fdobridge: <m​ohamexiety> oh
14:23 fdobridge: <c​langcat> Reminds me of the first time I did FDE
14:23 fdobridge: <c​langcat> I encrypted my boot
14:23 fdobridge: <c​langcat> XD
14:23 fdobridge: <k​arolherbst🐧🦀> pain
14:24 fdobridge: <k​arolherbst🐧🦀> but yeah.. on my desktop I don't have `/boot` partitions because it's pointless
14:24 fdobridge: <c​langcat> Well atleast it was a new install and I had all my stuff backed up
14:24 fdobridge: <k​arolherbst🐧🦀> one `/boot/efi` and several `/` for various distributions
14:24 fdobridge: <m​arysaka> 4 kernels is a bit of a mess to fit ~~especially when you forget to enable compression on kernel modules~~
14:24 fdobridge: <m​ohamexiety> so how do things work without `/boot`
14:24 fdobridge: <k​arolherbst🐧🦀> yeah...
14:25 fdobridge: <k​arolherbst🐧🦀> if you build kernels yourself you are kinda screwed with the GSP stuff now :ferrisUpsideDown:
14:25 fdobridge: <c​langcat> Well you have /boot. it's just on your rootfs
14:25 fdobridge: <m​arysaka> I just reduced dnf to only keep 2 kernels
14:25 fdobridge: <k​arolherbst🐧🦀> pain
14:25 fdobridge: <m​arysaka> and well enabled compression because yeah
14:25 fdobridge: <c​langcat> I mean my laptop has 12 kernels installed.
14:26 fdobridge: <k​arolherbst🐧🦀> soon only 3
14:26 fdobridge: <m​ohamexiety> I see
14:26 fdobridge: <m​arysaka> I also could cheat and not integrate the GSP firmware in the initramfs, and let the nvidia rpmfusion package handle adding nouveau for me when the nvidia driver is missing
14:26 fdobridge: <c​langcat> It's the broken laptop I test as many different kernels as I could. XD
14:26 fdobridge: <k​arolherbst🐧🦀> I like the idea of a "misc file" initramfs file shared across all installed kernels
14:26 fdobridge: <k​arolherbst🐧🦀> I hope distributions will do something like that
14:27 fdobridge: <k​arolherbst🐧🦀> but ...
14:27 fdobridge: <k​arolherbst🐧🦀> what happens if the misc one breaks?
14:27 fdobridge: <k​arolherbst🐧🦀> can't contain files which are critical for booting
14:27 fdobridge: <k​arolherbst🐧🦀> but in such a case I'd also be okay with kms not showing up as it's already in an error state
14:28 fdobridge: <c​langcat> I mean my actual PC only has 2 so it's not a big deal to have two initramfs
14:29 fdobridge: <c​langcat> Especially when I use so little space overall
14:29 fdobridge: <c​langcat> https://cdn.discordapp.com/attachments/1034184951790305330/1172181109140901920/grafik.png?ex=655f61ba&is=654cecba&hm=c2f94021bb7a4114fe83a8d3f45bd34518d24e9fdfdb948dc8eb54b691074ced&
14:29 fdobridge: <c​langcat> I can afford the backup kernel
14:29 fdobridge: <k​arolherbst🐧🦀> yeah..
14:29 fdobridge: <k​arolherbst🐧🦀> that's fine
14:29 fdobridge: <k​arolherbst🐧🦀> I advise to use FDE on every laptop with private data however :ferrisUpsideDown:
14:30 fdobridge: <c​langcat> I don't keep private data on here really.
14:30 fdobridge: <k​arolherbst🐧🦀> like.. even the discord authentication token is private data 😛
14:31 fdobridge: <k​arolherbst🐧🦀> or like cookie storage of your browser
14:33 fdobridge: <c​langcat> I don't store cookies. XD
14:33 fdobridge: <k​arolherbst🐧🦀> so you login into every website every time you visit it?
14:34 fdobridge: <c​langcat> But yea I get your point. if you did store access tokens.
14:34 fdobridge: <c​langcat> Yup
14:34 fdobridge: <k​arolherbst🐧🦀> okay
14:34 fdobridge: <c​langcat> I host a password manager on my local network.
14:34 fdobridge: <c​langcat> it fills in password and stuff for me.
14:35 fdobridge: <k​arolherbst🐧🦀> ahh, fair
14:35 fdobridge: <c​langcat> For reference that password server is encrypted. For what I hope is clear reasons
14:35 fdobridge: <k​arolherbst🐧🦀> sure 😄
14:54 fdobridge: <k​arolherbst🐧🦀> cool, but it's hard to read 🙂 Might make sense to open an MR at some point, so everybody can browser, but no pressure, open one whenever you feel like you are read for proper review/comments/suggestions
14:54 fdobridge: <t​heevilskeleton> Open in Firefox and zoom
14:54 fdobridge: <t​heevilskeleton> Open in Firefox and zoom in (edited)
14:55 fdobridge: <t​heevilskeleton> It looks like this on a 1440p display
14:55 fdobridge: <t​heevilskeleton> https://cdn.discordapp.com/attachments/1034184951790305330/1172187819557535754/image.png?ex=655f67fa&is=654cf2fa&hm=b6389518751b24a15301f111c2e70a3e3d69fbca2c51438d49bbc8369d3866d0&
14:56 fdobridge: <t​heevilskeleton> Open in Firefox and zoom in, it's probably gonna help (edited)
14:57 fdobridge: <k​arolherbst🐧🦀> ohh right.. me dumb dumb :ferrisUpsideDown:
14:57 fdobridge: <t​heevilskeleton> Blame Discord :p
14:57 fdobridge: <k​arolherbst🐧🦀> good idea
14:58 fdobridge: <k​arolherbst🐧🦀> but also.. classic gnome moments as the screenshot is of lower quality than your new one :ferrisUpsideDown:
14:58 fdobridge: <k​arolherbst🐧🦀> ehh
14:58 fdobridge: <k​arolherbst🐧🦀> both aren't really crisp..
14:58 fdobridge: <t​heevilskeleton> I used Firefox's screenshot utility
14:59 fdobridge: <k​arolherbst🐧🦀> mhh
14:59 fdobridge: <k​arolherbst🐧🦀> that's with gnome
14:59 fdobridge: <k​arolherbst🐧🦀> https://cdn.discordapp.com/attachments/1034184951790305330/1172188742979702864/image.png?ex=655f68d6&is=654cf3d6&hm=782626afb58ab7cd780233923331a80f16854679417e56a481877df14c3132d9&
15:00 fdobridge: <t​heevilskeleton> It looks fine to me if I open the image in Firefox
15:00 fdobridge: <t​heevilskeleton> Discord compresses for whatever reason
15:00 fdobridge: <k​arolherbst🐧🦀> yeah dunno.. it looks worse than the native page.. whatever
15:00 fdobridge: <t​heevilskeleton> I guess
15:02 fdobridge: <t​heevilskeleton> I still need to work on mobile support, and then I'll open an MR
15:02 fdobridge: <k​arolherbst🐧🦀> cool! :ferrisBongo:
15:02 fdobridge: <t​heevilskeleton> It looks like this lol
15:02 fdobridge: <t​heevilskeleton> https://cdn.discordapp.com/attachments/1034184951790305330/1172189523145400350/image.png?ex=655f6990&is=654cf490&hm=feb328b60538ecd0c36a659f9d8d8302b12a53606109a8122e9c9f65dd1cbee9&
15:03 fdobridge: <k​arolherbst🐧🦀> ~~can't be worse than the current one~~
15:03 fdobridge: <t​heevilskeleton> I'm pretty sure it is lol
15:03 fdobridge: <t​heevilskeleton> Oh WHAT THE FUCK
15:03 fdobridge: <t​heevilskeleton> Never mind lol
15:03 fdobridge: <t​heevilskeleton> https://cdn.discordapp.com/attachments/1034184951790305330/1172189817057062942/image.png?ex=655f69d6&is=654cf4d6&hm=1a5b493fa2597d5380fa5403009b44e77938ec4e74dfae852344c2e25f148667&
15:03 fdobridge: <t​heevilskeleton> Literally unreadable
15:04 fdobridge: <k​arolherbst🐧🦀> yeah.. though if I open it on my phone it's perfect
15:05 fdobridge: <t​heevilskeleton> Huh
15:05 fdobridge: <k​arolherbst🐧🦀> huh what
15:05 fdobridge: <k​arolherbst🐧🦀> the table size changes if I reload 😄
15:05 fdobridge: <t​heevilskeleton> Cursed
15:06 fdobridge: <k​arolherbst🐧🦀> https://cdn.discordapp.com/attachments/1034184951790305330/1172190378766643210/Screenshot_2023-11-09-16-05-53-15_ed7821ed99ee442dec4ede205e7971d6.jpg?ex=655f6a5c&is=654cf55c&hm=cda4a7952cf46a3446ee60e30bb750e13e82f0a3f88603ee87e886deaab0bf79&
15:06 fdobridge: <k​arolherbst🐧🦀> https://cdn.discordapp.com/attachments/1034184951790305330/1172190379043475629/Screenshot_2023-11-09-16-05-47-45_ed7821ed99ee442dec4ede205e7971d6.jpg?ex=655f6a5c&is=654cf55c&hm=7849c91c8093adc41401e84851f4d96eb38bee8ecab1f9391e9dfbcace839e3e&
15:06 fdobridge: <k​arolherbst🐧🦀> well.. "perfect"
15:06 fdobridge: <k​arolherbst🐧🦀> at least it's readable
15:07 fdobridge: <t​heevilskeleton> This is so cursed lol
15:10 fdobridge: <k​arolherbst🐧🦀> yeah..
15:27 fdobridge: <d​wlsalmeida> ack
15:46 fdobridge: <g​fxstrand> Do we know what the 2nd predicate coming out of an XSetP does?
15:49 fdobridge: <g​fxstrand> CUDA docs seem to actually say. \o/
15:49 fdobridge: <k​arolherbst🐧🦀> yeah.. just wanted to suggest it's probably the same as with `ISETP` no?
15:51 fdobridge: <g​fxstrand> Yeah.
15:51 fdobridge: <g​fxstrand> Ugh... I don't think we can implement a swap with `PSETP`
15:52 fdobridge: <g​fxstrand> We could with `PLOP3` but I don't think we can with `PSETP`
16:20 HdkR: Still such a great instruction name
16:35 fdobridge: <g​fxstrand> Ugh... I think I'm going to totally rework the sm50 branch again. Sorry, folks.
16:36 fdobridge: <g​fxstrand> Ugh... I think I'm going to totally rework the sm50 branch again. Sorry, folks. Hopefully this is the last time. (edited)
16:36 fdobridge: <g​fxstrand> Existing MRs will probably mostly still work.
16:36 fdobridge: <g​fxstrand> @vdpafaor I'll be pulling in your LOP2 fixes implicitly, I think.
16:44 fdobridge: <d​wlsalmeida> lmk where to find the most up to date stuff
16:44 fdobridge: <m​arysaka> no worries on my side... I got lost on envyhooks a bit :AkkoDerp:
16:44 fdobridge: <d​wlsalmeida> or if the branch remains the same
16:44 fdobridge: <m​arysaka> Just pushed some changes for envyhooks that add an actual documentation and some extra fixes <https://gitlab.freedesktop.org/marysaka/envyhooks >(multi GPU support, fixed MME dumper hopefully, less spamy logs,...)
16:45 fdobridge: <m​arysaka> Just pushed some changes for envyhooks that add an actual documentation and some extra fixes <https://gitlab.freedesktop.org/marysaka/envyhooks> (multi GPU support, fixed MME dumper hopefully, less spamy logs,...) (edited)
16:50 fdobridge: <g​fxstrand> It'll be the same branch
17:00 fdobridge: <k​onstantinseurer> Is there a parser for the pushbuf/MME dumps?
17:02 fdobridge: <m​arysaka> https://gitlab.freedesktop.org/marysaka/mesa/-/tree/nouveau/pushbuf-dump-tool
17:03 fdobridge: <m​arysaka> I have some stuffs here but if you want to switch between Turing/Fermi style for MME macros it's a mess (because of isaspec needing some love)
17:04 fdobridge: <k​onstantinseurer> Thanks, I'm just interested in Turing right now
17:05 fdobridge: <m​arysaka> then it should be fine, I force disable the old MME decoder on some commit on that branch ^^
17:06 fdobridge: <m​arysaka> to use the pushbuf tool you just do: ``nv_push_dump <file_name> TURING``
17:08 fdobridge: <b​enjaminl> you can do it with the xor trick, but I don't think you can do it in a single instruction
17:10 fdobridge: <b​enjaminl> _maybe_ using the second predicate dst, I don't really understand how that works
17:11 fdobridge: <g​fxstrand> Yeah, I'm pretty sure we can't with that.
17:11 fdobridge: <g​fxstrand> Real bummer, too.
17:13 fdobridge: <b​enjaminl> oof
17:13 fdobridge: <b​enjaminl> how often do swaps actually get emitted?
17:16 fdobridge: <g​fxstrand> More often than you'd like.
17:16 fdobridge: <g​fxstrand> I can do the same trick I do with GPRs, though, and reserve one.
17:16 fdobridge: <g​fxstrand> Then never
17:16 fdobridge: <g​fxstrand> Or we could go through a temp GPR
18:21 fdobridge: <g​fxstrand> @marysaka @vdpafaor @dwlsalmeida I just force-pushed nak/sm50 in nouveau/mesa for hopefully the last time in a while. I think I'm pretty happy with it at this point. Notable changes:
18:21 fdobridge: <g​fxstrand> 1. We're now taking advantage of the SM in the builder (thanks, Ben) and just emitting the right thing up-front
18:21 fdobridge: <g​fxstrand> 2. No more `OpPLop2`, just `OpPSetP` which is what old hardware actually has
18:21 fdobridge: <g​fxstrand> 3. I thoroughly reworked immediates. Take a look at `encode_fadd()` and `encode_isetp()` as model encode functions for future reworks.
18:22 fdobridge: <g​fxstrand> @marysaka @vdpafaor @dwlsalmeida I just force-pushed nak/sm50 in nouveau/mesa for hopefully the last time in a while. I think I'm pretty happy with it at this point. Notable changes:
18:22 fdobridge: <g​fxstrand> 1. We're now taking advantage of the SM in the builder (thanks, Ben) and just emitting the right thing up-front
18:22 fdobridge: <g​fxstrand> 2. No more `OpPLop2`, just `OpPSetP` which is what old hardware actually has
18:22 fdobridge: <g​fxstrand> 3. I thoroughly reworked immediates. Take a look at `encode_fadd()` and `encode_isetp()` as model encode functions for future reworks. (edited)
18:22 fdobridge: <m​arysaka> great 👍
18:28 fdobridge: <b​enjaminl> hmm, if we don't have `OpPLop2` anymore, we could drop `OpLop2` as well and just use `LOP3.LUT` on SM50
18:28 fdobridge: <g​fxstrand> Possibly?
18:28 fdobridge: <g​fxstrand> If we know how to encode `LOP3.LUT`, I don't see a reason why not
18:28 fdobridge: <k​arolherbst🐧🦀> does it work the same on SM50?
18:28 fdobridge: <g​fxstrand> I suspect Kepler will want LOP2, though.
18:28 fdobridge: <m​arysaka> I don't think it exist on SM50...?
18:29 fdobridge: <k​arolherbst🐧🦀> I wonder when somebody starts to implement `LOP3.LUT` folding
18:29 fdobridge: <g​fxstrand> The other thing I'm unsure about with immediates is if there are any opcodes which want a `u20` immediate instead of `i20`.
18:29 fdobridge: <g​fxstrand> We already have `LOP3.LUT` folding
18:29 fdobridge: <k​arolherbst🐧🦀> kinda yes
18:29 fdobridge: <k​arolherbst🐧🦀> but it depends on the context
18:29 fdobridge: <k​arolherbst🐧🦀> it's weird
18:29 fdobridge: <b​enjaminl> it does, opcode `0x0200`
18:30 fdobridge: <m​arysaka> huh I missed that one :aki_thonk:
18:30 fdobridge: <b​enjaminl> don't know about the semantics though, just what nvdisasm will output
18:30 fdobridge: <k​arolherbst🐧🦀> @gfxstrand indirects
18:30 fdobridge: <k​arolherbst🐧🦀> they are 24 bits tho
18:30 fdobridge: <m​arysaka> well I can figure that out if needed
18:30 fdobridge: <k​arolherbst🐧🦀> but it changes on the indirect
18:30 fdobridge: <g​fxstrand> Oh, indirects are an entirely different things
18:30 fdobridge: <k​arolherbst🐧🦀> `RZ + offset` is unsigned, where `Rx + offset` is signed
18:30 fdobridge: <g​fxstrand> Okay, that's funky.
18:31 fdobridge: <k​arolherbst🐧🦀> it kinda makes sense tho 😄
18:31 fdobridge: <k​arolherbst🐧🦀> but yeah
18:31 fdobridge: <g​fxstrand> It does but it's funky
18:31 fdobridge: <g​fxstrand> I was more concerned with random instructions like LOP2 which might just decide they want an unsigned immediate
18:32 fdobridge: <k​arolherbst🐧🦀> I think if it can't be derived from the context they usually have flags for it
18:32 fdobridge: <k​arolherbst🐧🦀> but I can look it up in my docs
18:33 fdobridge: <g​fxstrand> Yeah, like IMul has signed and unsigned bits for each source. Do those affect immediates? 🤷🏻‍♀️
18:33 fdobridge: <k​arolherbst🐧🦀> at least `LOP3` is always unsigned
18:34 fdobridge: <g​fxstrand> womp womp
18:34 fdobridge: <k​arolherbst🐧🦀> I'd assume so
18:34 fdobridge: <g​fxstrand> This is where we really need to get a unit test framework upstreamed so we can fuzz these things to death.
18:34 fdobridge: <k​arolherbst🐧🦀> yeah
18:34 fdobridge: <k​arolherbst🐧🦀> better to be sure here
18:35 fdobridge: <k​arolherbst🐧🦀> ohh
18:35 fdobridge: <k​arolherbst🐧🦀> do you know that cb offsets roll over to the next index?
18:36 fdobridge: <k​arolherbst🐧🦀> though I think that only works with indirects
18:36 fdobridge: <k​arolherbst🐧🦀> but yeah.. the upper bits are added to the index
18:36 fdobridge: <g​fxstrand> Yes, I'm aware
18:36 fdobridge: <k​arolherbst🐧🦀> :ferrisUpsideDown:
18:36 fdobridge: <k​arolherbst🐧🦀> okay
18:36 fdobridge: <b​enjaminl> hmm, any idea what bit 56 on `LOP32I` does? in nvdisasm, it toggles a `.INV` modifier on the immediate: `LOP32I.AND R0, R0, 0x0.INV`
18:36 fdobridge: <k​arolherbst🐧🦀> allows for very very funky optimizations you never need
18:37 fdobridge: <b​enjaminl> it would be a little weird if it's just bnot, since you could always fold that into a 32-bit immediate
18:37 fdobridge: <g​fxstrand> Probably inverts the immediate. Not that that's very useful if you have a 32-bit immediate...
18:37 fdobridge: <g​fxstrand> I looked sideways at that one, too.
18:37 fdobridge: <k​arolherbst🐧🦀> yeah...
18:37 fdobridge: <k​arolherbst🐧🦀> they dropped the `.INV` naming so I can't verify
18:37 fdobridge: <k​arolherbst🐧🦀> but we have `~` modifiers
19:26 TimurTabi: airlied: I have an idea for the initrd problem with GSP-RM. Have the driver load without GSP-RM support on early boot, and then reload the driver on full boot when /lib/modules is available. You don't need high performance graphics during early boot.
19:28 karolherbst: TimurTabi: we do need GSP for kms though, no?
19:28 karolherbst: kms is used to activate more displays and stuff
19:29 TimurTabi: That, I don't know.
19:29 karolherbst: with ampere we added a hack temporarily to enable display support without firmware
19:29 karolherbst: but we were restricted to one context
19:29 karolherbst: and given that GSP _also_ handles display, that would basically mean we'd maintain a display path only for pre GSP loads
19:30 karolherbst: which I suspect will remain very buggy
19:30 TimurTabi: On Turing and Ampere, apparently GSP-RM is not needed for normal functionality.
19:30 TimurTabi: At the very least, you could boot non-GSP on Turing and that would save 30MB
19:30 karolherbst: sure.. but then we'd have to support migrating over to GSP on a running system
19:30 karolherbst: and it's not a solution for ada+
19:30 karolherbst: kinda need something working everywhere
19:31 karolherbst: okay.. we save 30MB now, but in the future we might have 200, 300MB of firmware in total anyway
19:31 TimurTabi: Ben said he could get Ada working without GSP-RM, he just didn't didn't bother.
19:31 karolherbst: yeah.. because that means we'd have to support kms on non GSP nouveau
19:31 karolherbst: so essentially maintain two code paths for kms
19:32 TimurTabi: I guess it all depends how badly you want to avoid 60MB bloat on initrd.
19:32 karolherbst: well.. I tell distributions to not ship the same firmware multiple times
19:32 karolherbst: but they do it regardless
19:33 karolherbst: the issue isn't that the file exists once, it exists per installed kernel
19:33 TimurTabi: Frankly, I'm surprised the kernel hasn't figure out a way to mount hard drives before loading the video drivers.
19:33 karolherbst: ohh, we do
19:33 karolherbst: but we also have full disk encryption
19:33 karolherbst: and a pw prompt you want to see on displays
19:33 TimurTabi: can't you do that with normal VGA emulation?
19:33 karolherbst: no
19:33 karolherbst: the firmware won't bring up every display
19:33 karolherbst: DP-MST barely works
19:34 karolherbst: displays on discrete GPUs not at all
19:34 karolherbst: some have "always closed" laptop setups
19:34 karolherbst: and I don't see why we would make it a pain for some users, just because distributions don't get their stuff together
19:35 karolherbst: there is the idea of splitting firmware files in their own initramfs shared across all kernels, so you don't have N x 60 MB, but only 60MB
19:35 karolherbst: we can optimize further by culling old and non needed firmware files
19:35 karolherbst: could even just ship the files you need for your hardware
19:36 karolherbst: btrfs subvolumes would also just solve this issue
19:36 karolherbst: we already have all the solutions here, just....
19:37 karolherbst: that 500MB/1G sized /boot/ is a ticking time-bomb should have been known to everybody...
19:53 HdkR: dedupe would also be a nice solution :)
19:53 HdkR: Sure, ship as many copies as you want, the volume is going to get a dedupe run over it anyway
19:55 karolherbst: well.. the issue is, that initramfs compresses stuff
19:55 karolherbst: and then dedup starts to not do much anymore
19:56 karolherbst: my take is just, that including the same files in each initramfs was a bad idea from the start
20:07 HdkR: ah, okay that's rough
20:25 fdobridge: <b​enjaminl> are multiple initramfs supported, or would that need to be a separate addition?
22:48 fdobridge: <p​homes_> there is both a graphics and a rust dev room at fosdem this year
23:58 fdobridge: <k​arolherbst🐧🦀> I submitted a talk for the rust dev room last year, they didn't accepted it, so I don't like them anymore :ferrisUpsideDown: :ferrisKnife: