multi-planar tiled fourcc's in mesa and drm

[Rob Clark]

On Sat, Sep 20, 2014 at 11:40 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Sat, Sep 20, 2014 at 11:34 AM, Rob Clark <robdclark at gmail.com> wrote:
>> On Fri, Sep 19, 2014 at 3:16 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> For the mesa part, it looks like there is a bit of work needed to
>>> teach egl about multi-planar buffers, buffers where offset[n] != 0,
>>> etc.  I'll start with patches to teach egl how to import plain NV12
>>> buffers.  But once that is done, for it to be much use to me I'll need
>>> NV12MT, which means adding a new gallium format and
>>> __DRI_IMAGE_FOURCC_NV12MT.
>>>
>>> Also, I'm still a bit undecided on how to represent multi-planar
>>> formats (ie. single pipe_resource encapsulating each of the planes?
>>> or pipe_resource per plane but teach pipe_sampler_view about textures
>>> which have multiple pipe_resource's, one for per plane).
>>
>>
>> So, on the mesa end of things, pipe_video_buffer looks like it may be
>> a better fit for an imported multi-planar format external eglimage
>> (since at least on some hw sampling a YUV buffer as a texture would
>> take multiple texture sampler slots), other than the fact that we
>> wouldn't have any codec in this case..  but does mesa state tracker
>> understand how to use a pipe_video_buffer as a sampler in a shader
>> somehow?  Right now I can only see references to pipe_video_buffer
>> from gallium video stuff.  I'd really prefer not to have to introduce
>> an extra YUV->RGB blit just to get the video frame into a form that
>> can be used from GL..
>
> You may be interested in vl_compositor.c which details with these
> pipe_video_buffer's. You can use the pipe_video_buffer's
> ->get_sampler_view_components to get the individual YUV bits (or
> whatever the format).

hmm, I suppose it is a possibility to use vl_compositor from gallium
egl bits to blit the YUV into an RGB shadow buffer, and then use that
as the eglImage.  Not exactly awesome from a memory bandwidth
perspective, and I'd need to think a bit about how the bookkeeping
would work.  But afaiu this would be allowed for external eglImages,
so I suppose it might be the best approach just to get something
working.

>>
>> How does the connection between eglImage and omx state tracker work?
>> I'm probably getting at least a bit confused by the cpp macro hell in
>> bellagio headers..

fwiw, afaict so far, the mesa omx does not support eglImage..

>> BR,
>> -R
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel