"Pohjolainen, Topi" <topi.pohjolai...@intel.com> writes: > On Tue, Apr 16, 2013 at 01:22:22PM -0700, Eric Anholt wrote: >> Topi Pohjolainen <topi.pohjolai...@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.
pgpactbxbzCLM.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
