[Mesa-dev] EXT_image_dma_buf_import for intel

[Eric Anholt]

"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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130422/508b6db7/attachment.pgp>