23:39 alyssa: how strongly do people feel in favour of extension structs for new drm uapi's?
23:39 alyssa: I know it's modelled after vulkan but also, this is my #1 complaint about vulkan's api at this point :melt:
23:40 alyssa: zero-extending seems simpler for both mesa & kernel, not sure why we need to do this dance
23:40 airlied: yeah I'm not a huge fan of them, always feel a bit over engineered, then underused
23:41 alyssa: airlied: is that a +1 from you for me ripping them out of the asahi uapi?
23:41 alyssa: (I do not want to do the work to remove them only to be told to add them back during review, lol)
23:41 airlied: are they providing value or just look nice, like we have some targetted ones that worked out, like amdgpu chunks
23:41 alyssa: so far they're not but, no crystal ball
23:42 airlied: xe does have them, maybe the intel folks could comment on if they've been useful
23:42 airlied: to me it always seems like adding a multiplexer to a multiplexer
23:42 alyssa: yeah
23:43 alyssa: with vk the one thing it can help with is having multiple unrelated different-vendor exts going in parallel
23:43 alyssa: I don't see that applying here
23:43 alyssa: except possibly if we want to like, skip unused old hardware parameters on new hw? but not sure that's worth it and would require some serious crystal ball to design properly
23:43 pinchartl: alyssa: looking at the last 20 years of V4L2 development, my best recommendation today for ioctl extension is to not over-engineer it. matching on the ioctl number without taking the size into account allows extending structs, and the kernel can easily figure out which version of the struct is used based on the size
23:44 alyssa: pinchartl: so that's another +1 for just "extend structs with zero-state-as-old-behaviour and use size"?
23:44 alyssa: (my personal preference. I just know that extension structs are trendy in DRM because of Vulkan)
23:44 pinchartl: yes, as a base rule. exceptions can be considered as needed
23:45 airlied: thellstrom, rodrigovivi : maybe you have any idea if they've been used in xe yet?
23:45 airlied: I think exec is often the one that needs something
23:46 alyssa: yeah exec is a mess on apple
23:46 alyssa: but honestly, I suspect exec needs to just be fully per-gen on apple uapi, or eat overhead from having unused fields
23:46 alyssa: (I expect big changes in m3)
23:48 pinchartl: in V4L2 we queue ISP parameters (the closest there would be to a command buffer, but it's really parameters, not commands) through a standard ioctl. the format of the buffer is driver-specific, and some drivers use an extensible format, storing data as a list of blocks, each block starting with a common header containing a type and size
23:48 pinchartl: (just food for thought, I'm not sure that would be useful in DRM)
23:51 alyssa: hmm interesting
23:51 airlied: yeah that is kinda like amd chunks I suppose
23:51 alyssa: the problem on AGX is that we have a pile of state that we need to pass to the fw
23:52 alyssa: what I'd *like* is to just have an opaque blob in the uapi and do it all in Mesa
23:52 airlied: we have a chunk id, length and data_ptr, and the kernel just adds new chuns
23:52 alyssa: but the fw<-->kernel interface is unstable and the kernel is the responsible party for abstracting over that, so the uapi has to enumerate every register explicitly so the kernel can shuffle stuff into place on submit
23:53 airlied: which has allowed exec to add sync stuff over the years without changing the fundamentals
23:53 airlied: alyssa: the kernel could provide userspace a translation table
23:53 airlied: but it would still need to deal with it I suppose for new things
23:53 alyssa: (we also don't know what unknown registers do, and it's not clear that giving userspace access to registers we don't know about is a good idea. and if the kernel needs to parse/sanitize stuff, we lose a lot of the efficiency gains)
23:54 pinchartl: alyssa: for ISPs we're repeatedly told that giving access to undocumented bits is totally fine, really, I swear, no problem can happen ever
23:55 airlied: I'd hope with apple they at least have vm protection, so it'll just crash the context, reset the GPU and won't damage other apps.
23:55 airlied: at some point you have to trust that, esp if the expose it on osx to userspace drivers
23:56 alyssa: airlied: I don't think apple does expose it to macOS userspace..
23:57 alyssa: although I don't recall the details
23:57 alyssa: pinchartl: (((:
23:57 airlied: like does metal record command buffers and those are handed directly to the fw I suppose is what I'd be asking
23:58 alyssa: I don't think it does but it's been a while
23:58 alyssa: iirc there's a synthetic kernel-parsed command buffer