Hi, On Mon, 13 Mar 2017 at 7:08 pm, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Mon, Mar 13, 2017 at 11:53 AM, Kristian H. Kristensen < > k...@bitplanet.net> wrote: > > Daniel Stone <dan...@fooishbar.org> writes: > > > I guess it depends on how much asymmetry there is between texture and > > render formats ... if there isn't much, then we could focus on landing > > Varad's work and use that as a jumping-off point. I was under the > > impression that there was a pretty big difference for some hardware, > > though I guess the GBM implementation would still rank by optimality > > when allocating ... > > Right, but if it's more complicated than what > EGL_EXT_image_dma_buf_import_modifiers exposes, do really we want to > that logic into gbm? > > > The GBM API I was thinking of was basically a GBM version of that. The > primary addition to the above extension being some set of usage flags. > There shouldn't be a huge asymmetry between texture and render. What > concerns me more is if you tie some other API into EGL that does media or > something (OpenMAX?) you may run into issues where something works for > render but not for media decode. If we don't care about anything other > than 3D tying into EGL, then the above API should be ok. > OK, great. Let's just go with that then; I think any more complicated multi-device usecases really fall under the allocator domain, and I'd rather not reinvent that under GBM. At the moment, the only users we care about are allocating directly for scanout (so can go through GBM + GetPlane2), or solely for GPU, where EGL modifiers query + GBM allocation is fine. Cheers, Daniel
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
