[Mesa-dev] [RFC] OES_external_image for i965

[Kristian Høgsberg]

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...

Kristian

>> [i] http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>>
>>
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev