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

[Michel Dänzer]

On 27/07/17 07:38 AM, Eric Anholt wrote:
> 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)

I don't see how those can both be depth 24.

> will actually shift around the bits during the copy?

Assuming they were the same depth, since CopyArea just copies the bits
verbatim, it will shift around the components for other uses which apply
the different formats to interpret the bits.


-- 
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/20170727/ca56e9c8/attachment.sig>