@wpierce Thanks for your reply. However like @langdalepl I can’t see any difference, likely due to the exact operations we need to perform to make the nvidia-vaapi-driver work. Or it’s just my card, it seems to be stuck at P0 permanently.
With that said I feel I should update my original post I made 7 years ago. Since the original post was made, I release the initial version of the driver that used EGLStreams to export the buffer from NVDEC/CUDA and get it to a dma-buf. That worked ok for a while until EGLStreams was broken in your driver, and that hasn’t worked since.
Because of that we’ve had to implement a new backend to directly poke the nvidia driver to get the buffer exported. This is a fairly fragile method, although we’ve been lucky and only have it break a few times in fairly minor ways.
However over the years of operating the driver it’s become clear that NVDEC just isn’t a good API to attempt to wrap with VA-API. NVDEC isn’t designed for this sort of playback inside a security concious environment. In addition to the power usage issue, there are others too:
- An issue relating to NVDEC needing to know how many buffers/frames are needed upfront, which is the opposite to how VA-API (and VDPAU) operate which can create buffers adhoc. This can lead us to needing to allocate as many as 32 buffers, which can get expensive at higher resolutions.
- Due to how NVDEC exposes the decoded frame we need to do 2 memcpy’s to get the data out, which is really unnecessary.
- NVDEC/CUDA was never designed to run inside a sandboxed environment. My attempts to modify Firefox’s sandbox to accommodate would have significantly degraded the sandbox to the point it wouldn’t really be worth using it, hence why we’re still disabling it to this day. (I don’t really expect CUDA to work in this environment, as I say it’s just not designed for this.)
- NVDEC doesn’t work on Wayland (at least not without the hack our driver has to do to get the buffer out)
- Support for Optimus setups. To be fair, I don’t think this is an easy problem to solve.
With that said, what I would like to see is VDPAU improved. I did see some mention in one of your roadmaps about making VDPAU work with Wayland. Ideally I would love to see a function in VDPAU to export a VdpSurface as DMA-BUF (along with supplying the modifiers/stride/etc…). This isn’t difficult code to write as it’s basically what our driver is already doing. With this extra method we can use the original libva-vdpau-driver with some small changes, and will likely end up with a much nicer/more robust implementation.
I think that’s everything. I appreciate that you haven’t completely forgotten about us.
Regards
elFarto