On Thu, Nov 28, 2019 at 02:12:30PM +0200, Joonas Lahtinen wrote:
Quoting Niranjan Vishwanathapura (2019-11-27 21:23:56)
>We should try to have the uAPI as final as early as possible. The
>change process is harder the later it is done, even for RFC :)
>
>On the same note, I'm inclined to have I91
Quoting Niranjan Vishwanathapura (2019-11-27 21:23:56)
> >We should try to have the uAPI as final as early as possible. The
> >change process is harder the later it is done, even for RFC :)
> >
> >On the same note, I'm inclined to have I915_SVM_MIGRATE called
> >I915_GEM_VM_PREFAULT from the start,
On Tue, Nov 26, 2019 at 03:59:31PM +0200, Joonas Lahtinen wrote:
Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)
On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
>Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
>> Shared Virtual Memory (SVM) runtime allocator support
Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)
> On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
> >Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
> >> Shared Virtual Memory (SVM) runtime allocator support allows
> >> binding a shared virtual address to a buffer objec
On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
Shared Virtual Memory (SVM) runtime allocator support allows
binding a shared virtual address to a buffer object (BO) in the
device page table through an ioctl call.
The ioctl
Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
> Shared Virtual Memory (SVM) runtime allocator support allows
> binding a shared virtual address to a buffer object (BO) in the
> device page table through an ioctl call.
The ioctl though is not svm specific, it is to do with "bulk residency
