Hi, 2014-07-24 20:26 GMT+02:00 Steven Toth <st...@kernellabs.com>: >>> The only i965 driver attempt to query the >>> VASurfaceAttribExternalBuffers->num_buffers/buffers member is inside >>> i965_suface_external_memory(). >>> >>> Have I missed something important, or is this simply not possible? >>> >>> I assume DRM_PRIME or KERNEL_PRIME handles don't permit the use of >>> user allocated pointers. Correct? >> >> Correct. > > Thank you for confirming this Gwenole. > >> 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. > 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> 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). - The userptr memory need to be page aligned. - 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. > 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. :) Regards, -- Gwenole Beauchesne Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France Registration Number (RCS): Nanterre B 302 456 199 _______________________________________________ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
