<div dir="ltr"><div>I would keep the existing modifier interfaces, API extensions, and expectations the same as today for simplicity.</div><div><br></div><div><div>The new linear modifier definition (proposal) will have these fields:</div><div>   5 bits for log2 pitch alignment in bytes</div><div>   5 bits for log2 height alignment in rows<br></div><div>   5 bits for log2 offset alignment in bytes</div><div><div>   5 bits for log2 minimum pitch in bytes<br></div><div><div>   5 bits for log2 minimum (2D) image size in bytes<br></div><div><br></div></div></div><div>The
 pitch and the image size in bytes are no longer arbitrary values. They 
are fixed values computed from {width, height, bpp, modifier} as 
follows:</div><div>   aligned_width = align(width * bpp / 8, 1 << log2_pitch_alignment);<br></div><div>   aligned_height = align(height, 1 << log2_height_alignment);</div><div>   pitch = max(1 << log2_minimum_pitch, aligned_width);<br></div><div>   image_size = max(1 << log2_minimum_image_size, pitch * aligned_height);<br></div><div></div><div><br></div><div>The
 modifier defines the layout exactly and non-ambiguously. Overaligning the pitch or height is not supported. Only the 
offset alignment has some freedom regarding placement. Drivers can
 expose whatever they want within that definition, even exposing only 1 linear modifier is OK. Then, you can look at modifiers of other drivers if you want to find commonalities.<br></div><div><br></div></div><div>DRM_FORMAT_MOD_LINEAR needs to go because it prevents apps from detecting whether 2 devices have 0 compatible memory layouts, which is a useful thing to know.<br></div><div><br></div><div>Marek<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 10, 2025 at 4:23 PM James Jones <<a href="mailto:jajones@nvidia.com">jajones@nvidia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/19/24 10:03, Simona Vetter wrote:<br>
> On Thu, Dec 19, 2024 at 09:02:27AM +0000, Daniel Stone wrote:<br>
>> On Wed, 18 Dec 2024 at 10:32, Brian Starkey <<a href="mailto:brian.starkey@arm.com" target="_blank">brian.starkey@arm.com</a>> wrote:<br>
>>> On Wed, Dec 18, 2024 at 11:24:58AM +0000, Simona Vetter wrote:<br>
>>>> For that reason I think linear modifiers with explicit pitch/size<br>
>>>> alignment constraints is a sound concept and fits into how modifiers work<br>
>>>> overall.<br>
>>><br>
>>> Could we make it (more) clear that pitch alignment is a "special"<br>
>>> constraint (in that it's really a description of the buffer layout),<br>
>>> and that constraints in-general shouldn't be exposed via modifiers?<br>
>><br>
>> It's still worryingly common to see requirements for contiguous<br>
>> allocation, if for no other reason than we'll all be stuck with<br>
>> Freescale/NXP i.MX6 for a long time to come. Would that be in scope<br>
>> for expressing constraints via modifiers as well, and if so, should we<br>
>> be trying to use feature bits to express this?<br>
>><br>
>> How this would be used in practice is also way too underdocumented. We<br>
>> need to document that exact-round-up 64b is more restrictive than<br>
>> any-multiple-of 64b is more restrictive than 'classic' linear. We need<br>
>> to document what people should advertise - if we were starting from<br>
>> scratch, the clear answer would be that anything which doesn't care<br>
>> should advertise all three, anything advertising any-multiple-of<br>
>> should also advertise exact-round-up, etc.<br>
>><br>
>> But we're not starting from scratch, and since linear is 'special',<br>
>> userspace already has explicit knowledge of it. So AMD is going to<br>
>> have to advertise LINEAR forever, because media frameworks know about<br>
>> DRM_FORMAT_MOD_LINEAR and pass that around explicitly when they know<br>
>> that the buffer is linear. That and not breaking older userspace<br>
>> running in containers or as part of a bisect or whatever.<br>
>><br>
>> There's also the question of what e.g. gbm_bo_get_modifier() should<br>
>> return. Again, if we were starting from scratch, most restrictive<br>
>> would make sense. But we're not, so I think it has to return LINEAR<br>
>> for maximum compatibility (because modifiers can't be morphed into<br>
>> other ones for fun), which further cements that we're not removing<br>
>> LINEAR.<br>
>><br>
>> And how should allocators determine what to go for? Given that, I<br>
>> think the only sensible semantics are, when only LINEAR has been<br>
>> passed, to pick the most restrictive set possible; when LINEAR<br>
>> variants have been passed as well as LINEAR, to act as if LINEAR were<br>
>> not passed at all.<br>
> <br>
> Yeah I think this makes sense, and we'd need to add that to the kerneldoc<br>
> about how drivers/apps/frameworks need to work with variants of LINEAR.<br>
> <br>
> Just deprecating LINEAR does indeed not work. The same way it was really<br>
> hard slow crawl (and we're still not there everywhere, if you include<br>
> stuff like bare metal Xorg) trying to retire the implied modifier. Maybe,<br>
> in an extremely bright future were all relevant drivers advertise a full<br>
> set of LINEAR variants, and all frameworks understand them, we'll get<br>
> there. But if AMD is the one special case that really needs this I don't<br>
> think it's realistic to plan for that, and what Daniel describe above<br>
> looks like the future we're stuck to.<br>
> -Sima<br>
<br>
I spent some time thinking about this over the break, because on a venn <br>
diagram it does overlap a sliver of the work we've done to define the <br>
differences between the concepts of constraints Vs. capabilities in the <br>
smorgasbord of unified memory allocator talks/workshops/prototypes/etc. <br>
over the years. I'm not that worried about some overlap being <br>
introduced, because every reasonable rule deserves an exception here and <br>
there, but I have concerns similar to Daniel's and Brian's.<br>
<br>
Once you start adding more than one special modifier, some things in the <br>
existing usage start to break down. Right now you can naively pass <br>
around modifiers, then somewhere either before or just after allocation <br>
depending on your usage, check if LINEAR is available and take your <br>
special "I can parse this thing" path, for whatever that means in your <br>
special use case. Modifying all those paths to include one variant of <br>
linear is probably OK-but-not-great. Modifying all those paths to <br>
include <N> variants of linear is probably unrealistic, and I do worry <br>
about slippery slopes here.<br>
<br>
---<br>
<br>
What got me more interested though was this led to another thought. At <br>
first I didn't notice that this was an exact-match constraint and <br>
thought it meant the usual alignment constraint of >=, and I was <br>
concerned about how future variants would interact poorly. It could <br>
still be a concern if things progress down this route, and we have <br>
vendor A requiring >= 32B alignment and vendor B requiring == 64B <br>
alignment. They're compatible, but modifiers expressing this would <br>
naively cancel each-other out unless vendor A proactively advertised == <br>
64B linear modifiers too. This isn't a huge deal at that scale, but it <br>
could get worse, and it got me thinking about a way to solve the problem <br>
of a less naive way to merge modifier lists.<br>
<br>
As a background, the two hard problems left with implementing a <br>
constraint system to sit alongside the format modifier system are:<br>
<br>
1) A way to name special heaps (E.g., local vidmem on device A) in the <br>
constraints in a way that spans process boundaries using some sort of <br>
identifier. There are various ways to solve this. Lately the thinking is <br>
something around dma heaps, but no one's fleshed it out yet that I'm aware.<br>
<br>
2) A transport that doesn't require us to revise every userspace API, <br>
kernel API, and protocol that got revised to support DRM format <br>
modifiers, and every API/protocol introduced since.<br>
<br>
I haven't seen any great ideas for the latter problem yet, but what if <br>
we did this:<br>
<br>
- Introduced a new DRM format modifier vendor that was actually <br>
vendor-agnostic, but implied the format modifier was a constraint <br>
definition fragment instead of an actual modifier.<br>
<br>
- Constraint-aware code could tack on its constraints (The ones it <br>
requires and/or the ones it can support allocating) as a series of <br>
additional modifiers using this vendor code. A given constraint might be <br>
fragmented into multiple modifiers, but their definition and <br>
serialization/deserialization mechanism could be defined in drm_fourcc.h <br>
as macros all the clients could use.<br>
<br>
- Existing non-constraint-aware code in a modifier usage chain might <br>
filter these modifiers out using the existing strict intersection logic. <br>
Hence, any link in the chain not aware of constraints would likely block <br>
their use, but that's OK. We're muddling along without them now. It <br>
wouldn't make those situations any worse.<br>
<br>
- New code would be required to use some minimal library (Header-only <br>
perhaps, as Simon and I proposed a few years ago) to intersect format <br>
modifier lists instead, and this code would parse out the constraint <br>
modifiers from each input list and use the envisioned per-constraint <br>
logic to merge them. It would result in yet another merged <br>
modifier+constraint list encoded as a list of modifiers that could be <br>
passed along through any format-modifier-aware API.<br>
<br>
- One consideration that would be sort of tricky is that constraints are <br>
supposed to be advertised per-modifier, so you'd have to have a way to <br>
associate constraint modifiers in a given set with real modifiers in <br>
that set or in general. This is easily solved though. Some bits of the <br>
constraint modifiers would already need to be used to associate and <br>
order constraint fragments during deserialization, since modifier lists <br>
aren't strictly ordered.<br>
<br>
This effectively allows you to use format modifiers to encode <br>
arbitrarily complex constraint mechanisms by piggybacking on the <br>
existing format modifier definition and transport mechanisms without <br>
breaking backwards compatibility. It's a little dirty, because modifiers <br>
are being abused to implement a raw bitstream, but modifiers and <br>
constraints are related concepts, so it's not a complete hack. It still <br>
requires modifying all the implementations in the system to fully make <br>
use of constraints, but doesn't require e.g. revising X11 DRI3 protocol <br>
again to tunnel them through Xwayland, and in situations where the <br>
constraint-aware thing sits downstream of the non-constraint-aware thing <br>
in the allocation pipeline, you could get some benefit even when all the <br>
upstream things aren't updated yet, because it could still merge in its <br>
local constraints before allocating or passing the modifier list down <br>
the chain.<br>
<br>
Does this seem like something worth pursuing to others? I've been trying <br>
to decide how to best move the allocation constraints efforts forward, <br>
so it's potentially something I could put some time into this year.<br>
<br>
Thanks,<br>
-James<br>
</blockquote></div>