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

[Eric Anholt]

Michel Dänzer <michel at daenzer.net> writes:

> [ Unknown signature status ]
> 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.

Right.  So is the plan that XRGB888 to BGRX8888 (both depth 24) will
actually shift around the bits during the copy?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170726/d773dca9/attachment.sig>