[PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1

[Daniel Stone]

Hi,

On 28 July 2017 at 01:11, Keith Packard <keithp at keithp.com> wrote:
> Eric Anholt <eric at anholt.net> writes:
>> I think one option would be to have this extension create pixmaps with a
>> depth equal to the highest populated bit of the fourcc plus one.  Sure,
>> it's weird that rgbx8888 and xrgb888 have a different depth, but "depth"
>> is a pretty awful concept at this point.
>
> It's just supposed to express which bits in the pixel contribute to
> generating the resulting color; bits outside of depth 'don't matter',
> and may not even be retained. Of course, for fourcc values which spread
> 'pixel' data across multiple storage units.
>
> Sorry for not reading the whole proposal up front; I've been out
> crabbing in the San Juan's for a week and trying to catch up on email in
> the last few days...

Really can't fault your choices there.

> When I was doing Present, what I figured was that we'd define new kinds
> of read-only picture which had image storage data associated with it
> that could be in a non-pixel format -- various fourcc formats using
> multiple buffers, jpeg, png or whatever. You could use those with Render
> or Present to get data into RGB format or onto the screen. Trying to
> mash them into 'pixmaps' makes little sense.
>
> In this case, I'd imagine we'd add fourcc pictures, and a new
> DRI3PictureFromBuffers request. Adding a PresentPicture request would be
> a nice bonus feature to make sure the copy was synchronized with vblank.

Hm. I think I prefer Eric's suggestion, of just declaring this to be
undefined behaviour.

You're right that it makes little to no sense to mix the two, but I'm
not sure what practical gain we get from expressing things as
Pictures. Ultimately, the server still deals in Window Pixmaps and
Screen Pixmaps for backing storage, and the compositor interface is
NameWindowPixmap. Your suggestion of another type seems nicer, but it
doesn't look like we can avoid Pixmaps as the lowest common
denominator anyway.

By implementation if not spec, DRI3 v1.0 enforces that depth 16 is
RGB565, depth 24 is XRGB8888, and depth 32 is ARGB8888. Or at least in
Mesa: the server only supports the latter two with glamor_egl. It
seems like this has served well enough for long enough, so equally we
could just eliminate the FourCC from the protocol, stick with the
fixed depth <-> base format mapping, and encode that in the protocol
text as well.

That would much more clearly match the intention of the spec
additions, which was to allow non-linearly-addressed (Intel X/Y*,
Vivante tiled/supertiled, VC4 T-tiled, the infinite AMD/NV tiling
modes) buffers, as well as losslessly-compressed buffers (Intel CCS,
whatever Tegra calls its mode which similarly has an auxiliary buffer
to interpret the tiled primary colour buffer, ARM AFBC which is just
an inline block format). Allowing YUV buffers, attaching colourspace
information (e.g. converting between primaries/EOTF), replacing the
use of Pixmaps with another buffer type (Readable as a counterpart to
Drawable ... ?), would all be objectively good things to have, but
equally I don't think trying to fix them in a protocol which is really
just a better version of PutImage for Pixmaps is the best thing.

tl;dr: we could replace FourCC with depth as the format determinant to
better match DRI3 v1.0, or just declare that doing anything with those
Pixmaps other than displaying them to a Window with a compatible
Visual results in undefined behaviour

Cheers,
Daniel