On Sat, Sep 20, 2014 at 11:40 AM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: > On Sat, Sep 20, 2014 at 11:34 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: >> On Fri, Sep 19, 2014 at 3:16 PM, Rob Clark <robdclark@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
