Hi Thomas, Matt and all, This came up when I port i915 svm codes to xe driver. In i915 implementation, we have i915_buddy manage gpu vram and svm codes directly call i915_buddy layer to allocate/free vram. There is no gem_bo/ttm bo concept involved in the svm implementation.
In xe driver, we have drm_buddy, xe_ttm_vram_mgr and ttm layer to manage vram. Drm_buddy is initialized during xe_ttm_vram_mgr initialization. Vram allocation/free is done through xe_ttm_vram_mgr functions which call into drm_buddy layer
to allocate vram blocks. I plan to implement xe svm driver the same way as we did in i915, which means there will not be bo concept in the svm implementation. Drm_buddy will be passed to svm layer during vram initialization and svm will allocate/free memory directly
from drm_buddy, bypassing ttm/xee vram manager. Here are a few considerations/things we are aware of:
Do you have any comment to this approach? Should I come back with a RFC of some POC codes? Thanks, Oak |