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

[Michel Dänzer]

On 26/07/17 06:20 AM, Eric Anholt wrote:
> Daniel Stone <daniels at collabora.com> writes:
> 
>> DRI3 version 1.1 adds support for explicit format modifiers, including
>> multi-planar buffers.
> 
> I still want proper 64-bit values, and I don't think the little XSync
> mess will be much of a blocker.
> 
>> Signed-off-by: Daniel Stone <daniels at collabora.com>

[...]

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


-- 
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/38c103ac/attachment-0001.sig>