05:37mareko: zmike: if you run draw-prim-rate from this branch that uses mesh shaders, zink will crash radv: https://gitlab.freedesktop.org/mareko/piglit/-/commits/meshy-meshy 05:39mareko: vk_object_base_assert_valid assertion failed
10:31phasta: I think I might have discovered a new drm_sched bug. If there's no more credits in the scheduler, the run_job work item doesn't do anything. The work item will ever run again, however, if someone pushes a new job into a entity (drm_sched_wakeup()). So hypothetically you could submit work, there's no space, and then drm_sched sleeps forever if you don't submit subsequent work.
10:31phasta: https://elixir.bootlin.com/linux/v6.18-rc3/source/drivers/gpu/drm/scheduler/sched_main.c#L1241 10:31phasta: tursulin: +Cc
10:31phasta: s/ever/never
11:00kuligs2: hello, i was wondering if i could ask here about mesa/vulkan-radeon issues on linux?
11:05kuligs2: In short, i have 7900xtx, OLED tv 4k 120Hz. cnnected with DP to HDMI adapter. Using vulkan-radeon i get horizontal white line flashes/artifacting once every few seconds. Using amdvlk - all good. Archlinux, KDE, plasma wayland.
12:14phasta: kuligs2: I think they have a gitlab where you can open tickets, don't they?
12:38kuligs2: they do, and yes i opened a ticket... just thought maybe its a common issue and one one-liner away of fixing it.. but thanks for suggestion
16:56zmike: mareko: I don't see that
16:56zmike: I get
16:56zmike: draw-prim-rate: ../src/compiler/nir/nir_opt_varyings.c:4846: compact_varyings: Assertion `slot->num_slots >= 2' failed.
18:33mareko: zmike: that's fixed by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38113/diffs?commit_id=2a20e714ed6a6e87afeff9b3e6e6642497387827 18:34zmike: ah
18:34zmike: I'll test again tomorrow
18:58gfxstrand: Investigating coherency issues with nouveau on Tegra... It appears that TTM just totally ignores caching parameters on Arm
19:00alyssa: gfxstrand: probably. I don't think I'd ever heard of anyone using TTM on arm
19:00gfxstrand: Yeah. I'm very sure nouveau is the only one
19:01gfxstrand: But this really needs to be fixed for NVK. That or I commit very serious sins. :D
19:02alyssa: gfxstrand: https://c.tenor.com/-cu91ZNv1HYAAAAC/tenor.gif 19:10austriancoder: I’m looking for someone to review the gallium parts of 31512
19:19austriancoder: mareko: thx
19:28gfxstrand: alyssa: Sins comensing....
19:31alyssa: gfxstrand: https://assets.stickerswiki.app/s/frozenelsa/3338e3ab.webp 19:31gfxstrand: "Faith, why are you allocating BOs on a different DRM device?!?"
19:31gfxstrand: Shhhh! It's fine....
20:16airlied: gfxstrand: I'm pretty sure radeonsi has worked on certain ARM variants
20:17airlied: gfxstrand: but also I failed to get grace hopper working last time I tried
20:17alyssa: gfxstrand: ok that hack is really evil
20:17alyssa: thanks i hate it
20:18alyssa: take my ack and leave
20:18alyssa: :p
20:20airlied: ah I see the uma comment otherplace, indeed ttm arm uma isn't a well run quantity
20:26gfxstrand: airlied: Yes but not UMA
20:31airlied: but also ARM doesn't have as complicated crap as the x86 page tracking
20:31airlied: ttm_prot_from_caching should be all we need
20:38gfxstrand: Yeah
20:38gfxstrand: But I can't figure out where it all ties in
20:39gfxstrand: In theory, it's already doing that
20:40gfxstrand: It could also just be the map ioctl going bad
20:41airlied: x86 is complicated because you aren't allowed a cached and uncached mapping of the same phys memory, and x86 has a cached linear mapping of all memory
20:41alyssa: arm ryzen when
20:41airlied: so you have to track pages and remove them from the linear mapping etc
20:42airlied: but on arm, it should be allocate page, set pgprot for it
20:43airlied: but there is definitely some issues, I can't remember where I ended up with GH100, but I was somewhat down that rabbithole
20:44gfxstrand: Annoyingly, creating the BO on the tegra device is also faulting
20:44gfxstrand: I'm mapping it through nouveau but that should call into tegra to handle the fault
20:49airlied: sigbus on mapping or access?
20:49gfxstrand: access
20:50airlied: could be unaligned?
20:50gfxstrand: Nope. Pointer is 4k aligned and I'm doing a memset
20:50airlied: doesn't mean glibc ain't doing something dumb :-P
20:50gfxstrand: It works fine on cached maps
20:51gfxstrand: and glibc isn't making choices there
20:52airlied: so normal memory allows unaligned access, device memory doesn't
20:52gfxstrand: I guess it's possible memset is being catestrophically dumb
20:53airlied: noncached pgprot translates to a device memory
20:53airlied: MT_DEVICE_nGnRnE
20:54airlied: writecombined might work
20:54airlied: since it MT_NORMAL_NC
20:55gfxstrand: And now I got an oops
20:58gfxstrand: https://paste.centos.org/view/8dfca6b9 21:03gfxstrand: I wonder what happens if I just smash nouveau to use WC instead
21:03gfxstrand: That might be nicer
21:04gfxstrand: But also oopsing means something very bad is happening and I'm triggering it from userspace
21:09gfxstrand: The thing I did to break it harder was to write my own memcpy. :P
21:11gfxstrand: Smashed to WC instead of uncached and building
21:18gfxstrand: Okay, this is entertaining. If I run the thing that does a sigbus, it's kind of okay. If I run it in gdb, I get an oops
21:20gfxstrand: That might be a red herring
22:10gfxstrand: That took way too frickin' long but I think I'm still getting bus errors on WC
22:17gfxstrand: clearing with dwords doesn't work, either
22:18gfxstrand: I don't think it's an alignment issue
22:21gfxstrand: Actually... That might have sorted it
22:21gfxstrand: Dare I CTS this?
22:24gfxstrand: I'm gonna go home before the CTS blows up (-: