07:52 Ermine: do I need to be subscribed to dri-devel to be able to post there?
08:06 emersion: no
08:07 emersion: but you can be registered and have delivery off
08:09 MrCooper: and if you're not subscribed, your posts may get delayed due to going through the moderation queue
08:30 tagr: sima: thanks, will do that
08:31 Ermine: emersion: ok, thank you, will do that
08:59 tzimmermann: jfalempe, thanks for the reviews. if nothing else comes in for the client lib, i intend to merge it by the end of the week, which should unblock drm_log
09:01 jfalempe: tzimmermann: you're welcome, and thanks for the client lib work, that's really appreciated.
12:43 zmike: daniels / MrCooper: probably one of you should take a closer look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31658
12:44 MrCooper:adds to list
16:00 zamundaaa[m]: When using writeback connectors, the WRITEBACK_PIXEL_FORMATS property only tells me what formats I can use, but not which modifiers... is it just assumed to always be linear?
16:33 emersion: zamundaaa[m]: good question
16:52 linkmauve: K900, speaking of the NPU of that SoC, I’m really unhappy with the teflon API, which depends on the Python library tflite_runtime and doesn’t expose anything to make it usable in any different library.
16:53 K900: I honestly don't know much about Teflon other than people are working on it
16:53 K900: I don't really have any use for the NPU myself
16:53 linkmauve: It is very different from OpenGL, Vulkan or any other API implemented by Mesa, which can be used by any program from a C ABI, here it exposes a single function to which you have to pass a tflite_runtime graph object and which will modify it to run parts of it on the NPU.
16:54 linkmauve: I currently would have two uses for it, automated translation and noise reduction, both of which are way too slow to do in real-time on the Cortex-A76.
16:57 linkmauve: I use tract for most of my experiments in that area, but it would have to reimplement the exact memory layout of tflite_runtime to be able to make use of teflon, which is most likely not the way forward. But I don’t think I’d be able to design a cross-vendor cross-platform cross-everything API that would allow NPUs to be exposed by Mesa to any program using a proper C ABI.
17:17 K900: Yeah, I run my 3588s as server boxes
17:17 K900: So nothing like that
17:38 Ermine: speaking of 3588s - it is served by panthor driver, right? But it doesn't expose DRIVER_MODESET nor DRIVER_ATOMIC
17:39 daniels: Ermine: yes it is panthor, it's only a GPU driver; the display driver is completely separate
17:39 daniels: on Rockchip SoCs it's rockchip-drm
17:39 daniels: (which does support atomic)
17:43 linkmauve: K900, even as a server, you might want to do automated translation for instance.
19:55 Ermine: daniels: oic
21:04 Ermine: dwfreed: ^
21:06 dwfreed: ack
21:08 Ermine: thank you
22:53 DemiMarie: jenatali: do you by any chance know what the “PCI location path” Windows uses for Discrete Device Assignment is, and if it has any analog on Linux (sysfs?)?
22:54 DemiMarie: This is somewhat on-topic because it is needed for GPU passthrough in a somewhat reasonable way.
22:54 jenatali: No idea
22:58 DemiMarie: Thanks jenatali.