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

[Keith Packard]

Daniel Stone <daniel at fooishbar.org> writes:

> You're right that it makes little to no sense to mix the two, but I'm
> not sure what practical gain we get from expressing things as
> Pictures.

Well, abstractly, a Picture can represent any of the formats you've
talked about -- they have explicit knowledge of color and translucency,
and already provide a notion of 'source only' objects which need not
store ARGB values for each pixel.

> Ultimately, the server still deals in Window Pixmaps and
> Screen Pixmaps for backing storage, and the compositor interface is
> NameWindowPixmap. Your suggestion of another type seems nicer, but it
> doesn't look like we can avoid Pixmaps as the lowest common
> denominator anyway.

What's the plan for compositors which just want to turn window contents
into textures? I'd assume you'd want to update them to understand the
new format bits, which leaves us free to do something sensible here.

For X-based compositors (are there any left?), we can fake out the
pixmap easily enough (NameWindowPixmap creates a suitable 'real' pixmap,
CopyArea/Composite update the source region before the copy happens).

> That would much more clearly match the intention of the spec
> additions, which was to allow non-linearly-addressed (Intel X/Y*,
> Vivante tiled/supertiled, VC4 T-tiled, the infinite AMD/NV tiling
> modes) buffers.

I'm confused -- I can't see how tiling is relevant here; if you're
storing actual ARGB pixels, even in some crazy order, then you've got a
pixmap. I have to admit that all I know about is Intel X/Y tiling
though; are there ways in which the other tiling formats don't just
store ARGB pixels?

> tl;dr: we could replace FourCC with depth as the format determinant to
> better match DRI3 v1.0, or just declare that doing anything with those
> Pixmaps other than displaying them to a Window with a compatible
> Visual results in undefined behaviour

Hrm. I think I'm stuck on the notion that Pixmaps are concrete 2D
arrays of multi-bit values.

What about calling them 'source pixmaps' and offering extended requests
to determine the precise nature of the data within? Make core requests
report correct width and height values, and then fix them at depth 24
for RGB or depth 32 for ARGB. Using them as a rendering target could
generate BadMatch, or be ignored (I'd prefer the former).

DRI3BufferFromPixmap could create a shadow 'normal' pixmap and use
Damage to sync it with the source pixmap.

Creating a Picture from a 'source pixmap' could dtrt (at least at some
point; it could also just use a shadow pixmap).

A new DRI3BufferFromSourcePixmap request would be used to get the list
of buffers and appropriate format data so that updated compositors could
get improved results.

-- 
-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/20170728/6139f2c2/attachment.sig>