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

[Michel Dänzer]

On 28/07/17 05:03 PM, Daniel Stone wrote:
> 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.

Declaring where? Once a pixmap is created, it only has a depth, no
format, so there's nothing to base on that e.g. CopyArea between two
pixmaps of the same depth is undefined.


> 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.

No, it doesn't. How the bits stored in a pixmap are interpreted is
outside of the scope of DRI3 1.0.


> 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

I'm getting less and less convinced that any reference at all to formats
in the context of pixmaps in the DRI3 specification is a good idea.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer