01:17Lynne: airlied: nothing in dmesg
01:17Lynne: I found out that if I explicitly wait on the comamnd buffer I use to upload images, everything works fine
01:18Lynne: but why? nothing gets destroyed, nothing is threaded
03:59misyl: colinmarc: Yes, it just means fifo
06:53colinmarc: and unchecking it means mailbox? or immediate?
06:53colinmarc: oh, I see that was answered above
06:53colinmarc: thanks both!
13:02tagr: airlied, sima: I just noticed that I applied commit dc56f8428e5f34418f3243a60cec13166efe4fdb to drm-misc-next while it should've really gone into drm-misc-fixes
13:02tagr: can I just push this again to drm-misc-fixes to make sure it gets into v6.12?
14:32sima: tagr, ping the drm-misc-fixes maintainer of the release as fyi and then use the dim cherry-pick helper for consistent formatting
14:32sima: the maintainer ping is as a heads-up because cherry-pick conflicts tend to evolve into really confusing stuff with more chnages
15:02Ermine: sima: (pinging you since you're stated as a contact for dumb_map_offset TODO list entry) I want to replace dumb_map_offset implementation in virtio driver with generic one. But virtio also has an ioctl to do the same thing. Should I modify the ioctl to use drm_gem_dumb_map_offet too? If yes, then drm_gem_dumb_map_offset can return EINVAL in certain situations where virtio's
15:02Ermine: implementation, virtio_gpu_mode_dumb_mmap, doesn't. Will it constitute API break?
15:04sima: Ermine, the case for imported dma-buf? or another one?
15:06Ermine: yes, the imported one
15:06sima: yeah that's an uapi break, but it shouldn't break stuff I think
15:07sima: definitely not for the dumb_mmap
15:07sima: the entire todo is not just nice code refactor, but the goal is to make sure we have that uapi limitation consistently everywhere
15:07sima: so userspace follows the rules
15:13Ermine: Got it, thank you
17:38FireBurn: Hey, what's the correct way to report bugs for the new DRM Panic stuff?
17:41glehmann: am I missing something or does the mesa selinux option not do anything anymore except add dead meson code?
17:43Sachiel: looks that way
17:44Sachiel: well, it makes it link to libselinux too. No idea if that does some magic
18:17dj-death: are the builders disabled on MRs?
18:18dj-death: this one doesn't have any : https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/1289932
18:19jenatali: That seems bad
18:46dj-death: eric_engestrom: just noticed you added vkd3d testing on nvk, I'm wondering, is this testing only happening on valve hosted machines?
19:02dj-death: ah it's at mupuf's :)
19:02mupuf: dj-death: IOW, yeah 🤣
19:03mupuf: Although nothing prevents others to add the same job
19:05dj-death: I was wondering about having an intel one
19:05dj-death: but I guess I have to find somewhere to host it
19:18daviatorstorm: Hello guys. I'm trying to find a build for radxa 5b mesa build with vulkan 1.2. Does anyone know where I can get this?
19:19daviatorstorm: Or its better to build locally on the SBC?
19:21K900: It doesn't really exist
19:22K900: PanVK, the Vulkan driver for your GPU, is in pretty early development
19:22K900: DemiMarieObenour[m]: It's PanVK which is very WIP and I'm not sure anyone is even working on it actively
19:23daviatorstorm: I mean. There is no Vulkan driver that can work with rk3855 rock chip?
19:24K900: There is the vendor ARM one
19:25K900: But I think it only exists for Android
19:25K900: And even there it's not very good
19:25K900: You could also try building PanVK which may kinda work but that will heavily depend on your workload and you definitely shouldn't expect it to be compliant
19:25K900: Also, it's 3588
19:28daviatorstorm: I want to try start llama2 on that board and I wanted to use it through vulkan driver
19:31K900: That's definitely not happening right now
19:32K900: It's more likely there will be a proper NPU driver for it eventually
19:32K900: Because people are actually working on that
19:32daviatorstorm: There is kinda NPU support via rknn-server as i've heard
19:33daviatorstorm: but still there is no direct support of rk3855 via other AI engines
19:33K900: That's vendor stuff that I don't personally want anything to do with
19:34K900: Once Mesa gets a real NPU driver, it'll work with anything Tensorflow
19:34daviatorstorm: ic
19:34daviatorstorm: but its not in very close future as I can guess
19:36K900: It is, as far as I know, being actively worked on
19:42daniels: panvk is also being very actively worked on, but not yet at 1.2
19:42daviatorstorm: I've found this issue. That says that atleast for AI that works
19:43daviatorstorm: https://github.com/Joshua-Riek/ubuntu-rockchip/issues/888
19:50K900: Wait Asahi doesn't have preemption? Like, at all?
20:04daviatorstorm: have no idea (((