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

[Daniel Stone]

Hi,

On 28 July 2017 at 16:44, Keith Packard <keithp at keithp.com> wrote:
> 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.

Sure, but we've already managed to get this far with DRI3 and Present
only speaking Pixmaps. The point of modifiers isn't to deal with
colourspaces or anything, it's just to allow non-linear expression of
the existing formats we have today ...

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

Same as before: they call BuffersFromPixmap, instead of BufferFromPixmap.

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

So, if we take Michel's suggestion and ditch the FourCC format
completely and go back to depth, it's the same as DRI3 v1.0 in this
respect.

>> 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?

They do just store ARGB pixels. It's purely the storage and addressing
that's different, requiring either detiling or decompression to
texture from.

I'm also confused here. What I was saying is:
  - DRI3 v1.0 seems to be sufficient for linear buffers so far
  - the addition of modifiers allows explicit expression of non-linear
storage, and nothing else
  - the proposed DRI3 v1.1 spec replaced 'depth' as the determinant of
format with an explicit FourCC enum to make things more explicit
  - doing that seems to have just confused everyone, so we can make it
a lot more clear by going back to using depth to determine the format
(i.e. depth 24 == XRGB8888 storage), and only adding modifiers on top
of that

The point of these protocol additions was to allow servers to
advertise their supported storage modes to clients, so e.g. using
tiling modes between multiple GPUs becomes possible. Adding the
explicit modifier token and support for auxiliary buffers also means
that you can use lossless compression on Intel/Tegra (implemented as
tiled colour buffer + auxiliary block compression status buffer), or
other block compression modes.

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

I'm not sure what benefit this would bring. The reason I changed depth
to a FourCC wasn't because I'm desperate to support XBGR as well as
XRGB, but because a) drm_fourcc.h modifier tokens are usually paired
with drm_fourcc.h format tokens, and b) currently with DRI3 v1.0,
there is an implicit hardcoded mapping between depth and format, and
being more explicit seemed better than being implicit. Those two are
purely cosmetic though, so going back to the DRI3 v1.0 scheme of just
using depth rather than a FourCC format would perhaps make the intent
a bit more clear. Also, the XRGB8888/ARGB8888 format restrictions
don't seem to be biting anyone: I haven't seen any demand for extended
formats.

As far as creating new SourcePixmaps with shadow Pixmaps etc goes, I'm
not sure what we gain by the type indirection. If you want to forbid
rendering to client-created buffers passed to the server over DRI3
(currently just Pixmaps), why not just document that doing so results
in undefined behaviour? That can be BadMatch, that can be rendering
ignored, that can be your Pixmap/buffer full of junk. (Also, I'm not
sure why we'd hook up Damage if we're to forbid using it as a
rendering target ... ?)

Present would also need to gain a PresentSourcePixmap (or
PresentPicture, or?) request here. Again I'm not sure what gain we
really get from all the typing ... am I missing something?

Cheers,
Daniel