<alyssa>
how strongly do people feel in favour of extension structs for new drm uapi's?
<alyssa>
I know it's modelled after vulkan but also, this is my #1 complaint about vulkan's api at this point :melt:
<alyssa>
zero-extending seems simpler for both mesa & kernel, not sure why we need to do this dance
<airlied>
yeah I'm not a huge fan of them, always feel a bit over engineered, then underused
<alyssa>
airlied: is that a +1 from you for me ripping them out of the asahi uapi?
<alyssa>
(I do not want to do the work to remove them only to be told to add them back during review, lol)
<airlied>
are they providing value or just look nice, like we have some targetted ones that worked out, like amdgpu chunks
<alyssa>
so far they're not but, no crystal ball
<airlied>
xe does have them, maybe the intel folks could comment on if they've been useful
<airlied>
to me it always seems like adding a multiplexer to a multiplexer
<alyssa>
yeah
knurd has joined #dri-devel
<alyssa>
with vk the one thing it can help with is having multiple unrelated different-vendor exts going in parallel
<alyssa>
I don't see that applying here
<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
<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
<alyssa>
pinchartl: so that's another +1 for just "extend structs with zero-state-as-old-behaviour and use size"?
<alyssa>
(my personal preference. I just know that extension structs are trendy in DRM because of Vulkan)
<pinchartl>
yes, as a base rule. exceptions can be considered as needed
<airlied>
thellstrom, rodrigovivi : maybe you have any idea if they've been used in xe yet?
<airlied>
I think exec is often the one that needs something
<alyssa>
yeah exec is a mess on apple
<alyssa>
but honestly, I suspect exec needs to just be fully per-gen on apple uapi, or eat overhead from having unused fields
<alyssa>
(I expect big changes in m3)
knurd has quit []
<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
<pinchartl>
(just food for thought, I'm not sure that would be useful in DRM)
knurd has joined #dri-devel
<alyssa>
hmm interesting
<airlied>
yeah that is kinda like amd chunks I suppose
<alyssa>
the problem on AGX is that we have a pile of state that we need to pass to the fw
<alyssa>
what I'd *like* is to just have an opaque blob in the uapi and do it all in Mesa
<airlied>
we have a chunk id, length and data_ptr, and the kernel just adds new chuns
<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
<airlied>
which has allowed exec to add sync stuff over the years without changing the fundamentals
<airlied>
alyssa: the kernel could provide userspace a translation table
<airlied>
but it would still need to deal with it I suppose for new things
<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)
<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
<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.
<airlied>
at some point you have to trust that, esp if the expose it on osx to userspace drivers
<alyssa>
airlied: I don't think apple does expose it to macOS userspace..
<alyssa>
although I don't recall the details
<alyssa>
pinchartl: (((:
<airlied>
like does metal record command buffers and those are handed directly to the fw I suppose is what I'd be asking
<alyssa>
I don't think it does but it's been a while
<alyssa>
iirc there's a synthetic kernel-parsed command buffer