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

[Michel Dänzer]

On 26/07/17 10:48 AM, Michel Dänzer wrote:
> On 26/07/17 06:20 AM, Eric Anholt wrote:
>> Daniel Stone <daniels at collabora.com> writes:
>>
>>> +	combined to specify a single logical source for pixel
>>> +	sampling: 'num_buffers' may be set from 1 (single buffer,
>>> +	akin to PixmapFromBuffer) to 4. This is the number of file
>>> +	descriptors which will be sent with this request; one per
>>> +	buffer.
>>> +	
>>> +	The exact configuration of the buffer is specified by 'format',
>>> +	a DRM FourCC format token as defined in that project's
>>> +	drm_fourcc.h header, in combination with the modifier.
>>> +
>>> +	Modifiers allow explicit specification of non-linear sources,
>>> +	such as tiled or compressed buffers. 'modifier_hi' (the most
>>> +	significant 32 bits of a 64-bit value) and 'modifier_lo' are
>>> +	combined to produce a single DRM format modifier token, again
>>> +	as defined in drm_fourcc.h. The combination of format and
>>> +	modifier allows unambiguous declaration of the buffer layout
>>> +	in a manner defined by the DRM tokens.
>>> +
>>> +	DRM_FORMAT_MOD_INVALID may be passed for 'modifier', in which
>>> +	case the driver may make its own inference as to the exact
>>> +	layout of the buffer(s).
>>> +
>>> +	'width' and 'height' describe the geometry (in pixels) of the
>>> +	logical pixel-sample source.
>>> +
>>> +	'strideN' and 'offsetN' define the number of bytes per logical
>>> +	scanline, and the distance in bytes from the beginning of the
>>> +	buffer passed for that plane until the start of the sample
>>> +	source for that plane, respectively for plane N. If the plane
>>> +	is not used according to the format and modifier specification,
>>> +	both values for that plane must be zero.
>>> +
>>> +	Precisely how any additional information about the buffer is
>>> +	shared is outside the scope of this extension.
>>> +
>>> +	If the buffer(s) cannot be used with the screen associated with
>>> +	'pixmap', a Match error is returned.
>>> +
>>> +	If the format and modifier combination is not supported by the
>>> +	screen, a Value error is returned.
>>
>> Should we be specifying how the depth of the Pixmap is determined from
>> the fourcc?  Should we be specifying if X11 rendering works on various
>> fourccs, and between pixmaps of different fourccs?  It's not clear to me
>> what glamor would need to be able to do with these pixmaps (can I
>> CopyArea between XRGB888 and BGRX8888?  What does that even mean?)
> 
> X11 pixmaps provide storage for n bits per pixel, where n is the pixmap
> depth. CopyArea between pixmaps just copies the bits in the source to
> the destination verbatim. Note that this is only possible if both
> pixmaps have the same depth.

This raises a question about multi-plane (e.g. YUV) formats, where
different planes may have different resolutions. Is this functionality
intended to be used for such formats? If so, how are X11 drawing
operations to/from pixmaps created from such formats envisioned to work?


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 224 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170726/b3ed3658/attachment.sig>