Skip to content

vkr: fallback to gbm bo import when export is not supported

Yiwei Zhang requested to merge zzyiwei/virglrenderer:gbm-alloc into master

We scope down the prior FORCE_ENABLE_DMABUF given the workaround is only required for host visible mem type, and also sanity check the externam memory export feature before force the export path.

Only non-import path is affected by this fallback:

  • drop the export info since the fd type can only be dma_buf here
  • allocate gbm bo and export a fd for import as external memory
  • track the gbm bo in vkr_device_memory
  • vkr_context_get_blob exports fd from the bo and we destroy bo here
  • vkr_device_memory_release ensures the gbm bo gets destroyed

Commits brief:

  • 1st commit is tiny fix on the sign of error return codes.
  • 2-4 commits refactor so that the special object releases are synced. The one for device memory will be enriched later thus not made inline.
  • 5-7 commits refactor so that fd export can be relocated inside vkr_device_memory with a clean interface.
  • 8th commit scopes down the prior hack to just host visible memory types and physical device supporting memory export.
  • 9th commit let vkr_physical_device track the gbm device for later gbm bo allocation and fd export.
  • 10th commit add the gbm bo import fallback path with necessary docs.

Tests passing:

No perf regressions on anv, radv since they will stay on the force dma_buf path. As tested before, there's also no perf regression even if forcing them to use the import path.

/cc @olv @ryanneph @jbates

Edited by Yiwei Zhang

Merge request reports