[Mesa-dev] EXT_image_dma_buf_import for intel

[Pohjolainen, Topi]

On Tue, Apr 16, 2013 at 01:22:22PM -0700, Eric Anholt wrote:
> Topi Pohjolainen <topi.pohjolainen at intel.com> writes:
> 
> > The set introduces new target for 'eglCreateImageKHR()' allowing one
> > to create EGL images out of externally allocated buffers. Especially
> > one can combine up to three separate buffers into one single logical
> > entity. Low level native buffers may not support planar formats and
> > hence EGL layer will instead combine native buffers each representing
> > a single plane into one planar image.
> >
> > Until now an image in intel dri backend consisted of a single region.
> > Here this is extended to accomodate YUV formats having each component
> > in its own plane, but intended only for images that are to be bound
> > as textures later on.
> >
> > As such the images are not much of use, but combined with the logic
> > (OES_external_image) allowing one to create textures out of these
> > images, one can start directly sampling the underlying buffers.
> 
> This seems the non-planar parts (certainly formats like
> DRM_FORMAT_ARGB8888) ought to be testable immediately using the existing
> GL_OES_EGL_image support.

I took a look at this and after some studying I realized that I need some
advise. Providing an EGL image created out of a dma buffer (having fourcc
format __DRI_IMAGE_FOURCC_ARGB8888) needs special handling in the intel_screen:

The hook 'intel_setup_image_from_fds()' would need to set the currently
ignored fields of __DRIImage (width, height, tile_x/y, format) in order for the
logic later on in 'intel_set_texture_image_region()' to be able to do its
thing.

The result, however, is not enough for '_mesa_test_texobj_completeness()' which
fails to find an image for level one - which is to be expected, right? The
original dma buffer has only the zero level. 
The incompletenss finally causes the updating of the texture state (just before
kicking off the rendering) to fail in '_mesa_test_texobj_completeness()' as the
_MipmapComplete flag is down for the texture. And then one falls back to the
1x1 default texture ignoring the dma buffer texture altogether.


Would the texture completeness logic need to be content with level-zero mipmaps
for TEXTURE_2D targets or am I misunderstanding something else? I can think of
a few things to bend but I don't what is the right thing to do.

-Topi