[Mesa-dev] EXT_image_dma_buf_import for intel

[Pohjolainen, Topi]

On Mon, Apr 22, 2013 at 10:08:47AM -0700, Eric Anholt wrote:
> "Pohjolainen, Topi" <topi.pohjolainen at intel.com> writes:
> 
> > 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.
> 
> The caller of the EGL GL-texture-from-images has to set up its textures
> correctly like normal.  It could use an EGL image per miplevel to set up
> a mipmapped texture (or mix-and-match with normal texture images), or it
> can use one EGL image and set its min/mag filters appropriately.  You
> don't get any magic setting of your texture state.

Ok, thanks for the explanation, I'll work on the test case then.