On Wed, Dec 18, 2024 at 10:44:17AM +0100, Michel Dänzer wrote: > 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. Yeah with all other modifiers pitch alignment or other alignment/sizing requirements are generally implied. Mostly by stuff like tile size, but there's others where the hw requirement flat out is that the buffer must have a power-of-two stride (and maybe we should document these when they pop up, but the only one I know of are the legacy i915 modifiers, which are kinda busted anyway for interop). For that reason I think linear modifiers with explicit pitch/size alignment constraints is a sound concept and fits into how modifiers work overall. -Sima > > > -- > Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer > https://redhat.com \ Libre software enthusiast -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
