libva
libva copied to clipboard
intel
add new PRIME type for more memory information
the additional memory information include memory location and some addtional information
Signed-off-by: Carl Zhang [email protected]
The intent of this is to connect to the memory_region stuff in the i915 kernel DRM driver, right? Given that it won't apply to anything other than i915, maybe that should be in the name rather than calling it DRM_PRIME_3 as if it applied to other DRM PRIME cases - something like VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME_I915_MEMORY_REGION, perhaps?
Relatedly, what lies on the other side of this API? Is there a matching OpenCL/Vulkan extension or KMS feature which accepts/provides this information?
The intent of this is to connect to the memory_region stuff in the i915 kernel DRM driver, right? Given that it won't apply to anything other than i915, maybe that should be in the name rather than calling it
DRM_PRIME_3as if it applied to other DRM PRIME cases - something likeVA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME_I915_MEMORY_REGION, perhaps?
yes, one of the reason is memory_region, but the main purpose is that OCL want us provide the memory location, want to know the surface is allocated on system memory or local memory( on chip/device memory).
new memory type always indicate new structure, right? even we use VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME_I915_MEMORY_REGION, we still need a structure, but the structure also need to contain the information already in VADRMPRIMESurfaceDescriptor. actually, I suppose we forgot to reserve some bytes in VADRMPRIMESurfaceDescriptor.
Relatedly, what lies on the other side of this API? Is there a matching OpenCL/Vulkan extension or KMS feature which accepts/provides this information?
Kernel user api does not provide a interface to query such information though a handle of buffer object. it's why I want to extend VADRMPRIMESurfaceDescriptor. about "Is there a matching OpenCL/Vulkan extension or KMS feature which accepts/provides this information?" I am not sure, need to check.