[Libva] External buffers for surfaces

[Steven Toth]

>>> On the VA-API side, what you want is userptr support
>>> (VA_SURFACE_ATTRIB_MEM_TYPE_USER_PTR).
>>
>> I did see VA_SURFACE_ATTRIB_MEM_TYPE_USER_PTR in the va headers.
>> However, I don't see any use of VA_SURFACE_ATTRIB_MEM_TYPE_USER_PTR in
>> the va-api project, or the intel-driver project other than its
>> definition, suggesting it's simply not implemented by the i965 driver.
>
> Yes, this is not implemented yet on the i965 driver because the kernel
> patches where not mainstream yet.

thx.

>
>> In fact, a quick grep of the intel driver for VA_SURFACE_ATTRIB_MEM
>> returns only  TYPE_VA, _KERNEL_DRM and _DRM_PRIME
>>
>> :(
>>
>>> However, this comes with restrictions on the driver side, and requires
>>> additional kernel patches (vmap). What specific use-cases do you want
>>> to support?
>>
>> Do you have an url to the vmap patches? and perhaps some notes on the
>> driver restrictions?
>
> AFAICS, the userptr patches seem to be integrated to intel-drm-next now:
> <http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-next>

Thanks (again).

>
> In terms of restrictions, currently spread among various minds and IRC
> logs I am afraid:
>
> - If decoding, or encoding, is involved you will always need a
> "native" VA surface. i.e. a VA surface created with 4:2:0 chroma type.
> Internally, for Intel HD Graphics hardware, this will be NV12 Y-tiled
> format. This means that if you need to get userptr allocated pages
> into the picture, you will need to use VPP to transfer from that BGRX
> to NV12 first (for encode), or from NV12 to BGRX (for decode).

Understood. We currently do this via VPP.

>
> - The userptr memory need to be page aligned.

That's ok.

>
> - I had discussed with Chris Wilson about another use-case I wanted to
> support. For legacy OpenGL (GLX): PBO-mapped to VA surface. That's not
> so simple (sync, coherency). However, Chris had produced a kernel
> patch before I leave for vacation some time ago. I will try to dig for
> a link in the IRC logs if you are interested in that.

Yes, it would be interesting to see this.

Our current application 'screen-scrapes' an OpenGL window (BGRX)
inside the Mesa surface flip function. We memcpy the content into a
shared memory segment and scheduling it for later encoding. I don't
expect us to be able to improve this, but it would be nice if the
shared memory content could be uses as existing surfaces...So a single
memcpy to pull form the opengl surface.

>
>> I have a shared memory segment between two processes, along with some
>> locking primitives and metadata. The segment is a series of BGRX
>> frames. Process A writes the pixels, Process B va-api encodes them.
>> I'd like to avoid Process B copying from the shared segment into the
>> surface for each frame, where possible.
>
> If BGRX frames refer to to OpenGL, so what I mentioned above could help. :)

Yes, its opengl.

- Steve

>
> Regards,
> --
> Gwenole Beauchesne
> Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
> Registration Number (RCS): Nanterre B 302 456 199



-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
+1.646.355.8490