01:04phomes_[d]: It is interesting to see how the compression MR affect different games
01:04phomes_[d]: Some games must have been very memory bound. Serious Sam goes from 135 to 281 fps which is very close to what we get on the prop driver
01:05phomes_[d]: The few games that are not helped by it at all must have completely different problems
01:06phomes_[d]: X4 Foundations for instance has not improved with any of the perf MRs that have landed lately
01:18gfxstrand[d]: steel01[d]: Should be sorted in a month. marysaka[d] and I are planning to trade boards at XDC so I should come home with an X1 that boots.
01:19gfxstrand[d]: karolherbst[d]: Cache flushing. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33959
01:24gfxstrand[d]: Heck, maybe we can fix it at XDC. It's always fun to have a group hacking project.
01:25steel01[d]: Fixes would be amazing.
01:25gfxstrand[d]: Once the kernel patch we need lands, we'll have NVK for all Tegra, modulo bugs and CTS testing.
01:28steel01[d]: Once nvk fires up for tegra, I'll put android stuff through the paces. Figure out if zink or angle is better. And hopefully 3dmark won't crash and I'll be able to start getting some hard numbers to compare against the proprietary stack.
01:30steel01[d]: Then I'll just need the vaapi stuff to land. Which hasn't had any discussion for over 2 weeks now. I hope that doesn't just fade into obscurity.
02:01karolherbst[d]: gfxstrand[d]: maybe I should take my nano with me?
02:01karolherbst[d]: I know that that one used to work
02:02gfxstrand[d]: steel01[d]: Once I have a working Tegra on my desk, I plan to hack on Android myself.
02:02gfxstrand[d]: IDK what state your tree is in but if there was something I could `repo sync`, that'd be amazing.
02:03mangodev[d]: gfxstrand[d]: firefox, chrome is a-okay and i've ran into no major issues (aside from some minor artifacting)
02:03mangodev[d]: i may make an issue for it tonight, since it's a reproducible issue (rare)
02:04gfxstrand[d]: karolherbst[d]: My nano works sometimes. It's been "scanning for Bluetooth drives" for a couple weeks now. It only boots one time in 50 but once it's up it's stable.
02:05steel01[d]: gfxstrand[d]: It's a bit of a mess atm. Been planning to push the mainline compatible stuff to the lineage org so it can be built directly there. This could be more incentive to do so. I can look at targeting early next month to finish that.
02:05gfxstrand[d]: mangodev[d]: Okay. Probably more EGL sync bugs. IDK why FF and Chrome are different there but I can try to take a look when I can find a free day or two. I've got a couple other things that are top priority between now and XDC, though.
02:06steel01[d]: gfxstrand[d]: Oh, it is? Thought you said it imploded after booting. Mmm.
02:07steel01[d]: So that is similar to what I see on my nano's, just with a vastly different work/fail ratio.
02:07gfxstrand[d]: steel01[d]: I don't care too much what tree it lives in as long as I can reproduce your builds. But if it's easiest to just push it all to Lineage, then do that.
02:07gfxstrand[d]: steel01[d]: Yeah. It often takes days to get a successful boot but then it's fine.
02:08steel01[d]: gfxstrand[d]: It's a mix of lineage, my staging org, and local hacks. I at least need to work out my local hacks.
02:08karolherbst[d]: gfxstrand[d]: lol
02:09mangodev[d]: gfxstrand[d]: i honestly really wanna find what causes the jank with the cursor layer, it's the primary thing stopping me from liking it as a daily-driver
02:09mangodev[d]: my top suspect is nouveau, but idk why it'd be updating sprite and offset across two frames
02:09mangodev[d]: i tried looking in that `drm-misc` branch, but…
02:09mangodev[d]: 🫠
02:10mangodev[d]: i think the code is architecture specific?
02:10mangodev[d]: saw some cursor plane related stuff in the nv[fournumbers] files
02:11steel01[d]: What does that cursor corruption look like? Do you have a screenshot?
02:11mangodev[d]: i'm not talking about corruption
02:11mangodev[d]: lucky enough to have never ran into it
02:12steel01[d]: Ah, mmm. I've got full out corruption on tegra on android. Trying to screenshot. It definitely doesn't look like a cursor.
02:12mangodev[d]: there's an old issue that's exactly like what i'm having, but with radv
02:12mangodev[d]: it was marked fixed in 2021 with no known cause other than "the driver updates a lot and i guess it got accidentally fixed" 🫠
02:14mangodev[d]: the issue i'm having is jitter
02:14mangodev[d]: shape updates the first frame, offset updates the next
02:14mangodev[d]: it should do it in one go, but it does it across two frames instead
02:14mangodev[d]: different applications are differently and seemingly randomly prone to it, although some are admittedly far worse than others at it
02:15mangodev[d]: firefox is completely exempt from it, and chrome is *mostly* exempt with `EnableFeatures=WaylandWindowDecorations` (but *really bad* without it)
02:15mangodev[d]: everything else varies
02:16steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1414071758314803222/Screenshot_20250906_211539.png?ex=68be3c73&is=68bceaf3&hm=989d5270c2b0480caae04ed5801810d4ae43410249894cf3fd7b60ed2974a4d4&
02:16steel01[d]: Broken cursor on tegra android.
02:16steel01[d]: Via gallium. So... who knows if it'll 'just work' once nvk gets fired up.
02:17steel01[d]: Or if there's an issue with the cursor plane in the tegra-drm driver.
02:17mangodev[d]: hmmmm
02:19mangodev[d]: i think i found the file
02:19mangodev[d]: but it's a lot of abbreviations and mystery functions
02:19mangodev[d]: for the jitter, not for the corruption
02:19mangodev[d]: i wish i could find the culprit, but i do not own hardware subject to it
02:20mangodev[d]: one of [these two functions](https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next/drivers/gpu/drm/nouveau/dispnv50/curs507a.c#L46-L69)
02:20mangodev[d]: maybe
02:21mangodev[d]: wait no, probably not point
02:21mangodev[d]: point seems to be the position of the cursor on screen
02:27mangodev[d]: hmmm
02:27mangodev[d]: maybe `curs507a_prepare()`
02:28mangodev[d]: https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next/drivers/gpu/drm/nouveau/dispnv50/curs507a.c#L77-L88
02:31gfxstrand[d]: mangodev[d]: What desktop environment?
02:33mangodev[d]: gfxstrand[d]: kde wayland
02:33mangodev[d]: i wanted to try the x session, but i think the default wayland environment kerscrewied the x session, because it just boots to a black screen
02:33mangodev[d]: any good full or micro wms/compositors for testing would be helpful
02:34mangodev[d]: i could try gnome, but nouveau in general doesn't have a good history with gnome, and i think i'd find more than what i came for :P
02:34gfxstrand[d]: Okay. KDE seems somehow worse with cursor stuff. IDK why.
02:34mangodev[d]: than gnome? wild
02:35gfxstrand[d]: Yeah, in my testing gnome was fine.
02:35mangodev[d]: would an x session be better, since nvk actually has official support for it?
02:36gfxstrand[d]: <a:shrug_anim:1096500513106841673>
02:37gfxstrand[d]: For cursor issues, yes. Modesetting doesn't have the issues KWin's DRM/KMS backend has.
02:37mangodev[d]: tbf that old radv issue i was talking about was with kde and weston
02:37mangodev[d]: so there's a pattern
02:40gfxstrand[d]: I suspect it has something to do with the order of updates and maybe atomic vs. not.
02:40mangodev[d]: if you're talking about atomic modesetting, it happened regardless
02:41mangodev[d]: both on "legacy" and atomic modes
02:41mangodev[d]: i smell atomics are involved in some way though
02:41gfxstrand[d]: With atomic, you can do it better. But there are potential issues either way. But I'm very much not an expert on this stuff.
02:42gfxstrand[d]: I can play a window system girl on TV but I'm pretty divorced from that world at this point. Especially on the display end.
02:42mangodev[d]: godot applications are by far the worst with it
02:42mangodev[d]: while firefox (surprisingly) has the least issue
02:42mangodev[d]: chromium with WaylandWindowDecorations is mostly fine (with occasional jitters here and there), but it starts happening again on window edges???
02:43mangodev[d]: tbf…
02:43mangodev[d]: that cursor code in nouveau does grab a pointer to the window for the offset
02:44mangodev[d]: although that could be a different type of window
02:44mangodev[d]: i'm honestly not sure, something to talk to a nouveau-drm dev about
02:44gfxstrand[d]: Yeah, window edges are where they hand off the cursor. If the image update, position update, and submitting the next composited frame aren't done in the right order, you can end up with weirdness.
02:45gfxstrand[d]: I've even seen cursor lag on Intel with Iris.
02:45mangodev[d]: by "window edge" i don't mean decorations
02:45mangodev[d]: i mean if the offset of the cursor would exit outside window bounds
02:45x512[m]: Maybe stupid question: why Nouveau-GL can't share NVK shader compiler and command buffer generator code? Will it be faster than NVK+Zink?
02:46mangodev[d]: i mean
02:46mangodev[d]: a literal language barrier is one factor
02:46mangodev[d]: but i think the biggest is that no one wants to touch nouveau-gl
02:46mangodev[d]: and if i'm not mistaken, nouveau-drm is essentially on life support until nova enters a semi-viable state in the future
02:50orowith2os[d]: the shader compiler also isn't the only thing necessary to have ngl support newer hardware.
02:51mangodev[d]: it's a lot of work for a gain unknown
02:51mangodev[d]: i mean, yeah, nouveau-gl *could* be revived
02:51mangodev[d]: but it'd be a lot of effort put into a pandora's box
02:51mangodev[d]: a lot of effort away from nvk
02:52mangodev[d]: and it likely isn't worth as much effort as it'd take to make another gl driver effectively from scratch
02:53orowith2os[d]: point from a previous conversation: it's much better to put that work into zink, which already exists and has more potential, and nvk, which doesn't have the same cruft around it that ngl does.
02:53mangodev[d]: ⬆️
02:53mangodev[d]: i don't get why discord doesn't let me compose arrow characters anymore :/
02:53mangodev[d]: i mean… weechat
02:55mangodev: yeah see, weechat
02:56mangodev: irc
02:56mangodev: yeah! ↑
02:56mangodev: i wonder if my terminal color will die on me here again
02:57mangodev: i think something broke in zink a couple weeks ago that makes kitty lose its color after printing enough characters to the buffer
02:57gfxstrand[d]: mangodev[d]: Yes
02:59gfxstrand[d]: x512[m]: NAK and NIL (the image layout library) were specifically designed to be shareable. They may get less so if we ever do a full Rust conversation but that's a ways out yet. Command buffers, though? If you want to share that, at that point just use Zink.
03:06gfxstrand[d]: And as much as people like to worry about the overhead of having a layer in the way, it really isn't a problem. You can probably get closer to absolute max performance if you tailor the driver to OpenGL but it's not going to matter much for most apps.
03:08gfxstrand[d]: There's a few things we could probably do a little better around resource binding but Zink usually hits NVK's resource optimizations pretty reliably so it's not likely to be worth the effort. And if there is a gap, we can probably figure out how to optimize in NVK.
03:18x512[m]: Anybody knows what is the difference between Zink and ANGLE except desktop OpenGL support?
03:24HdkR: A big difference, they're completely different projects :)
03:25x512[m]: Which one works better?
03:25HdkR: I'd make claims that Zink is better but I'm biased.
03:26HdkR: Since "better" is such a vague term anyway
03:26x512[m]: Benchmark results etc..
03:26HdkR: A phone manufacturer shipped Angle as their GLES implementation and it was laughed at pretty thoroughly, that's at least a reasonable data point
03:27HdkR: Problem is since Angle only supports ES, you're kind of limited to Android ecosystem for tests which isn't interesting for me :D
03:29steel01[d]: x512[m]: This is an interesting point. Would zink expose desktop gl on android? That was one of the big points of the shield tablet and tv series. Ability to use desktop gl on android.
03:30HdkR: Wouldn't work out of the box.
03:30x512[m]: According to recent merge request comments it conflicts with Android system libEGL implementation and require bypassing it.
03:30HdkR: ^
03:30HdkR: Need to replace android's libEGL shim, which NVIDIA devices did.
03:30steel01[d]: Not replace, per se. Sec.
03:31steel01[d]: https://review.lineageos.org/q/nvgpu-t
03:31steel01[d]: Extend.
03:31HdkR: I guess that would work
03:31steel01[d]: This has been enough to get desktop gl working on lineage on the shield devices.
03:32steel01[d]: If zink or even nouveau gallium exposes the extensions, some variant of that should handle the platform side.
03:32x512[m]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30766#note_3072525
03:33steel01[d]: I feel like I'm super missing something here.
03:34steel01[d]: Using zink would mean angle isn't being used, right?
03:34steel01[d]: It gets exposed as a native gl interface?
03:35HdkR: Most companies ship native GLES drivers instead of using Angle anyway.
03:35HdkR: But Google is changing that.
03:36steel01[d]: Personally I still prefer the real EGL approach...I used to fight for that but ANGLE won't give in since folks originally brought ANGLE to Android had plumbed those already
03:36steel01[d]: But... if zink gets exposed via egl, then android shouldn't care and just handle it like it's native. That statement makes it sound like native doesn't work for zink. And I don't understand why.
03:37x512[m]: On Android libEGL handle windowing system stuff so Zink Kopper will not work.
03:38x512[m]: But Mesa EGL DRI Android WSI may work.
03:38steel01[d]: Due to hard technical limitations or unimplemented stuff?
03:39x512[m]: Due Android libEGL architecture.
03:40HdkR: Looks like AHB has some specific quirks to work around Angle specific things. So it's all WSI problems as usual :D
03:40steel01[d]: So I'm hearing that zink just doesn't work with android. So I'd be stuck with angle and the loss of desktop gl compared to the proprietary stack.
03:41steel01[d]: Or gallium nouveau which no one wants to work on.
03:41HdkR: Sounds about right.
03:41steel01[d]: Meh.
03:41x512[m]: Zink without Kopper may work on Android.
03:42HdkR: Don't most Android emulators have Vulkan renderers these days anyway? Not like GL is interesting in that ecosystem.
03:42HdkR: And not like the NVIDIA game ports will work with Mesa :P
03:43steel01[d]: My target devices are the shield tv devices and jetson devkits. Half the use case is streaming. Other half is emulators and games. And... at least in the libretro ecosystem, which I'm more familiar with, there's still notable cases where gl renderers exist and vulkan does not. Pretty sure ps1 is one such case.
03:44steel01[d]: Dolphin is another case. Last I tried, the desktop gl path was still faster than vulkan,.
03:44HdkR: Strong question there would be, is Dolphin on mesa faster under NVK or NVK+Zink. I would bet NVK alone is faster
03:45steel01[d]: But if there's no native gl and it'd be going userspace gl -> translation layer -> vulkan... yeah.
03:46steel01[d]: I should try to fire up dolphin. I got off on other stuff before trying that. 3dmark just up and crashes during startup on gallium without nvk. And the logs aren't greatly helpful as to telling why.
03:49orowith2os[d]: The question of what apps are faster under which driver setup largely depends on how efficient those renderers are, not the drivers.
03:51orowith2os[d]: You can get more performance out of a well written Vulkan renderer than a crappy GL renderer, and vice versa, more performance out of a well written gl renderer than a crappy Vulkan renderer, if both driver setups (gl and vk) are close enough in performance.
03:53HdkR: When I was working on porting Dolphin's GL renderer to GLSL, I definitely did a crappy job, it's true :)
03:54HdkR: Also, SHIELD TV drivers have been not updated in what, six years? That's a lot of progress to not have gained.
03:54steel01[d]: Oh. I didn't realize you were one of the dolphin devs. Cool.
03:55steel01[d]: Drivers? Potentially longer than that. >< Probably haven't had any real changes since O, whenever that was. Since around then, it's all been bare minimum sustainment.
03:57steel01[d]: I still don't know how the desktop gl stuff gets called in dophin. I tried to trace it a few times to debug issues in my lineage support. And my brain melted out my ears every time.
03:59mangodev[d]: HdkR: i'd think it depends on the implementation
03:59mangodev[d]: a good and well-optimized GL app will run better than an okay VK app
03:59mangodev[d]: although i'd think dolphin's VK impl is at least a 1:1 conversion of the GL stuff, rather than a new-but-worse impl
03:59steel01[d]: *googles username* Ohhhhhh... all makes sense now. I missed the multi-username part.
03:59HdkR: :D
04:00mangodev[d]: steel01[d]: i checked too
04:00mangodev[d]: they really are there
04:00mangodev[d]: they must have some good lawyers or something
04:00HdkR: steel01[d]: I wrote the GL loader, it's just eglGetProcAddress for the world.
04:01steel01[d]: I probably talked to you about stuff like eight years ago. I was trying pretty hard to keep good emulator support on lineage for the shield devices.
04:01steel01[d]: Or cm, back in the day.
04:02HdkR: mangodev[d]: I wouldn't be surprised if the VK implementation in Dolphin as better than the GL path these days, but I haven't run Dolphin in like a decade.
04:02steel01[d]: And here I am again, facing a wall of 'kernel 4.9 already shouldn't be working on current android versions', trying to keep the devices supported by getting mainline support up to snuff.
04:07HdkR: Would be nice if NVIDIA just released a new X1 class SoC. Maybe ship a next-gen Portable or Tablet then all the people holding on to X1 at least have an upgrade target.
04:07HdkR: But sadly, dreams.
04:08steel01[d]: It's called the t239. It's in the switch 2. Just gotta convince the company to do something else with the chip.
04:08HdkR: More likely to have someone crack the chip and get Linux on it :P
04:08steel01[d]: Or that. I'm down for that.
04:09HdkR: Expose a UART in some controller pins or something
04:10steel01[d]: Seems likely to me that the new joycons are still connected via serial, so... probably a thing. Flip a odm bit or two and watch the logs flow. Unless nvidia learned to lock that down. Or just remove odm bits entirely.
04:11steel01[d]: Pretty sure odmdata is still a thing on t234 at least, though.
04:29steel01[d]: [ 645.566584][ T479] drm drm: out of I/O virtual memory: -28
04:29steel01[d]: Well, that's a problem.
04:29steel01[d]: I did get dolphin to start a game, though. Forgot to turn on the fps counter, though. ><
04:32HdkR: :thonk:
04:39steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1414107854960590962/Screenshot_20250906_233849.png?ex=68be5e11&is=68bd0c91&hm=3c8d0175bf782937aff2579734307d006dc9e3b46e4fbe60b6473686b9e2566a&
04:39steel01[d]: Points for trying?
04:40steel01[d]: The intro cutscene was ~20 fps, though.
04:42HdkR: nvk in a spicy place for X1?
04:43steel01[d]: If you call 'the devs with a clue's units fail to probe' spicy. ><
04:43steel01[d]: Hopefully getting that fixed at the end of the month.
04:44steel01[d]: This is on gallium, since that's all I've got access to atm.
04:45HdkR: ah
04:45steel01[d]: It'd be sad if swiftshader was faster.
04:47HdkR: Especially on those anemic Cortex-A57 cores
04:48steel01[d]: Cpu is pegged, gpu is hanging out at 307 MHz, like fourth from the lowest. A long ways from the max. Implying the gpu just isn't getting fed nearly enough.
04:49steel01[d]: Startup did complain that most if not all of the shaders failed to compile. But then it started rendering anyways. #magic
04:49HdkR: :D
04:50steel01[d]: Not sure what it needs to compile ubershaders. Apparently gallium nouveau doesn't have it.
04:53steel01[d]: Oh hah. The gpu is only sitting at 307 MHz because the power hal sets that min for games.
04:53HdkR: :D
04:54HdkR: At least that's working
04:54HdkR: And recognizes that it is a game...?
04:54steel01[d]: Not sure how that magic works. Probably a flag in the app manifest.
05:31mangodev[d]: "game"
05:35HdkR: As soon as a game is being emulated, it evolves to its final evolution, a game.
06:55gfxstrand[d]: steel01[d]: A compiler that can reliably spill registers. 🙃
07:01gfxstrand[d]: FYI: Part of my plan post-XDC when I have a board that boots is to work with folks to come up with a proper Nouveau Android plan. This will include fixing/finishing NVK Android support and writing a Nouveau backend for minigbm that can allocate tiled buffers, among other things. I'd also like to look at our options RE Zink vs. ANGLE vs. NGL.
07:02asdqueerfromeu[d]: gfxstrand[d]: I assume you meant Android support for GeForce GPUs, right?
09:21esdrastarsis[d]: What's the current status of compression support?
15:53steel01[d]: gfxstrand[d]: Just so I have context here. Is this a another nouveau gallium issue or something more generic? Or something else entirely?
16:43marysaka[d]: steel01[d]: It uses the old compiler that isn't really great :maxpoeSweat:
17:24snowycoder[d]: I haven't seen any talk about Variable Refresh Rate, is it ever planned?
17:27snowycoder[d]: Because honestly, NVK is really solid, I got to play Silksong on release with 0 bugs and great performance.
17:27snowycoder[d]: (Except a hardware bug where the card sometimes freezes with nothing in dmesg)
17:29karolherbst[d]: needs somebody to wire it all up on the kernel side
17:29karolherbst[d]: same with hdmi 2.1 support
19:25gfxstrand[d]: steel01[d]: What marysaka[d] said. They compiler used by the old GL driver just falls over sometimes.