On Mon, Mar 13, 2017 at 11:53 AM, Kristian H. Kristensen <k...@bitplanet.net> wrote:
> Daniel Stone <dan...@fooishbar.org> writes: > > > Hey Kristian, > > > > On 13 March 2017 at 17:31, Kristian H. Kristensen <k...@bitplanet.net> > wrote: > >> Jason Ekstrand <ja...@jlekstrand.net> writes: > >>> I was talking to Daniel today and I think we also need another some > sort of > >>> GL or GBM api that gives you the modifiers supported for > >>> rendering/texturing. One option would be a gbm_get_modifiers_for_use() > >>> entrypoint that takes a usage and gives you a set of modifiers that's > >>> guaranteed to work for that usage. For scanout, it would return > LINEAR, X, > >>> and Y on SKL+ and LINEAR and X on BDW-; it wouldn't return CCS because > that > >>> only works on a limited number of planes. I say this now because we > may > >>> want to do that with the same DRI version bump as the rest of it. > >> > >> Are you aware of > >> > >> https://www.khronos.org/registry/EGL/extensions/EXT/ > EGL_EXT_image_dma_buf_import_modifiers.txt > >> > >> If you talked to Daniel, he probably brought it up - what's missing? > Hey, Look! An API! That appears to mostly do what we want. > > 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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
