Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • V virglrenderer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 88
    • Issues 88
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 35
    • Merge requests 35
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • virgl
  • virglrenderer
  • Merge requests
  • !651

vkr: Support import/export of host memory with opaque fd

  • Review changes

  • Download
  • Patches
  • Plain diff
Merged Omar Akkila requested to merge rakko/virglrenderer:opaque-fd-vkr-ctx0 into master Nov 22, 2021
  • Overview 165
  • Commits 4
  • Pipelines 52
  • Changes 12

The primary motivation here is to allow virglrenderer to be able to interop with host vulkan drivers that support VK_KHR_external_memory_fd but not VK_EXT_external_memory_dma_buf (For example, and more specifically, lavapipe).

Having virglrenderer work with lavapipe would enable the mesa venus driver to be tested within the mesa CI against deqp-vk.

Running deqp-vk against venus/corsvm/virglrenderer in the CI lead to numerous failures due to the lack of support for mapping any host device memory that isn't through dma_buf.

This series of patches seeks to implement support both the export and import of host memory through an opaque fd.

For blob mapping, without access to the context with which the blob was created, a separate, dedicated context is created to handle importing the blob and returning a host pointer back to the guest.

I am opening the MR to allow for comments and feedback on the approach so far and if improvements could be made in other areas.

Edited Jan 28, 2022 by Omar Akkila
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: opaque-fd-vkr-ctx0