On Tue, Nov 15, 2016 at 1:04 PM, Marek Olšák <mar...@gmail.com> wrote: > On Tue, Nov 15, 2016 at 6:26 PM, Rob Clark <robdcl...@gmail.com> wrote: >> On Tue, Nov 15, 2016 at 12:17 PM, Marek Olšák <mar...@gmail.com> wrote: >>> On Tue, Nov 15, 2016 at 5:58 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>> On Tue, Nov 15, 2016 at 11:44 AM, Marek Olšák <mar...@gmail.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Is the modifier just a driver-specific description of the tiling >>>>> layout and compression? >>>>> >>>>> What makes you think that 8 bytes is enough to describe that? What if >>>>> I need 9 bytes just to program the display hardware? >>>>> >>>>> Drivers importing DMABUFs still have to invoke the texture tiling >>>>> calculator to get all necessary parameters for rendering (not just >>>>> display), which may even be 128 bytes per plane. >>>> >>>> fwiw, this maps 1:1 to addfb2 ioctl, and just brings egl to parity with >>>> kms. >>>> >>>> Maybe the addfb2 approach wasn't the best idea compared to some of the >>>> ideas proposed for hypothetical "liballoc" for being ultra-generic. >>>> OTOH perhaps you can just treat it like an enum? I mean maybe the set >>>> of tiled formats that you would actually exchange with another device >>>> is less than 2^^72. It seems reasonable to restrict the possible >>>> tiled formats supported by this extension to only things that can be >>>> exchanged with i965.. >>> >>> For tile modes alone, 64 bits seem enough. >>> >>> For compression, you may need a separate buffer to hold compression >>> data, so now you have to encode the tile mode and other parameters of >>> the plane, parameters of the compression buffer, and possibly also the >>> pitch and offset of the compression buffer. >>> >>> I'm not saying it can't be done, but it wouldn't be nice. >> >> Perhaps pass the compression buffer as a separate plane? Then it gets >> it's own dmabuf fd, and stride (and offset incase it really is a >> single buffer) plus 64b modifier.. > > And then I'd have to update all the window system protocols to get the > second plane for basic RGBA formats. Thank you very much, I'm not > interested.
afaiu weston already supports planar formats, and I know android does. So really only a matter of fixing x11 ;-) > Immutable metadata (modifiers) stored in the kernel is the only > scalable (and thus usable) solution here. There was an argument > against _mutable_ metadata attached to BOs and the synchronization > hell it can cause, but I've not seen any argument against _immutable_ > metadata. Trying to push the metadata (modifiers) through window > system protocols seems like a horrible idea to me, not just because of > that fact that window system protocols shouldn't care about > driver-specific stuff, but also because of the immense burden once you > realize that you have to fix all window system protocols and KMS apps > because 64 bits of metadata is not enough to support your hardware. > It's clearly not economically sustainable. > > That said, I'm OK with the patch series (I didn't read all of it - you > still need an ack from someone else), but widespread adoption of this > feature is unlikely to happen. I'm needing something like this for sharing tiled yuv buffers w/ video decoder, so even outside of window-system it has some utility. BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev