On Mon, Apr 22, 2013 at 10:08:47AM -0700, Eric Anholt wrote: > "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.
Ok, thanks for the explanation, I'll work on the test case then. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev