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