[Mesa-dev] [RFC] OES_external_image for i965

Kristian Høgsberg krh at bitplanet.net
Mon Mar 4 06:56:34 PST 2013

On Mon, Mar 4, 2013 at 4:55 AM, Pohjolainen, Topi
<topi.pohjolainen at intel.com> wrote:
> On Fri, Mar 01, 2013 at 10:03:45AM -0500, Kristian H?gsberg wrote:
>> On Fri, Mar 1, 2013 at 3:51 AM, Pohjolainen, Topi
>> <topi.pohjolainen at intel.com> wrote:
>> > On Tue, Feb 26, 2013 at 04:05:25PM +0000, Tom Cooksey wrote:
>> >> Hi Topi,
>> >>
>> >> > The second more or less questionable part is the support for creating YUV
>> >> > buffers. In order to test for YUV sampling one needs a way of providing them
>> >> > for the EGL stack. Here I chose to augment the dri driver backing gbm as I
>> >> > couldn't come up with anything better. It may be helpful to take a look at the
>> >> > corresponding piglit test case and framework support I've written for it.
>> >>
>> >> You might want to take a look at the EGL_EXT_image_dma_buf_import[i] which has been written
>> >> specifically for this purpose. Though this does assume you have a driver which supports exporting a
>> >> YUV buffer it has allocated with dma_buf, such as a v4l2 driver or even ion on Android.
>> >>
>> >
>> > It certainly looks good addressing not only the individual plane setup but
>> > allowing one to control also the conversion coefficients and subsampling
>> > position.
>> > Coming from piglit testing point of view, do you have any ideas where to
>> > allocate the buffers from? I guess people wouldn't be too happy seeing v4l2 tied
>> > into piglit, for example.
>> SInce you're already using intel specific ioctls to mmap the buffers,
>> I'd suggest you just go all the way and allocate using intel specific
>> ioctls (like my simple-yuv.c example).  I don't really see any other
>> approach, but it's not pretty...
> I used gbm buffer objects in order to match the logic later in
> 'dri2_drm_create_image_khr()' which expects the buffer to be of the type
> 'gbm_dri_bo' (gbm_bo) for the target EGL_NATIVE_PIXMAP_KHR. Giving drm buffer
> objects instead would require new target, I guess?

Right... I'd use the extension Tom suggests:


which is mostly implemented by this patch:


with just the EGL extension bits missing.  That way, you're also not
dependent on any specific window system.  As it is your test has to
run under gbm, using the dmabuf import extension it can run under any
window system.


More information about the mesa-dev mailing list