00:00 karolherbst[d]: but also, you have ldsm and stsm which are handling bank conflicts just fine
00:01 karolherbst[d]: though might be that nvidia isn't expose those through ptx?
00:01 karolherbst[d]: *exposing
00:04 karolherbst[d]: I really need to wire up perf counters...
00:05 karolherbst[d]: we kinda have the information that we need to write performant shaders, the bigger issue is just that we don't know where our bottlenecks are
00:18 karolherbst[d]: oof.. I should read that stuff more often
00:47 steel01[d]: And if perf counters work, load based dfs isn't far behind for reclockable cards. I'm sure the desktop cards are more work than tegra, though. I was surprised how simple tegra dfs was compared to what I expected it to be.
06:11 santanaegon: I already said that some ACPI firmware likely the fw linux or something similar cracks the touchpad of 2011 macbooks. I noticed a change anyways that now to fire up the sleepping or and hibernating machine requires power button to be pushed, before any key could do it, but i am on debian bookworm. Never did any bios update, it's at stock as it was before. uefi from apple for intel i5. Yeah
06:11 santanaegon: sure i can roll back, but whatever.
06:11 santanaegon: you are endless bugworms cheaters and fraudlent tyrans in my opinion, and i do not fancy dealing with such.
06:13 santanaegon: otherwise restricting the wake up for power button only is a good idea overall.
06:15 santanaegon: intel assembly is totally irrelevant to how things later work on the stack of modern computing, it's not possible to govern my code with patents, that is also why i gave the methods overall as a teaser.
16:22 cry0xen[m]: are fermi gfx cards properly supported on wayland by nouveau drivers? nvidia isnt gonna support on 390 and 470... wondering if nouveau gonna pick that up? I was thinking whether to install wayland or x11 on a 820m laptop...
16:28 cry0xen[m]: furthermore, 820m isn't listed on nouveau website either under fermi architecture
16:30 cry0xen[m]: https://nouveau.freedesktop.org/CodeNames.html#NVC0
16:43 karolherbst[d]: steel01[d]: if you don't have to care about memory, it's relatively simple
16:43 karolherbst: cry0xen[m]: should work. "model names" are kinda weird in nvidia especially around that time
16:51 gfxstrand[d]: cry0xen[m]: Yeah, Nouveau has Fermi support and I think we can even reclock most of them. You'll be stuck on the legacy GL driver, though, which isn't great.
16:54 gfxstrand[d]: Wayland and X11 work fine
16:54 gfxstrand[d]: IDK how the display situation looks, though.
17:03 karolherbst[d]: gfxstrand[d]: not fermi
17:03 karolherbst[d]: well...
17:03 karolherbst[d]: code is kinda there to reclock the engines, but memory reclocking isn't there
17:04 karolherbst[d]: and it's disabled anyway
17:06 gfxstrand[d]: Oh. Well never mind, then.
17:10 RSpliet: There's some decade-old code in one of my guthub branches that started on fermi memory reclocking, but I never got past one card, one or two levels
17:10 RSpliet: and when I say guthub, I mean github
17:11 RSpliet: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master/
17:11 RSpliet: if anyone is so inclined, you might want to see what you can pick off there
17:17 cry0xen[m]: Okay should I just go with x11 or wayland... 820m does not have vulkan support so i am guessing some pre-2008 games run properly with wined3d
17:17 RSpliet: the odds of just grabbing those patches, forward porting them to nouveau of today, and then magically have your card change to any performance level and back is 0 though (-:
17:18 karolherbst: cry0xen[m]: ... define "game"
17:19 cry0xen[m]: like nfs most wanted 2005 or pop sand of time, arcade mame etc
17:19 karolherbst: like the only reason that 820m existed was so that somebody can plug a HDMI cable into the laptop and hope the desktop shows up. I don't think you can expect any reasonable performance out of that one
17:21 karolherbst: like even if we could change perf levels, that puts in on par with high end GPUs from 2005
17:21 karolherbst: an because nouveau can't, maybe you get the performance from 2000?
17:22 karolherbst: so while those games might run, I expect it to be super slow
17:55 asdqueerfromeu[d]: cry0xen[m]: cry0xen[m}: The first game is definitely a classic
19:19 kicchou: karolherbst[d]: i saw your message on the archive about not being subscribed to the list; i've since subscribed, so should I resubmit?
19:19 karolherbst: kicchou: nope, I let your emails through
19:19 karolherbst: they should be on the archive now
19:20 kicchou: cool, thanks
22:39 steel01[d]: Question. I see that nouveau on newer desktop cards uses zink for gl. Are there side-by-side benchmarks of that somewhere? I saw a claim that zink is faster than gallium. I... find that hard to wrap my brain around. Even taking lack of reclocking out of the picture, is gallium really that poorly written? A native driver should never be slower than a driver going through a compatibility layer to
22:39 steel01[d]: another api, when both are written ideally.
22:43 orowith2os[d]: steel01[d]: It strongly depends on the quality of the driver. For Nouveau, the Vulkan driver has far more work put into it than Nouveau-gl, and that's how it'll be, since it lessens the support load for Nouveau devs.
22:43 orowith2os[d]: nouveau-gl is only really kept around for old reference purposes (not useful for newer cards), and to support old GPUs that NVK can't support (/yet).
22:44 steel01[d]: Like tegra atm? :p
22:44 orowith2os[d]: compare that to something like radv+zink and radeonsi, where the difference between those are much bigger (but I've been dailying radv+zink for everything, for months now, without many issues.)
22:45 orowith2os[d]: steel01[d]: Probably. That and older cards, like Fermi.
22:45 karolherbst[d]: the issue with the gallium driver is, that it's just not great designed
22:45 steel01[d]: We really need to figure out why Faiths tegra boards fail to init nouveau.
22:45 karolherbst[d]: but that's also just because it's a very old driver
22:45 karolherbst[d]: the gallium one would require a full rewrite to properly make use of the hw in a performant way
22:45 steel01[d]: It's that old? Well... I suppose it is. Since it was around when gk20a was new.
22:46 karolherbst[d]: but zink is a new driver, and it's written in a way that gets more performance out of the hardware
22:46 karolherbst[d]: steel01[d]: well one of the first hw drivers
22:46 steel01[d]: Does anyone have hard number about how much performance zink shaves off ideal numbers?
22:46 orowith2os[d]: karolherbst[d]: and nobody's really interested in rewriting nouveau-gl, are they?
22:47 steel01[d]: I'm wanting to use this on the shield devices, which have some gaming use cases. It'd be nice to not lose that entirely if I get stuff to the point where I can ship android support using nouveau.
22:47 orowith2os[d]: steel01[d]: I've had only a couple FPS loss in games on my AMD laptop.
22:47 karolherbst[d]: I think nouveau initially landed in like 2007?
22:48 karolherbst[d]: orowith2os[d]: well it's quite a lot of work for almost no benefit
22:48 orowith2os[d]: much better to contribute more to zink and nvk, especially since zink work benefits multiple vendors AND nvidia, right?
22:48 karolherbst[d]: it's also already there
22:49 steel01[d]: Until an nvk dev can boot on tegra, I'm kinda screwed, though. Cause I definitely don't have the knowhow to do initial support myself. And throwing blind builds at testers just sucks.
22:49 karolherbst[d]: the thing is that a lot of the hw still needs to be understood
22:49 karolherbst[d]: and it's always a pain to integrate new findings into two drivers
22:50 karolherbst[d]: steel01[d]: it's kinda weird, because the gallium driver doesn't really do much tegra specific things
22:50 karolherbst[d]: *many
22:50 karolherbst[d]: what's the issue with tegra and nvk anyway?
22:50 orowith2os[d]: I thought the biggest difference between Tegra and desktop GPUs was the display hardware being separate from the GPU?
22:51 orowith2os[d]: (and something to do with sync. but apparently that's not a big problem?)
22:51 karolherbst[d]: well it's also an iGPU, and the UAPI is a bit in a weird state there I think?
22:51 steel01[d]: Faiths unit hang during nouveau probe. So she hasn't done initial teg tegra bringup yet.
22:51 karolherbst[d]: yeah but that has nothing to do with nvk or gallium
22:51 steel01[d]: Right. But it means the userspace dev is blocked.
22:52 orowith2os[d]: I'm gonna go ahead and @ marysaka[d], I know she did some shenanigans here.
22:52 karolherbst[d]: well the only thing I can think of is,t hat the kernel is a bit touchy in regards to memory domains
22:52 steel01[d]: Unless she wanted to do blind support and send it off to other testers like me. And I know that flow sucks having done it a couple times myself.
22:52 karolherbst[d]: and for tegra all the bos need to be placed in GART
22:53 steel01[d]: Most of my devices fire up fine. A couple of then are like 50/50 shots at hanging. And one way old prototype fails to init period.
22:54 steel01[d]: From what I hear, Mary's devkit works fine too.
22:54 steel01[d]: So... Yeah, I'm confused as to what's happening.
22:54 marysaka[d]: Probably will swap units with Faith at some point
22:55 marysaka[d]: I have two TX1 devkits working fine with nouveau so I could try to dig why her unit isn't behaving outside of L4T
22:55 marysaka[d]: maybe some kind of ODM data changing cboot behaviors or things like that
22:56 steel01[d]: The worse part is that I suggested she get a nano, and... that fails too. ><
22:56 marysaka[d]: my nano is completely busted so uum cannot test sadly
22:56 steel01[d]: Odm gets set by the flash scripts, so that shouldn't vary.
22:57 marysaka[d]: what I'm more worried is fuses
22:57 steel01[d]: I sent her my android flags package that works on my units, so... there should be zero sw difference.
22:57 steel01[d]: That... Would be possible. Something we could check, though. Downstream kernel exposes all of them.
22:57 marysaka[d]: I don't know L4T stack anyway, only ever touched NX stuffs anyway...
22:58 marysaka[d]: it could also be SMMU configuration difference I'm not too sure tbh, what would cause the variance and all
22:59 steel01[d]: I still haven't fully wrapped my brain around MMU. I also know that mainline MMU on tegra isn't great.
22:59 karolherbst[d]: I only tested on a nano and that was fine
22:59 karolherbst[d]: though I also flashed the UEFI image
22:59 steel01[d]: T194 implodes horribly if you enable MMU on the dc's.
22:59 karolherbst[d]: heh
22:59 karolherbst[d]: ~~who needs an MMU anyway~~
23:00 steel01[d]: Uefi? That'd not a t210 nano, then.
23:00 marysaka[d]: nan it's t210 nano, karol means u-boot uefi
23:00 orowith2os[d]: karolherbst[d]: manually flip the bits with a magnet and screwdriver :3
23:01 steel01[d]: marysaka[d]: Ahhhh.
23:01 steel01[d]: Native uefi was new to t194.
23:01 marysaka[d]: marysaka[d]: so in reality it's BPMP -> cboot (CCPLEX) -> terribly old atf (EL3) -> uboot
23:02 karolherbst[d]: yeah, but point is, it does work and let me boot fedora uefi aarc64 images 😄
23:02 steel01[d]: My stack uses upstream atf, fwiw. Still has issues on Faiths units.
23:02 marysaka[d]: yeah that's why I'm nore suspicious of previous payload
23:03 steel01[d]: Mmm.
23:03 steel01[d]: Ant thoughts on what I could check on my units that intermittently work and fail? Something I could start printf debugging through?
23:04 marysaka[d]: does it serror when it fails?
23:04 steel01[d]: On gk20a, I traced to the first reg access hanging. Haven't tried to step through this issue yet.
23:04 steel01[d]: No.
23:04 marysaka[d]: ah you mean tk1
23:05 steel01[d]: When I say gk20a, yes. For the rest of the conversation, the context is tx1.
23:05 steel01[d]: I've got a lot of issues. ><
23:06 steel01[d]: At least I can boot to userspace on android now. As of like 3 months ago, even that was failing. The change to allow block linear to try is what 'fixed' that.
23:10 steel01[d]: For this issue, when the failure happens, probe will hang. Then some time later, a timeout happens, which triggers a kernel panic and reboot. I haven't saved off the trace, though.
23:11 steel01[d]: It might even be watchdog kicking in.