[Mesa-dev] [PATCH 3/7] mesa/st: support lowering multi-planar YUV

[Rob Clark]

On Mon, Sep 12, 2016 at 9:39 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> so, fwiw, reworking __DRIImage + st_texture_object + st_texture_image
>> to have multiple resources, tacks on about another +223/-192..
>> untested (so might have missed some things.. the
>> st_texture_image/st_texture_object split is a bit fuzzy to me), and
>> haven't dropped the pipe_resource::next bit yet.  This was just to
>> give a rough idea about why I went w/ pipe_resource::next approach ;-)
>
> Oh yes that's indeed quite more churn than I thought - I didn't think
> there were both st_texture_object and st_texture_image...
> Maybe if there's only very few locations which need to know about the
> multiple planes, you could keep stObj->pt as is and use an additional
> stObj->pt23[2] or something. Albeit what you did here is cleaner.

Possibly.. although I'm not entirely sure which code paths I need to
care about (and not super-expert about the mesa classic interface so a
bit fuzzy on the _image vs _object split)..

I think I have more confidence in not having bugs in some code path or
another (maybe switching between _external and regular texture, or
some other edge case that I haven't thought of yet?) with my original
approach, since from PoV of refcnt'ing, etc, you can treat all the
chained layers as a single resource pretty much everywhere.

>> I guess Marek's idea gets a *bit* less intrusive on drivers if we
>> limit all 2 or 3 planes to have same backing dmabuf/bo, but that is
>> otherwise a restriction I'd like to not have.
>>
>> I still prefer the pipe_resource::next approach, but if others feel
>> strongly I can re-order the patches and make the YUV patch work on top
>> of the three that add multiple rsc support to
>> __DRIImage/st_texture_object/st_texture_image..
>
> I think Marek's idea to basically make those yuv planar formats
> supported gallium formats has merit if it is useful outside this egl
> misfeature. But just for this seems way complicated to me since as you
> said all drivers would need to handle it (and transfers and such look
> like needing additional work?). But the planar yuv stuff is always a
> pain to handle, keeping it out of the interface imho makes more sense.
> But maybe from a practical point of view it's not desirable...

I suppose useful to video state trackers (although I think they could
just as easily use the pipe_resource::next approach).  Might possibly
have made sense if things were initially designed this way, but with
the amount of existing state tracker and driver code, not sure if it
is worth the pain/churn of retrofitting..

BR,
-R