05:15TylerPerry[m]: Hey there Are you looking for a way? A telegram game changer is here🥰 be a part of the change while the opportunity still stands! inviting you to join this on tele.. he’s doing a great job 🥰 join with this link below Are you looking for a way? WE RISE BY LIFTING OTHERS This telegram channel Has Changed The Life Of Lives out there. Don't Miss This Great Opportunity, It May Never Be There Again. Hurry up Join The
05:16TylerPerry[m]: Winning Teams And Enjoy Yourself 👇👇👇👇👇👇👇👇 https://t.me/+jLJNhUzVTUphODVk Join the telegram channel by clicking now 📣🎊❤️
05:24mangodev[d]: hmmmm
05:24mangodev[d]: i have a slight feeling this is a scam
05:25mangodev[d]: -# who falls for this 😟
05:29HdkR: Probably the same people who buy thousands of monies of gift cards and gifts them over the phone sadly.
06:47airlied[d]: So nice to just have real spam
12:21gfxstrand[d]: 🤣
13:32huntercz122[d]: how can I check if compression on nouveau works?
13:32huntercz122[d]: because there's no way minetest/luanti went from 110fps to 592fps with that PR and nouveau kernel patches
13:43huntercz122[d]: false alarm, but from 390fps, so it actually runs better
13:46huntercz122[d]: booted back to kernel with compression applied and it runs at 707fps at the same spot now damn
13:56huntercz122[d]: 105fps in Goat Simulator 3 wat
13:57mohamexiety[d]: depends on how complex the game is but if it’s fairly simple then yeah those gains are expected. it’s a huuuuuge membw amplifier
14:00mohamexiety[d]: I’ll try to sort out the kernel comments today and hopefully send a v3 today or tomorrow
14:01huntercz122[d]: 86fps with normal kernel holy moly that's a big difference
14:29esdrastarsis[d]: Maybe you can contribute to the spreadsheet
14:55gfxstrand[d]: steel01[d]: Found the bug I introduced
14:59gfxstrand[d]: and pushed
15:07gfxstrand[d]: steel01[d]: Did you push your NVK stuff somewhere or were you waiting for me to get minigbm not hosed again?
16:55steel01[d]: gfxstrand[d]: It's pushed. To my fork of the mesa repo. That's what your manifest points to. So if you run `repo sync external/mesa`, it will update only that repo. Then there's a couple other change to make the os try to use vulkan, let me go find those.
16:56steel01[d]: https://gitlab.incom.co/CM-Shield/android_external_mesa3d/-/commits/lineage-23.0?ref_type=heads
16:56steel01[d]: This is the repo fwiw, if you want to read the changes online.
16:58steel01[d]: diff --git a/properties.mk b/properties.mk
16:58steel01[d]: index 1f86cc0..5c62fea 100644
16:58steel01[d]: --- a/properties.mk
16:58steel01[d]: +++ b/properties.mk
16:58steel01[d]: @@ -55,6 +55,7 @@ PRODUCT_SYSTEM_DEFAULT_PROPERTIES += \
16:58steel01[d]: ifeq ($(TARGET_GRAPHICS),mesa)
16:58steel01[d]: PRODUCT_PROPERTY_OVERRIDES += \
16:58steel01[d]: ro.opengles.version=196610 \
16:58steel01[d]: + ro.hardware.vulkan=nouveau \
16:59steel01[d]: vendor.hwc.drm.device=/dev/dri/card0 \
16:59steel01[d]: drm.gpu.vendor_name=nouveau
16:59steel01[d]: endif
16:59steel01[d]: In device/nvidia/tegra-common. This prop tells the frameworks what vulkan hal to use.
17:00steel01[d]: Then in tegra.mk, you can set `TARGET_USES_VULKAN ?= true` alongside the minigbm flags. This will make the ui render with vulkan. So depending on what you want to test, this may need set or not. Stuff explodes more quickly with this on.
17:01gfxstrand[d]: The first one just enables Vulkan?
17:01gfxstrand[d]: so it's available for apps
17:01steel01[d]: Correct.
17:01steel01[d]: Or it 'should'. I wasn't able to run the vulkan using app I was trying to use for a test. GravityMark, specifically. It just locked up.
17:05steel01[d]: The env vars I had you set to build enables mesa nvg and nvk. Some of the existing makefiles sets ro.hardware.egl=mesa based on that. ro.hardware.vulkan is not getting set yet, hence having to set that specifically for tegra. There's a couple other env vars that can be set to shuffle egl.
17:06steel01[d]: export TARGET_GRAPHICS=mesa;
17:06steel01[d]: #export TARGET_GRAPHICS_EGL=angle;
17:06steel01[d]: #export TARGET_GRAPHICS_VULKAN=swiftshader;
17:06steel01[d]: From my build scripts. The first enables mesa and defaults egl and vulkan to mesa. You can set the second var to use angle instead of ngl for opengl. The last can switch the vulkan hal, but not sure that would be of use to you.
17:07steel01[d]: I'm not sure how nvk+zink will work. Will probably have to change the mesa gallium targets in tegra-common's BoardConfigTegra.mk.
17:32gfxstrand[d]: Yeah, I don't want to do NVK+Zink
17:32gfxstrand[d]: Not for now
17:32gfxstrand[d]: How do I get out of the "searching for accessories" thing again?
17:33gfxstrand[d]: esc did it
17:37gfxstrand[d]: Trying to build an apk to test
17:47gfxstrand[d]: Any way to disable `com.nvidia.nvaudiosvc`?
17:47gfxstrand[d]: It's spamming like mad
17:51gfxstrand[d]: Okay, I found it in system apps
18:05gfxstrand[d]: What's the `m` command to build just Mesa?
18:08steel01[d]: gfxstrand[d]: Huh, I'll have to check that. Didn't notice that before. It's part of the proprietary nvidia audio hal, fwiw. Which I'm using cause I don't have a better oss alternative atm.
18:08steel01[d]: gfxstrand[d]: `m mesa3d` will build all mesa components.
18:10steel01[d]: There's more specific targets too. Like `m vulkan.nouveau` would be just nvk. There's all the deps I can't quote off the top of my head as well.
18:12gfxstrand[d]: kk
18:13gfxstrand[d]: I've got a sascha demo crashing
18:16steel01[d]: With stack trace? That'd be better than my attempt.
18:25gfxstrand[d]: Yup. Looks like a failed kkMapMemory
18:26gfxstrand[d]: Getting some prints
18:33gfxstrand[d]: Blowing up on a coherent map. 🤡
18:34gfxstrand[d]: I'm gonna do something stupid...
18:34steel01[d]: Uh oh.
18:35steel01[d]: Is it as bad as the block linear change that got android rendering on ngl? 😛
18:35gfxstrand[d]: Exactly as bad!
18:36gfxstrand[d]: Or someone could just fix coherent maps
18:36gfxstrand[d]: That's probably a better plan
18:37steel01[d]: Just need a kernel dev to show up. Of which there's... two? left.
18:37gfxstrand[d]: barely
18:38steel01[d]: I wish that Courbot had some free time to look at stuff. But alas. At least he's getting paid to do nova now. Maybe thor+ will 'just work' there.
18:39gfxstrand[d]: The thing that really bugs me here is that nouveau has almost zero code for this
18:39steel01[d]: Still dunno if orin will get supported by nova or not. I hear that its gsp isn't really gsp.
18:39gfxstrand[d]: It's all TTM
18:40gfxstrand[d]: Which, honestly, might be the whole problem. I think nouveau is the only Arm UMA driver
18:42gfxstrand[d]: Yeah... I think that's the bug.
18:42gfxstrand[d]: I might be able to fix this
18:43steel01[d]: Oh? *fingers crossed*
18:43gfxstrand[d]: Yeah, literally all the code that touches `ttm_uncached` is inside `#define CONFIG_X86`. So that's awesome...
18:43notthatclippy[d]: steel01[d]: I don't think Orin will be supported by Nova. It's a non-trivial amount of extra work
18:45steel01[d]: notthatclippy[d]: Mmm, sad. So thor+. And given that nouveau kernel support is effectively dead, it's not going in there either. Meaning that xavier and orin will be the sad archs that never get full oss support. :sigh:
18:45notthatclippy[d]: Apart from its "GSP" being, well, not GSP, it also only handles display.
18:47notthatclippy[d]: Most of the drivering is still handled by the kernel for Orin. There's nothing to offload it to. Which means a lot of extra code in Nova that only it would use. I don't really see it..
18:48steel01[d]: Makes sense, thanks for the clarification. I'd previously only heard little comments like 'orin gsp isn't really a gsp' with no extra context.
19:30gfxstrand[d]: Okay, I'm convinced it's easier to fix NVK than TTM
19:34steel01[d]: gfxstrand[d]: And is that the 'you think you fix it' task?
19:39gfxstrand[d]: These hacks won't work on Thor but that's a problem for future me
19:59gfxstrand[d]: Ugh... Even if I allocate on Tegra, it still throws SIGBUS if I map through nouveau
20:01gfxstrand[d]: I think I need to switch back to Fedora for this
20:09steel01[d]: Probably easier to debug with a full linux cli. And without the android frameworks spamming who knows what... ><
20:11gfxstrand[d]: yup
20:19gfxstrand[d]: Ugh... No ethernet for some reason. 🙄
20:25gfxstrand[d]: I also apparently don't have USB
20:27gfxstrand[d]: Ugh... What happened?!? It was working before
20:28gfxstrand[d]: All I see on USB is two root hubs
20:30gfxstrand[d]: `[ 22.244216] WARNING: CPU: 0 PID: 580 at drivers/spi/spi-tegra210-quad.c:1248 tegra_qspi_non_combined_seq_xfer+0x1e0/0x2c0`
20:30gfxstrand[d]: 😩
20:30gfxstrand[d]: All this shit worked before
20:31gfxstrand[d]: I have a feeling the SPI driver is kind of important
20:34gfxstrand[d]: Wrong DTB
20:35gfxstrand[d]: I'm surprised I booted to GNOME with the wrong DTB. 😂
20:36steel01[d]: That is... interesting. Must not have been too wrong a dtb.
20:36gfxstrand[d]: It was the one for the nano
20:40steel01[d]: Yeah, so all the core stuff is the same. Just a few device specific things are different. A little surprised the display heads lined up, though.
22:12leftmostcat[d]: For https://gitlab.freedesktop.org/mesa/mesa/-/issues/14153, is the first approach to add a `Sign` variant to `SrcMod` and then build out a match arm for `nir_op_iadd_sat` similar to the one for `nir_op_uadd_sat` (but obviously, with the `plop3`s and correct `sel` criteria)?
22:35gfxstrand[d]: steel01[d]: I may have a kernel patch. It's CTSing as I walk home. Very narrow says it may work.
22:35gfxstrand[d]: It's one line. 🙃
22:36steel01[d]: *blink*
22:36gfxstrand[d]: I'm sure it's wrong. It has to be.
22:36steel01[d]: Well that's been par for the course for this driver.
22:36steel01[d]: Oh yeah, someone forgot a line. Now everything is 10x better.
22:37steel01[d]: Or it's been less work than expected. Like my gp10b+ dfs. Change one clock. Instead of having to track 47 different things like gm20b does. That's always nice.
22:39gfxstrand[d]: I just hate how much of a PITA developing on these things is.
22:40steel01[d]: Is it any worse than $pickanotherarmsoc?
22:45mhenning[d]: leftmostcat[d]: yes. Along with the new SrcMod variant, you'll probably also need a new SrcType variant. You'll also need to add support for the new plop3 instruction encodings in sm70_encode.rs
22:45mhenning[d]: RE'd instruction encoding is here: https://kuterdinel.com/nv_isa/PLOP3.html
22:46mhenning[d]: there are also tests for instruction encoding in nvdisasm_tests and for instruction behavior in hardware_tests
22:47mhenning[d]: If I were you, I'd probably start by adding the new PLOP3 encodings and testing with nvdisasm_tests
22:49leftmostcat[d]: Thanks. 👍
22:54gfxstrand[d]: mhenning[d]: Not sure about that. SrcType is starting to get hairy and ill-defined but I think we can still shoehorn Sign in.
22:54gfxstrand[d]: mhenning[d]: Yes to this.
22:57mhenning[d]: gfxstrand[d]: What SrcType would we use if not a new one?
22:58mhenning[d]: I agree that the representation isn't totally clear though
23:12gfxstrand[d]: Pred
23:13gfxstrand[d]: And Pred is allowed to consume a GPR if and only if it's modified with Sign
23:15gfxstrand[d]: We'd just have to be careful not to do any generic copy propagation.
23:15gfxstrand[d]: But also it might be safer to have another type
23:17gfxstrand[d]: It's got the same problem Int does. Some things take neg and some don't and it's kind of case-by-case
23:39gfxstrand[d]: `Pass: 53516, Fail: 23, Crash: 4, Skip: 64375, Timeout: 4, Flake: 78, Duration: 1:15:18, Remaining: 1:45:53` so far. Things seem to be helping but I'm not thrilled.
23:46steel01[d]: It's less bad, but it's still bad? 😛