02:09 mangodev[d]: dwfreed: flicker in what way?
02:10 mangodev[d]: mine jitters, idk about flickers though
02:10 mangodev[d]: ofc the arch wiki says the solution is "get a proper 2d accel driver lmao"
02:30 dwfreed: basically like a fade effect
02:31 dwfreed: but sometimes it just vanishes for a few frames
02:46 mangodev[d]: strange
02:46 mangodev[d]: mine lags when moving between monitors or changing shape
06:49 arthurarmstrong: There should not be any problem releasing the compiler with some effort put yet on the development. However on the describing of things end, i am no longer active, as i believe i covered already everything that is important. If you ever come near me again, extreme force will be used against you, i promise with brutal finishing, and i was never soft, if my hand was not screwed up as
06:49 arthurarmstrong: plate in it, same with knee by terrorists from Estonia, ages ago, at this point i would had beaten up all of you one after another, but my sole belief is i knocked down narcissist idiots like you assaulting and humiliating me, in so big numbers in the past, that if i continued to that longer enough in a sequence, they'd had found a way to shoot a bullet to my heart already, which was de
06:49 arthurarmstrong: facto way to handle gods or admired and feared people here in the past until the Police settled in and took over. In other words, if i continued with fighting my own i'd be dead already.
12:00 snowycoder[d]: karolherbst[d]: For the real kernel patch should I flip the bits adding a comment or use a patching method as in 1cb9e2ef66d53b020842b18762e30d0eb4384de8 (something like `gk104_grctx_generate_r419e44` that is applied on all Kepler cards)?
12:00 karolherbst[d]: snowycoder[d]: the generate callbacks are only really useful if the value depends on external factors
12:01 karolherbst[d]: if you just change the constant then it's kinda pointless to add a callback for it
16:16 snowycoder[d]: karolherbst[d]: Sorry for the delay, I just want to make sure that everything is perfect, it's my first official kernel patch.
16:16 snowycoder[d]: Should I put you as a co-author (you told me what to write)?.
16:16 snowycoder[d]: Should I submit it to the mailing list or to freedesktop's gitlab drm/nouveau?
16:16 snowycoder[d]: Also, why can't we use `NVK_MME_SET_PRIV_REG` as with MaxwellB?
16:16 karolherbst[d]: snowycoder[d]: Suggested-by
16:17 karolherbst[d]: anyway, need to discuss it with dakr or Lyude, because they are the kernel maintainers, only doing userspace myself
16:17 karolherbst: or danilo I guess is the current IRC handle
16:18 karolherbst[d]: `NVK_MME_SET_PRIV_REG` needs firmware level support, which we only have with nvidia's firmware
16:18 karolherbst[d]: it's basically telling the firmware to do something, and the firmware has a list of regs it's allowed to touch this way, it's.. well.. nothing we've implemented in our foss firmware
16:43 gfxstrand[d]: Wait... So could we patch the Kepler firmware to support it? 🤔
16:43 gfxstrand[d]: That sounds like a LOT more work, though.
16:52 asdqueerfromeu[d]: karolherbst[d]: I now wonder how well various NVIDIA GPU generations work on nouveau without those NVIDIA firmware blobs
17:05 snowycoder[d]: gfxstrand[d]: I don't know much about the firmware.
17:05 snowycoder[d]: `NVK_MME_SET_PRIV_REG` seems a custom-defined macro, the only weird thing it does is call a `NV9097_SET_FALCON04`, maybe we need that?
17:13 snowycoder[d]: Also, do we need to fix MaxwellA too? It uses custom firmware (no `NVK_MME_SET_PRIV_REG`) and the 14th bit is still set.
17:13 snowycoder[d]: Anyone with a Maxwell card wants to run a single deqp test?
17:15 redsheep[d]: Th cast majority of Maxwell in the wild is MaxwellB, maybe someone has a 750ti though
17:51 steel01[d]: karolherbst[d]: Wait, what? What foss firmware? Is this just referring to the firmware blobs nvidia released to linux-firmware? Or did I somehow miss a project that's full out re-implementing the firmware?
18:14 gfxstrand[d]: asdqueerfromeu[d]: Not at all for most of them
18:14 gfxstrand[d]: snowycoder[d]: I can on Monday
18:15 gfxstrand[d]: steel01[d]: There's FOSS firmware (assembly source is in the kernel tree) for Fermi through Maxwell A.
18:16 steel01[d]: :wat: So... from the perspective of tegra again, since that's my focus, I could run tegra k1 and tegra x1 without any firmware blobs?
18:18 steel01[d]: Call me blind... but I don't see those. Where are they at?
18:18 karolherbst[d]: gfxstrand[d]: if you want to write assembly? sure
18:18 karolherbst[d]: and uhm.. reverse engineer the ABI how it all works
18:19 karolherbst[d]: might be an interrupt
18:19 karolherbst[d]: we also would have to allow list regs
18:19 karolherbst[d]: and then it's security relevant 🙂
18:20 snowycoder[d]: steel01[d]: graphics firmware is in `drivers/gpu/drm/nouveau/nvkm/engine/gr/fuc` (linux tree).
18:21 steel01[d]: Ah, not the extensions I was looking for when I heard assembly. Thanks.
18:22 snowycoder[d]: Yeah I don't know what fuc{,3,5} is exactly (Falcon UCode?)
18:22 snowycoder[d]: I don't even know how it gets compiled
18:22 marysaka[d]: yeah falcon
18:22 steel01[d]: Very well could be. And yeah, that's what I'm looking for too. How does this get used?
18:22 marysaka[d]: it uses envytools to build that
18:23 steel01[d]: How functional is it? Like dropped in beside the linux-firmware prebuilts?
18:23 marysaka[d]: https://github.com/envytools/envytools/
18:23 marysaka[d]: pretty sure it's a c array blobs in linux tree atm?
18:23 marysaka[d]: haven't looked that in years tho
18:23 marysaka[d]: those firware are quite small
18:24 snowycoder[d]: steel01[d]: It's always used in nouveau before MaxwellB AFAIK, so it is somewhat functional
18:26 steel01[d]: Hmm. I'm still pulling gk20a and gm20b firmware from linux-firmware for my tegra android builds. But I'm always looking for ways to nuke closed source bs whenever possible. If the kepler and maxwell oss firmware could be adapted for tegra, I'd be all in for it. As long as it doesn't lose any major functionality, that is.
18:26 marysaka[d]: steel01[d]: for gm20b impossible, it's all fuc5 with encryption/auth modes
18:27 steel01[d]: Meh.
18:27 marysaka[d]: unless you bypass it entirely (possible at least on tegra by targetting the bootrom)
18:27 snowycoder[d]: karolherbst[d]: We could use a blacklist, only allowing as little registers as we can (just that one).
18:27 snowycoder[d]: As far as I'm aware out-of-range warnings are only useful to debug bad drivers, so it's not useful in production, but it helps with driver dev.
18:27 snowycoder[d]: But reversing the ABI is going to be painful
18:27 snowycoder[d]: *whitelist, sorry
18:28 marysaka[d]: marysaka[d]: let me see if we ever documented that back when I was hacking on Switch stuffs...
18:28 steel01[d]: marysaka[d]: Eh, for targets like the switch that'd be reasonable. I'm also trying to target the shield devices, though. And I don't want to force users to tethered exploit. So guess I'll stick with the prebuilts.
18:28 marysaka[d]: steel01[d]: that's unrelated to the Switch itself, it would apply on all GM20B
18:29 marysaka[d]: likely even TX2 and AGX Xavier
18:29 snowycoder[d]: gfxstrand[d]: Thank you! Whenever you have time it's not urgent.
18:29 snowycoder[d]: The dEQP test case is `dEQP-VK.tessellation.geometry_interaction.passthrough.tessellate_triangles_passthrough_geometry_no_change`
18:29 steel01[d]: Without having to mess with the bootrom?
18:29 marysaka[d]: steel01[d]: I'm talking about the Falcon bootroom
18:29 marysaka[d]: https://switchbrew.org/wiki/Switch_System_Flaws
18:29 marysaka[d]: see "ROP under TSEC secure bootrom via DMA engine stack overwrite (--xploit)"
18:29 steel01[d]: Oooooohhhhh... Context, right. I'm thinking the soc bootrom.
18:29 i509vcb[d]: I wonder if Thor just uses the proper Nvidia open driver now or if it's still nvgpu
18:30 marysaka[d]: i509vcb[d]: I think Orin uses openrm but not the one on github
18:30 i509vcb[d]: (T234 or ga10b is still going to need some work)
18:30 marysaka[d]: it's released with L4T sources ect
18:30 i509vcb[d]: Did ga10b move to open?
18:30 steel01[d]: Orin using openrm for part of the display stack. Like the scanout display hardware. But the gpu itself is nvgpu.
18:30 i509vcb[d]: Last I recall Orin was still nvgpu
18:30 marysaka[d]: ah :nya_sad:
18:30 notthatclippy[d]: marysaka[d]: It uses both openrm and nvgpu. OpenRM for display only.
18:31 marysaka[d]: that's uuum interesting
18:31 i509vcb[d]: Well the Orin openrm is mutually exclusive with the normal one iirc
18:31 notthatclippy[d]: It has a pseudo-GSP in it that drives the display
18:32 steel01[d]: Afaik, internally openrm is one code base. But what gets released is cut and mangled for context. Like the desktop drop nukes all tegra. And vice versa for tegra. And probably a lot more stuff we know nothing about gets cut too.
18:32 notthatclippy[d]: i509vcb[d]: "Temporarily". It was supposed to be unified but then there's always something higher priority to do
18:32 i509vcb[d]: I doubt Orin will be getting that since Thor is releasing
18:32 i509vcb[d]: Unless <big customer> demands it
18:33 marysaka[d]: I wonder how Nintendo did the integration on Switch 2... probably still derived from Android stack and breaking ABI on nvservices :aki_thonk:
18:33 i509vcb[d]: iirc there is a port of nvgpu to horizon?
18:33 i509vcb[d]: Well for 1
18:33 marysaka[d]: yes for NX it was a very old variant of nvgpu
18:34 steel01[d]: I wish newer tegra chips could get oss gpu support. From what I've been told, ga10b would need to be in nouveau since the gsp is like a lite version, nothing like what current desktop cards use. Supposedly thor could be supported by nova, but we'll see.
18:34 marysaka[d]: marysaka[d]: with binder ported with surfaceflinger for presentation ect
18:34 marysaka[d]: really a mess
18:34 steel01[d]: gv11b and ga10b seem like they're gonna be hung out to dry, cause the firmware needed for nouveau will never be released.
18:35 i509vcb[d]: I'd hope the "gsplite" I see mentioned would be doable in Nova as well
18:35 marysaka[d]: marysaka[d]: binder IPC over their custom IPC... and nvgpu port having custom IPC commands for open/close/ioctl
18:35 gfxstrand[d]: gfxstrand[d]: To be clear, I don't think this is a *good* idea. I'm just pondering.
18:35 notthatclippy[d]: i509vcb[d]: FYI gsplite means different things in different architectures. But the volta one you can probably just forget about.
18:36 notthatclippy[d]: (Speaking about desktop. Tegra I'm not too familiar about)
18:36 marysaka[d]: Is it Falcon + new DMA?
18:36 marysaka[d]: I remember seeing that RISC-V presentation about the new cores and the plan around it ect
18:37 marysaka[d]: (<https://www.youtube.com/watch?v=7Lx3692cbAg>)
18:38 notthatclippy[d]: marysaka[d]: I think so? Later chips have both falcon and riscv on the same core (only one active at a time), but IIRC volta didn't have a functional riscv core.
18:39 notthatclippy[d]: We used volta's gsplite to prototype the new driver model but AFAIK it was never slated for production
18:39 i509vcb[d]: A lot of the non-desktop hardware suffers from what I call BSP stockholm syndrome.
18:39 i509vcb[d]: At least from what I recall with Orin most of the drivers are mainline except for the display and gpu
18:39 mohamexiety[d]: i509vcb[d]: they did announce upgrades to orin's SW stack in 2026
18:39 marysaka[d]: notthatclippy[d]: I see, well good thing that the old Falcon is gone tbh, it was quite a disaster :blobcatnotlikethis:
18:40 notthatclippy[d]: marysaka[d]: It's only fully gone for good in Blackwell.
18:40 notthatclippy[d]: If you want an aneurysm try to understand the turing authenticated boot flow with gsp (eg in nova)
18:41 marysaka[d]: I guess I will take a look at some point :maxpoeSweat:
18:41 steel01[d]: i509vcb[d]: More or less. There's still bits and pieces in nvidia-oot that aren't upstream. Yet? Display is the worst part. Openrm having c++ code makes stuff worse, though. Cfi seriously doesn't like that. I have to hack up android kernel builds due to that.
18:42 notthatclippy[d]: marysaka[d]: In one case the riscv gsp code sends a sequence of mmio commands to the cpu to execute which suspend and unload it and load something else on the same gsp core but in falcon mode, which does a thing and then resumes the riscv code
18:43 marysaka[d]: oh god :blobcatnotlikethis:
18:44 snowycoder[d]: notthatclippy[d]: ahahah, syscall is for noobs
18:44 karolherbst[d]: wouldn't it be almost better to run a falcon emulator 😄
18:45 karolherbst[d]: gfxstrand[d]: you see.. mwk did try to write an llvm falcon backend... so the chances we could have written it in C isn't 0%
18:46 marysaka[d]: we had a port of LLVM with Vale for a bit idk if we ever published
18:46 karolherbst[d]: rust to falcon when
18:46 marysaka[d]: good old switch hacking days
18:46 marysaka[d]: we do have a rust assembler and emulator https://github.com/vbe0201/faucon
18:46 marysaka[d]: even can test all crypto operations if you have the secrets dumped ect
18:47 karolherbst[d]: I'm sure it's all a frigging mess, because all this stuff is also context dependent and how I know how that works, it gonna suck
18:48 karolherbst[d]: I wonder if you could even dos the GPU with it
18:48 steel01[d]: Yeesh, if it really is trivial to break secure mode on the gpu falcons, at least on a few tegra generations, full oss firmware in a readable language would be *amazing*. I also know I'd be little of no help in the bootstrap of that. 🙁
18:49 steel01[d]: If the falcon is breakable on tegra, is desktop also vulnerable? Or is that completely differnet?
18:49 karolherbst[d]: though not sure how gsp implements those methods, but if you do it on the host, you need to pause execution, bind a context, set the mmio reg and resume or something
18:49 marysaka[d]: steel01[d]: well older stuffs don't need auth mode, Maxwell B+ need it (Falcon v5 and v6)
18:49 marysaka[d]: For auth mode, it can be (and has been) broken by doing a ROP under the execute only bootrom on X1 at least
18:50 marysaka[d]: it's just a mess because you don't know what you are executing and jumping too :P
18:50 steel01[d]: Is gm20b A or B? I'd assumed A since I thought it came out with the first generations cards
18:50 marysaka[d]: but even then, you would need to understand how the falcon interact with everything and that requires decrypting the blobs at the very least.
18:50 marysaka[d]: steel01[d]: it's B
18:50 steel01[d]: Ah, mmm.
18:50 marysaka[d]: GM20X is maxwell b
18:52 snowycoder[d]: marysaka[d]: I see it mentions a wiki, but no wiki seems present, does it really have docs related to Falcon?
18:52 steel01[d]: And atm, I can't even get any of my gk20a devices to fully boot and load nouveau. >< Everything from thermal panics to kernel panics to missing debug cables. :lesigh:
18:52 marysaka[d]: snowycoder[d]: the wiki refer to switchbrew https://switchbrew.org/wiki/TSEC
18:53 marysaka[d]: that and probably envytools for the rest
19:22 karolherbst[d]: marysaka[d]: great, can we port the current assembly over to it? 😄
19:28 marysaka[d]: karolherbst[d]: not sure what vale is up to those days but might be worth it? 😄
19:50 mohamexiety[d]: notthatclippy[d]: btw on this note, not sure if you can answer this or not but is GSP actually really single core? you touched on this before with e.g. the issues of certain commands blocking others, but the older presentations on the topic mentioned it being multicore which feels a bit weird given this :thonk:
19:53 mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1404191014318510081/FB24B739-3D50-43E8-ABED-8D471BEE52E5.png?ex=689a4a4a&is=6898f8ca&hm=853cbb818c970dc4bee2abc3947336c0c79366364772923c2c350fa669b07813&
19:53 mohamexiety[d]: or not, I think I misremembered; it's dual-core but the second core _isnt_ GSP
19:54 mohamexiety[d]: (note though this is a presentation from 2016)
20:37 airlied[d]: and both cores can't run at the same time
20:40 mohamexiety[d]: yeah
22:00 notthatclippy[d]: mohamexiety[d]: Much overloaded terminology, but it is a single "core" that supports two ISAs, but not at the same time. And in some cases only Falcon sode can do some privileged operations.
22:15 mohamexiety[d]: got it. thanks a lot! ❤️
22:18 notthatclippy[d]: The perf-improving direction here is to simply make gsp-rm do less and off the critical path, rather than throw more hw resources at it.
22:19 notthatclippy[d]: But..tradeoffs. And a lot of work.
22:19 mohamexiety[d]: absolutely