[Mesa-dev] [v6 2/9] intel: do not create renderbuffers out of planar images

[Daniel Vetter]

On Thu, May 30, 2013 at 9:49 AM, Pohjolainen, Topi
<topi.pohjolainen at intel.com> wrote:
> On Tue, May 28, 2013 at 01:33:18PM -0700, Eric Anholt wrote:
>> Topi Pohjolainen <topi.pohjolainen at intel.com> writes:
>>
>> > Signed-off-by: Topi Pohjolainen <topi.pohjolainen at intel.com>
>> > ---
>> >  src/mesa/drivers/dri/intel/intel_fbo.c | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c b/src/mesa/drivers/dri/intel/intel_fbo.c
>> > index 69f8629..7ccbaa8 100644
>> > --- a/src/mesa/drivers/dri/intel/intel_fbo.c
>> > +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
>> > @@ -280,6 +280,10 @@ intel_image_target_renderbuffer_storage(struct gl_context *ctx,
>> >     if (image == NULL)
>> >        return;
>> >
>> > +   /* Planar buffers are not supported as render targets. */
>> > +   if (image->planar_format && image->planar_format->nplanes > 1)
>> > +      return;
>> > +
>> >     /* __DRIimage is opaque to the core so it has to be checked here */
>> >     switch (image->format) {
>> >     case MESA_FORMAT_RGBA8888_REV:
>>
>> OK, this answers one question I had about what our support was going to
>> be.  But what about glEGLImageTargetTexture2DOES()?
>>
>> Are we only going to support planar textures with image_external?  My
>> thought is "yes".  How about on HSW with the YUV sampler support?  Are
>> we going to relayout the data in the incoming fds to a copy that can
>> support sampling from them, or are we going to reject incoming fds that
>> don't fit the required layout?  And if we decide to reject anything, are
>> we going to reject it at the or the dmabuf_import stage or the
>> image_external stage?
>
> I was also thinking that planar would be supported only by image_external, and I
> hadn't even thought about HSW yet.
>
> Clearly I haven't been thinking as far as you, I thought that images can be
> created relatively freely - it would be their uses that would fail if not
> supported. But this is wrong I guess. Once an image is created it should be
> guaranteed to be usable for quite a number of things.
>
> Having said that I realize that I don't most likely know enough about all the
> ways images can be used so that I could introduce proper constraints to the
> image creation logic.

I guess we have two questions here: The first is deciding where we
fail the import process if the client api can't directly access the
data in the imported dma_buf. I think it's better to fail late since
doing all possible checks at egl image creation time might be ugly and
too restrictive. Otoh failing late will make it even harder for
applications to figure out what's possible.

The other questions is who will be responsible for copying. Doing any
kinds of transparent relayouting (e.g. when resampling a planar yuv
with oes image external to something a hw sampler could directly cope
with in case of a mismatch) doesn't sound too good: It'll break users
if they try to re-use dma_bufs/egl_images and the client api objects
created from them. So we might want to disallow any kind of egl image
orphaning and any other non-zero-copy conversion for images backed by
dma_bufs. Otoh this could get really ugly if we add a egl_image ->
dma_buf export extension.

If we go with the "no orphaning for dma_buf backed egl_image" we could
make the copying somewhat more explicit with something like the egl
streams stuff. I haven't read the spec for that closely yet, but
having a solid zero-copy guarantee with making copying explicit sounds
good to me. Also, to better cope with interop issue we could guarantee
that every egl image which can be imported can at least be
hw-resampled into something useful. That way failing the
dma_buf->eg_image step still gives a useful piece of information to
users.

Since this sounds like a spec question cc'ing all the people from the
original dma_buf_import spec discussions.

Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch