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

Michel Dänzer michel at daenzer.net
Fri Jul 21 17:32:17 UTC 2017 

On 20/07/17 01:08 PM, Daniel Stone wrote:
> DRI3 version 1.1 adds support for explicit format modifiers, including
> multi-planar buffers.

Adding mesa-dev, Nicolai and Marek.

We just ran into an issue which might mean that there's still something 
missing in this v2 proposal:

The context is DRI3 PRIME render offloading of glxgears (not useful in 
practice, but bear with me). The display GPU is Raven Ridge, which 
requires that the stride even of linear textures is a multiple of 256 
bytes. The renderer GPU is Polaris12, which still supports smaller 
alignment of the stride. With the glxgears window of width 300, the 
renderer GPU driver chooses a stride of 304 (* 4 / 256 = 4.75), whereas 
the display GPU would require 320 (* 4 / 256 = 5). This cannot work.


I see two basic approaches to solve this:

1. A protocol request for the client to retrieve the display
    GPU constraints on the stride (and possibly other parameters) for a
    given format and modifier.

2. A protocol request which allows the creation of a pixmap with
    given format and modifier. The renderer GPU driver needs to pass in
    the stride it would choose, then the display GPU driver can choose a
    stride satisfying the constraints on both sides.

Maybe there are other possible approaches I'm missing? Other comments?


Relevant proposed new protocol requests quoted below for the benefit of 
mesa-dev readers:

> @@ -199,6 +202,182 @@ The name of this extension is "DRI3"
>   	associated with a direct rendering device that 'fence' can
>   	work with, otherwise a Match error results.
>   
> +┌───
> +    DRI3GetSupportedFormats
> +	window: WINDOW
> +      ▶
> +	num_formats: CARD32
> +	formats: ListOfCARD32
> +└───
> +	Errors: Window, Match
> +
> +	For the Screen associated with 'window', return a list of
> +	supported DRM FourCC formats, as defined in drm_fourcc.h,
> +	supported as formats for DRI3 pixmap/buffer interchange.
> +	The length of the list, in number of CARD32 elements,
> +	is returned in 'num_formats'.
> +
> +┌───
> +    DRI3GetSupportedModifiers
> +	window: WINDOW
> +	format: CARD32
> +      ▶
> +	num_modifiers: CARD32
> +	modifiers: ListOfCARD32
> +└───
> +	Errors: Window, Match
> +
> +	For the Screen associated with 'window', return a list of
> +	supported DRM FourCC modifiers, as defined in drm_fourcc.h,
> +	supported as formats for DRI3 pixmap/buffer interchange.
> +	Each modifier is returned as returned as a CARD32
> +	containing the most significant 32 bits, followed by a
> +	CARD32 containing the least significant 32 bits. The hi/lo
> +	pattern repeats 'num_modifiers' times, thus there are
> +	'2 * num_modifiers' CARD32 elements returned.
> +
> +┌───
> +    DRI3PixmapFromBuffers
> +	pixmap: PIXMAP
> +	drawable: DRAWABLE
> +	num_buffers: CARD8
> +	width, height: CARD16
> +	stride0, offset0: CARD32
> +	stride1, offset1: CARD32
> +	stride2, offset2: CARD32
> +	stride3, offset3: CARD32
> +	format, modifier_hi, modifier_lo: CARD32
> +	buffers: ListOfFD
> +└───
> +	Errors: Alloc, Drawable, IDChoice, Value, Match
> +
> +	Creates a pixmap for the direct rendering object associated
> +	with 'buffers'. Changes to pixmap will be visible in that
> +	direct rendered object and changes to the direct rendered
> +	object will be visible in the pixmap.
> +
> +	In contrast to PixmapFromBuffers, multiple buffers may be
> +	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.
> +
> +┌───
> +    DRI3BuffersFromPixmap
> +	pixmap: PIXMAP
> +      ▶
> +	nfd: CARD8
> +	width, height: CARD16
> +	format, modifier_hi, modifier_lo: CARD32
> +	strides: ListOfCARD32
> +	offsets: ListOfCARD32
> +	buffers: ListOfFD
> +└───
> +	Errors: Pixmap, Match
> +
> +	Pass back direct rendering objects associated with 'pixmap'.
> +	Changes to 'pixmap' will be visible in the direct rendered
> +	objects and changes to the direct rendered objects will be
> +	visible in 'pixmap' after flushing and synchronization.
> +
> +	'width' and 'height' describe the geometry (in pixels) of the
> +	logical pixel-sample source from combining the direct rendering
> +	objects.
> +
> +	'format' describes a DRM FourCC format token, with
> +	'modifier_hi' (most significant 32 bits) and 'modifier_lo'
> +	(least significant 32 bits) being combined together to produce
> +	a single unsigned 64-bit 'modifier' token. See
> +	PixmapFromBuffers for more details on DRM format definitions.
> +
> +	'nfd' describes the number of buffers returned for the pixmap,
> +	which must be combined together according to 'format' and
> +	'modifier'.
> +
> +	For each buffer, there is an entry in the 'strides',
> +	'offsets', and 'buffers' list. 'buffer' contains a single file
> +	descriptor referring to the buffer. 'stride' specifies the
> +	number of bytes per logical scanline for this plane, and
> +	'offset' specifies the distance in bytes from the beginning
> +	of 'buffer' until the start of the sample source for that
> +	plane.
> +
> +	Precisely how any additional information about the buffer is
> +	shared is outside the scope of this extension.
> +
> +	If buffers cannot be exported from the the screen associated
> +	with 'pixmap', a Match error is returned.


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

More information about the mesa-dev mailing list