<div dir="auto">Hi, </div><div dir="auto">Sorry for top-posting but formatting seems to get mangled with the phone client lately, so.</div><div dir="auto"><br></div><div dir="auto">'Aux plane for alpha or transparency key maybe?' - I should've clarified aux plane usage earlier. Generally it's used as a compression status buffer (per tile - or super/super-super tile? - if it's solid or the full tile needs to be streamed), as well as things like a clear colour. That's how Intel's CCS handles it, and I understand NV do the same. There's another compression scheme from another vendor I'm not at liberty to detail, but it's similar enough wrt this protocol.</div><div dir="auto"><br></div><div dir="auto">AYUV I've only seen in the form of the FourCC of the same name, packed into 32bpp, single plane with no subsampling. I've not heard of an I420a or even NV12a. So I'll grant you that for RGB, two is enough: single plane colour, auxiliary buffer compression. But might as well just bite the bullet and make YUV a bit less insurmountable at the same time.</div><div dir="auto"><br></div><div dir="auto">I'll make sure to cover that in the dri3proto.txt update - thanks!</div><div dir="auto"><br></div><div dir="auto">Cheers, </div><div dir="auto">Daniel</div><div><br><div class="gmail_quote"><div>On Mon, 19 Jun 2017 at 7:50 pm, Adam Jackson <<a href="mailto:ajax@nwnk.net">ajax@nwnk.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2017-06-19 at 13:35 +0100, Daniel Stone wrote:<br>
> On 13 June 2017 at 21:43, Adam Jackson <<a href="mailto:ajax@nwnk.net" target="_blank">ajax@nwnk.net</a>> wrote:<br>
> > On Thu, 2017-06-08 at 19:43 +0100, Daniel Stone wrote:<br>
> > ><br>
> > > +typedef struct {<br>
> > > +    [...]<br>
> > > +    CARD32  stride0 B32;<br>
> > > +    CARD32  offset0 B32;<br>
> > > +    CARD32  stride1 B32;<br>
> > > +    CARD32  offset1 B32;<br>
> > > +    CARD32  stride2 B32;<br>
> > > +    CARD32  offset2 B32;<br>
> > > +    CARD32  stride3 B32;<br>
> > > +    CARD32  offset3 B32;<br>
> > > +    [...]<br>
> > > +} xDRI3PixmapFromBuffersReq;<br>
> > > +#define sz_xDRI3PixmapFromBuffersReq 64<br>
> ><br>
> > Why exactly four strides/offsets?<br>
><br>
> Because that's what KMS takes for AddFB2, and (not coincidentally)<br>
> what EGL_EXT_image_dma_buf_import_modifiers also defines tokens for. I<br>
> don't even know of anyone using four, which would be tri-planar Y/U/V<br>
> with an auxiliary plane. But seemed prudent to line up with the<br>
> external APIs.<br>
<br>
Aux plane for alpha or transparency key maybe? But thanks, that<br>
clarifies the intent for me. I wasn't sure whether the multiple buffers<br>
were for front/back and left/right for stereo or something. If they're<br>
for planar color then 4 is plenty unless someone wants like CMYKA or<br>
something silly like that.<br>
<br>
- ajax<br>
</blockquote></div></div>