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. 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. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev