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

That's what both patch 5 of this series and pixman say the depth is for
bgrx8888.  I think things have only worked because nobody uses bgrx8888
with Render and also tries to do core operations with those contents,
but I think we should figure out what we actually want the behavior to
be here.

I don't think we want to define that CopyArea from XRGB8888 to BGRX8888
shifts the 24 bits of depth up by 8 within the 32bpp pixels.  One of the
options might be to say something along the lines of "core rendering
between pixmaps of different drm_fourccs is undefined".  I think
figuring out what the exact requirement would be takes a bit more
thought, though.
-------------- 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/20170727/09a7c2da/attachment.sig>