On Mon, Sep 12, 2016 at 9:39 PM, Roland Scheidegger <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
