libva
libva copied to clipboard
Support DRI3 in libva
DRI3 is the latest Direct Rendering Infrastructure. So far libva only supports DRI2. Due to lack of support for DRI3, user experienced some issues, e.g. https://github.com/01org/libva/issues/79
The main problem here is that DRI3 is not supportable with legacy Xlib because it can't pass file descriptors - XCB is required.
For XCB to work we would add a new library libva-xcb linking to XCB and containing a new function vaGetDisplayXCB() to make the VADisplay. It then needs the same arguments as DRI3Open (drawable, provider) in order to be able to open the right device.
However, at that point the library hasn't really achieved anything - the user can just call xcb_dri3_open() themselves and pass the fd to vaGetDisplayDRM() without needing the additional dependency. So, I'm not sure how useful this actually is - it can't be used with existing API, so if people want to use DRI3 then they need to add support for XCB as well, at which point it's trivial to implement the necessary behaviour directly with the existing libraries.
Yes, xcb is required, but why is a new library libva-xcb needed? We could add dri3 support in libva-x11, like as what mesa did in glx.
libva-drm is renderless, vaPutSurface() doesn't work if user calls vaGetDisplayDRM() instead of vaGetDisplay() on X11.
Not sure whether this task is already started?
@yakuizhao No. Are you interested in this task?
My understanding is that the Dri3 should work as like DRI2 except that the DRI3 is based on DRM prime_fd. And it can only work on X11 environment.
If the drm prime_fd also needs to work on vaGetDisplayDRM mode, maybe it needs to add some other mechanism to send/receive prime_fd. But this can be independent on DRI3.
This is a duplicate of issue 79.
We are in 2021 and still no DRI3 !
Any updates on this? This is needed for XWayland apps!
Any updates on this? This is needed for XWayland apps!
Note that apps can already be adopted to work on Xwayland by using libva-drm
, as pointed out in https://github.com/intel/libva/issues/122#issuecomment-331414538. That is what e.g. Firefox does and it works just fine for its use case. It also allows to have a common code path for X11 and Wayland, making porting processes easier. This does of course not work for apps relying on libva-x11
functionality.
Btw. this is indeed a duplicate of https://github.com/intel/libva/issues/79
Well, would you look at that: https://github.com/intel/libva/pull/614
#614 got merged.