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