09:48tanriol: Hi. Where should I report if on my laptop nouveau+GSP seems to be not working (DRI_PRIME=1 glxspheres segfaults) and likely unable to runtime suspend (extra 20W of battery consumption)? Linux 6.9.3, TU117. Errors in dmesg looking roughly like in https://gitlab.freedesktop.org/drm/nouveau/-/issues/349
09:50notthatclippy[d]: clangcat: FYI, none of these are related to GSP firmware.
09:51karolherbst: tanriol: might want to ping airlied, but issues like this are kinda hard to debug, especially if they involve firmware
09:51notthatclippy[d]: I'll see if I can figure out a better way to see if any of the CVEs from the last few years apply to r535 gsp.bin
09:54tiredchiku[d]: thanks for checking, milos <3
10:44airlied: tanriol: if it's the same dmesg, pleae point at which of them you have it the same as, there's a bunch of dmesgs on that issue
10:44airlied: or just file a new one maybe
10:53notthatclippy[d]: From nouveau's point of view, GSP is at a lower level of trust than the kernel, right? So only security issues you care about are those where userspace is involved and going through an unmodified, upstream nouveau, right?
10:54airlied: yes, so it's not hugely likely a gsp fw exploit will be exploitable from our userspace
10:56notthatclippy[d]: Yes. Particularly not anything more serious than crashing GSP. Chance of a successful kernel RCE by leveraging GSP are.. well, I'd pay good money to read about it for entertainment value alone.
11:00asdqueerfromeu[d]: GSP bricking vulnerabilities would be far worse (if they're even possible) 🐸
11:03notthatclippy[d]: Feeding a bitstream to GSP and bricking the GPU? Highly unlikely.
11:27tanriol: airlied: Actually, after a reboot my dmesg seems unconnected to the other problems (which haven't reproduced so far), so I've reported it separately as https://gitlab.freedesktop.org/drm/nouveau/-/issues/365
13:05karolherbst[d]: notthatclippy[d]: yeah.. that can only happen if we map arbitrary memory into GSP and then it's kinda nouveau's fault to not harden against invalid data or mapping things it shouldn't :ferrisUpsideDown:
15:34gfxstrand[d]: Debating adding smallvec (https://crates.io/crates/smallvec) as a dependency of NAK....
15:35karolherbst[d]: looks like all deps are optional
15:35gfxstrand[d]: Yeah
15:35gfxstrand[d]: It would be our first runtime dependency
15:35karolherbst[d]: what are `Dev-Dependencies` anyway :ferrisUpsideDown:
15:35gfxstrand[d]: But tiny vectors are so damn useful in compilers....
15:35gfxstrand[d]: There's a reason LLVM uses them everywhere
15:36karolherbst[d]: I mean.. you'd probably statically link against it anyway
15:36karolherbst[d]: (unless distributions disagree)
15:36gfxstrand[d]: Oh, yeah
15:36gfxstrand[d]: If this were C++, it'd be header-only
15:36karolherbst[d]: maybe benchmark it and see if it's worth it?
15:36gfxstrand[d]: Oh, I know it'll be better inside my RA than using Vec
15:37gfxstrand[d]: Maybe not, actually...
15:37karolherbst[d]: I also wanted to use serde at runtime actually
15:37gfxstrand[d]: Yeah, it would be
15:37karolherbst[d]: but...
15:37gfxstrand[d]: I can't wait until we get creates sorted better in meson
15:37karolherbst[d]: it's kinda a pain to use if you don't want anything special like json
15:38karolherbst[d]: like.. I want to use serde for serialize the CL program binaries and stuff
15:38gfxstrand[d]: yeah
15:39karolherbst[d]: I could also use SmallVec for a few things
15:39karolherbst[d]: because .. like.. when do you have more than 1 CL device :ferrisUpsideDown:
15:39gfxstrand[d]: If we ever made NVK Rust-only, I might use it for shader binaries, too.
15:40karolherbst[d]: but before I do any of this, I want to replace most of my HashMaps with Vecs....
15:43karolherbst[d]: nice..
15:43karolherbst[d]: next month I can bump to 1.77 or 1.78 or something
15:44karolherbst[d]: mhh.. maybe only 1.76
15:45karolherbst[d]: I really want 1.77 though
16:08asdqueerfromeu[d]: gfxstrand[d]: Does Rust have headers?
16:09gfxstrand[d]: No
20:49triang3l[d]: gfxstrand[d]: I'm so tempted to do exactly that and even skipping pipe_format…
20:50triang3l[d]: The endian mess there seems like a mess to me, plus that one non-plain exception for something (11.11.10 maybe, I can't remember), R10X6 treated like R16, is just too many edge cases for me
20:53triang3l[d]: also want to just use the color target component swap (the options on AMD are standard, alternate, standard reverse, alternate reverse) and use it and the component count for sampled image swizzles (which are arbitrary) too
20:54gfxstrand[d]: I don't know if we're quite to the point where we can forget big endian exists yet.
20:55gfxstrand[d]: But you certainly don't have to care
20:58redsheep[d]: This is for vulkan drivers? Between x86, all modern arm (afaik) and riscv being little endian can turing+ even work on something big endian?
20:58gfxstrand[d]: No, I mean mesa-wide
20:58gfxstrand[d]: I'd love to clean up the PIPE_FORMAT stuff that depends on endianness
20:59redsheep[d]: Oh hmm. Yeah. Power PC still exists, especially in the context of all of mesa.
20:59gfxstrand[d]: Last time anyone did any real work on BE mesa was almost 10 years ago now
21:00dadschoorse[d]: thankfully there is a big endian issue label, so it's easy to ignore all the bug reports related to it
21:02redsheep[d]: There's a non-zero number of people who love the openpower systems to have less proprietary stuff. As a windows user by day though, obviously I'm not quite so picky lol
21:03gfxstrand[d]: Given that the only thing that works with BE at all is softpipe and maybe LLVMpipe, we could probably amber all of BE
21:07dadschoorse[d]: I think r300 has some big endian support?
21:09airlied[d]: we did BE work recently to fix s390
21:10airlied[d]: and continue to care about it not regressing in main
21:10airlied[d]: support for hw devices though I think there was some radeonsi supported GPU IBM used to stick in BE ppc, but I doubt anyone cares about it that much
21:34karolherbst[d]: gfxstrand[d]: same... the initial support was "big endian is just reverse channel order, right?!?" and then it obviously broke once you have things like rgb565 involved, because you use 16 bit colors for VNC :ferrisUpsideDown:
21:34karolherbst[d]: though I think those bits are fixed enough
21:35karolherbst[d]: airlied[d]: I mean.. nothing against somebody caring, but then I'd advise them to rework how we do big-endian on texture formats
21:35gfxstrand[d]: It's not that they're broken so much as all the pipe format stuff has endian scattered all over because things are defined more endian-dependent than they need to be
21:35karolherbst[d]: yeah...
21:35karolherbst[d]: that was the conclusion I've reached when I looked into it
21:35karolherbst[d]: "why does endianess even matters here?"
21:36karolherbst[d]: but reverse channel order was definetly the point where I went "yep, it's all broken, just got added so it's good enough"
21:36karolherbst[d]: which is fine
21:37karolherbst[d]: doesn't really make sense to put in more effort than needed if your use case is "llvmpipe on VNC"
21:43airlied[d]: when you don't have hw involved it also is a lot easier to think about
21:44airlied[d]: I think last time I looked I got to I don't think you can do qbo's without adding endian support to CTS and apps to do it right
21:44airlied[d]: I'd hate to see how painful getting llvmpipe conformant on BE would be in terms of CTS fixes
21:45karolherbst[d]: yeah....
21:46karolherbst[d]: it's totally not worth the time to spend too much time on it. Though I still think that redoing big-endian from scratch in mesa could simplify some of the code
21:47airlied[d]: I think virgl also cares
21:47airlied[d]: But maybe only with llvmpipe
21:47karolherbst[d]: yeah...
21:47airlied[d]: Since ppl run big endian qemu images
21:48karolherbst[d]: sure, but are there any modern GPUs even supported on big endian by the vendors?
21:48karolherbst[d]: I know that e.g. nvidia gpu kinda had a switch to change some logic impact by endianess, but I think it never really worked
21:48karolherbst[d]: or rather stopped working once the GPUs got more complex
21:49karolherbst[d]: mostly legacy stuff for the PowerPC Macs back in the day
21:49karolherbst[d]: *days
21:53airlied[d]: no hw support be anymore, I think AMD CEDAR as last one I've seen in a be ppc, but maybe they plugged in some sea islands since
22:00triang3l[d]: gfxstrand[d]: Yeah, I think instead of messing with swizzles it needs to provide what swap the format would need (none, 8-in-16 or 8-in-32), using one approach for some formats and another for the other ones seems pretty fragile
22:01triang3l[d]: Though my suggestion is really biased towards AMD 🙃
22:02gfxstrand[d]: No, you really don't want to specify things in terms of swaps. That's just a mess of "did I swap enough times?" errors.
22:02gfxstrand[d]: The current way PIPE_FORMAT is spec'd is pretty reasonable. It says how the channels are laid out and then says which channels map to what colors.
22:02gfxstrand[d]: The annoying thing is the way it handles packed vs. array formats which is a bit backwards.
22:02gfxstrand[d]: But that difference is always going to be endianness pain
22:07airlied[d]: the problem with hw is usually how to you store things for the GPU, and make sure CPU accesses get swapped and vice-versa
22:08airlied[d]: so there having hw swappers confuses things more
22:08airlied[d]: since you can have data preswapped or data that is swapped by the hw
22:11triang3l[d]: gfxstrand[d]: Oh well, is_array plus channel size sounds good enough for determining the needed swap