Quoting Jason Ekstrand (2018-05-04 08:05:00) > On Thu, May 3, 2018 at 11:24 PM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > Quoting Scott D Phillips (2018-05-02 17:01:00) > > This series teaches anv how to pick its own virtual graphics addresses > > instead of using the relocation facility provided by the kernel. > > > > Jason Ekstrand (1): > > util: Add a virtual memory allocator > > > > Scott D Phillips (8): > > util/set: add a set_clear function > > anv: remove unused field anv_queue::pool > > anv: move canonical_address calculation into a separate function > > anv: Add vma_heap allocators in anv_device > > anv: soft pin state pools > > anv: use a separate pool for binding tables when soft pinning > > anv: elide relocations to pinned target bos > > anv: soft pin the remaining bos > > Something that I see missing from the allocator is consideration of > hugepage alignment requirements, 64k pages need 2MiB alignment, 1GiB > need 1GiB alignment. > > > The allocator takes an alignment parameter and is perfectly capable of > whatever > alignment you want. We're not using huge pages directly so I'm a bit confused > by what you're saying. Isn't this the kernel's problem? Or are we somehow > going to get better performance if we align things higher?
No, being able to use hugepages depend on setting bits in the PTE (in the GTT) at various levels, and so the hugepages also need to be aligned at the gtt_offset. Kernel problem! :-p -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
