On 4 March 2015 at 05:23, Chad Versace <chad.vers...@intel.com> wrote: > On 03/03/2015 11:13 AM, Dave Airlie wrote: >> On 4 March 2015 at 05:06, Chad Versace <chad.vers...@intel.com> wrote: >>> On 03/03/2015 11:01 AM, Daniel Stone wrote: >>>> Hi, >>>> >>>> On 3 March 2015 at 18:40, Chad Versace <chad.vers...@intel.com> wrote: >>>>> On 03/03/2015 12:13 AM, Daniel Stone wrote: >>>>>> On Tuesday, March 3, 2015, Dave Airlie <airl...@gmail.com >>>>>> <mailto:airl...@gmail.com>> wrote: >>>>>> + EGLBoolean eglExportDMABUFImageQueryMESA(EGLDisplay dpy, >>>>>> + EGLImageKHR image, >>>>>> + int *fourcc, >>>>>> + int *num_planes); >>>>>> >>>>>> >>>>>> Shouldn't this contain the modifier(s) as well? >>>>> >>>>> What is the motivation for defining two export calls, and exporting >>>>> a subset of information from each call? I don't understand why the >>>>> fourcc values are exported by one call, but the strides exported a >>>>> separate call. >>>> >>>> Querying the image gives you what you need in order to know if you can >>>> actually deal with the image, before you go to all the effort of >>>> exporting it. >>> >>> Thanks. That makes sense. >> >> Also you need the number of planes to correctly size the arrays for >> the second call to put the results into. > > Right, I understood that you needed to know the number of planes before > submitting the array. I was mostly confused by why fourcc was in this call, > not num_planes. > > My real feedback: It's probably best to rename num_planes to num_fds, > because you're not guaranteed num_fds != num_planes for interleaved formats. > And, using the name 'num_fds' allows us to avoid awkwardness if we need to > create future layered extensions > that export auxilliary buffers that may not correspond YUV planes. (There's > been a lot of lunch talk about exporting aux buffers at Intel).
But num_planes sizes fds, strides and offsets, which seems like we should either just return the same fd for each plane or one fd in slot0 and -1, -1 in the others if we need one fd per multi-planar.. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
