On Thu, Mar 17, 2016 at 03:37:16PM +0100, Jerome Glisse wrote: > What other driver do for non-buffer region is have the userspace side > of the device driver mmap the device driver file and use vma range you > get from that for those non-buffer region. On cpu access you can either > chose to fault or to return a dummy page. With that trick no need to > change kernel. Yes, this approach works for some designs however arbitrary VMA ranges for non-buffer regions is not a feature of all mobile gpu designs for performance, power, and area (PPA) reasons. > Note that i do not see how you can solve the issue of your GPU having > less bits then the cpu. For instance, lets assume that you have 46bits > for the GPU while the CPU have 48bits. Now an application start and do > bunch of allocation that end up above (1 << 46), then same application > load your driver and start using some API that allow to transparently > use previously allocated memory -> fails. Yes, you are correct however for mobile SoC(s) though current top-end specifications have 4GB/8GB of installed ram so the usable SVM range is upper bound by this giving a fixed base hence the need for driver control of VMA range. > Unless you are in scheme were all allocation must go through some > special allocator but i thought this was not the case for HSA. I know > lower level of OpenCL allows that. Subsets of both specifications allows for restricted implementation AFAIK, this proposed changes are for HSA and OpenCL up to phase 2, where all SVM allocations go via special user mode allocator. Regards, Olu -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>