[PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

[Michel Dänzer]

On 2024-12-17 12:03, Brian Starkey wrote:
> On Tue, Dec 17, 2024 at 11:13:05AM +0000, Michel Dänzer wrote:
>> On 2024-12-17 10:14, Brian Starkey wrote:
>>
>>> Modifiers are meant to describe framebuffers, and this pitch alignment
>>> requirement isn't really a framebuffer property - it's a device
>>> constraint. It feels out of place to overload modifiers with it.

FWIW, KMS framebuffers aren't the only use case for sharing buffers between devices.


>>> I'm not saying we don't need a way to describe constraints to
>>> allocators, but I question if modifiers the right mechanism to
>>> communicate them?
>> While I agree with your concern in general, AFAIK there's no other
>> solution for this even on the horizon, after years of talking about
>> it. The solution proposed here seems like an acceptable stop gap,
>> assuming it won't result in a gazillion linear modifiers.
> 
> UAPI is baked forever, so it's worth being a little wary IMO.
> 
> This sets a precedent for describing constraints via modifiers. The
> reason no other proposal is on the horizon is because describing the
> plethora of constraints across devices is a hard problem; and the
> answer so far has been "userspace needs to know" (à la Android's
> gralloc).
> 
> If we start down the road of describing constraints with modifiers, I
> fear we'll end up in a mess. The full enumeration of modifiers is
> already horrendous for parameterized types, please let's not
> combinatorially multiply those by constraints.

I agree there's a slippery slope.

That said, linear buffers are special in that they're the only possibility which can work for sharing buffers between devices in many cases, in particular when the devices are from different vendors or even different generations from the same vendor.

So as long as device vendors don't get too creative with their linear pitch alignment restrictions, it still seems like this might be workable stop-gap solution for that specific purpose alone, until a better solution for handling constraints arrives.


> P.S. "is the only modifier that has a chance of not working" is
> fundamentally false.

My reading of that part of the comment is that pitch alignment shouldn't be an issue with non-linear modifiers, since the constraints for pitch should be part of the modifier definition. Maybe that could be clarified in the comment.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast