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