[RFC xserver v7 1/2] dri3: Add modifier/multi-plane requests, bump to v1.1

[Keith Packard]

Louis-Francis Ratté-Boulianne <lfrb at collabora.com> writes:

> +	The first list of 'drawable_modifiers' contains a set of
> +	modifiers which the server considers optimal for the window's
> +	current configuration. Using these modifiers to allocate, even
> +	if locally suboptimal to the client driver, may result in a
> +	more optimal display pipeline, e.g. by avoiding composition.

I think it would be good to explicitly mention the expected
PresentPixmap usage to describe why the window matters at
all. I didn't understand this when just reading the patch.

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


I don't like using a name here which isn't consistent with the actual
semantic. I can easily imagine reading code using this extension and
having to go find the spec to figure out what DRM_FORMAT_MOD_INVALID
could mean in this context. Can we come up with a better name than this?
DRM_FORMAT_MOD_IMPLICIT or DRM_FORMAT_MOD_DRIVER_FIGURES_IT_OUT?

> +	Synchronization of access to buffers shared between processes
> +	is not defined by this protocol. Without the use of additional
> +	extensions not defined by the DRI3 protocol as of version 1.1,
> +	synchronization between multiple processes and contexts is
> +	considered to follow the implicit model.
> +
> +	In this model, the underlying driver is responsible for
> +	enforcing a strict ordering such that any reads requested by
> +	one process or context are fulfilled before any writes requested
> +	by another process or context, as long as that read was
> +	definitively submitted before the write (e.g. a through a
> +	blocking read command such as glReadPixels or explicitly
> +	flushing the command stream through glFlush). A similar
> +	dependency exists for reads submitted after writes: the driver
> +	must ensure that the write is fully visible and coherent to the
> +	read request.

This is a great addition; i think it needs to be in a separate section
from the requests so that it can apply equally to all objects referenced
in the extension.

-- 
-keith
-------------- 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/20180227/7ff1e851/attachment-0001.sig>