Gurchetan Singh 64182afb63 devices: gpu: complete investigation of udmabuf driver ... Hello everyone ..! After 2.5 years of "on the side" inquiries, I have finally completed my investigations [1] of the udmabuf!! udmabuf is a kernel driver that turns memfd pages into dmabufs. The original hope was it would reduce texture upload costs for virgl, which it did for larger textures [2]. But no measurable improvements where seen with real games. In addition, a more advanced "gfx-streaming" model has since come into the horizon[3][4], which is more performant, conformant, secure and simpler than virgl. As such, building more on virgl does not seem to be best option, but that's another story for another day. Where does that leave udmabuf, then?!? The investigation was able to turn up two possible use cases: 1) Intel integrated + dGPU PCI-passthrough resource sharing When the dGPU is passthroughed into the guest, the dGPU's memory is not available to the host. Ideally, for zero-copy, we would like to get the render target out of the guest somehow and then send to the display. Many approaches have been proposed, such as Vivek Kasireddy's Vdmabuf driver [5]. The current thinking is virtgpu guest blobs can be exported, and then imported into the dGPU -- Vivek is looking into this approach right now ..!! Sommelier or virtgpu KMS can then share the guest blob with the host. It's a quite complex use case and requires changes to guest Mesa GBM to get (such as metadata query) to get the right modifier. Indeed, some would even say you need a virtgpu context type optimized for sharing across domain boundaries. minigbm already supports this for Android upstream's Virtual Graphics Interface (VGI) initiative. 2) Guest VRAM dedicated heap created udmabufs This use case, proposed by automative virtualization expert Dmitry Sepp [6], is primarily for automotive hypervisors (such COQOS). It's typically not easy for such hypervisors to get zero-copy via BLOB_MEM_HOST3D, and these hypervisors have had their homebrew versions of udmabuf for many years. It's important to upstream the workarounds that are currently done for such hypervisors. To increase security and isolation, a guest dedicated heap is preferred over guest system memory. We might even need dedicated queues, who knows. crosvm seems like the most likely upstream target due to it's world class blob support and open-source nature. As such, this CL adds basic udmabuf capabilites so these use cases can be developed further via crosvm. [1] https://www.youtube.com/watch?v=lp6z3s1Gig0 [2] crrev.com/c/1325515 [3] goto.google.com/address-space-graphics [4] https://drive.google.com/file/d/19K_6M8QUeOn-x7HVYvoNfnuC6G5vkR8f/view [5] https://lists.freedesktop.org/archives/dri-devel/2021-February/296177.html [6] https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/159 BUG=chromium:892806, b:173630595 TEST=Create a bunch of udmabufs from the guest, with the subsequent patches Change-Id: Ia8083c0aa065f303f660ec6875ff5fb76f5d7b4f Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786290 Tested-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>		2021-03-30 16:42:03 +00:00
..
src	devices: gpu: complete investigation of udmabuf driver	2021-03-30 16:42:03 +00:00
.build_test_serial	devices: Add simple test for proxy device	2020-11-17 21:05:51 +00:00
Cargo.toml	crosvm: Keep memfd alive when creating new process	2021-03-30 16:42:01 +00:00