On 16/07/2020 01:43, Dave Airlie wrote:
On Wed, 15 Jul 2020 at 00:35, Matthew Auld <matthew.auld@xxxxxxxxx> wrote:
On 13/07/2020 06:09, Dave Airlie wrote:
On Fri, 10 Jul 2020 at 22:00, Matthew Auld <matthew.auld@xxxxxxxxx> wrote:
We need to add support for pwrite'ing an LMEM object.
why? DG1 is a discrete GPU, these interfaces we already gross and
overly hacky for integrated, I'd prefer not to drag them across into
discrete land.
same goes for pread.
You have no legacy userspace here, userspace needs change to support
LMEM, it can be fixed to avoid legacy ioctls paths.
Ok, there have also been similar discussions internally in the past. I
think one of the reasons was around IGT, and how keeping the
pread/pwrite interface meant slightly less pain, also it's not much
effort to implement for LMEM. If this is a NACK, then I guess the other
idea was to somehow fallback to mmap and update IGT accordingly.
I just don't think we should have internal kernel interfaces for
mapping ram in the kernel address space, seems pointless, makes less
sense with a discrete GPU in the mix, so yes I think NAK for
pread/pwrite at least at this time.
Ok.
I'd also like to see a hard no relocs policy for DG1 enforced in the kernel.
Ok, just checking, is that the case even if we don't require extra code
to support it? We recently dropped the CPU reloc path completely, in
favour of single GPU reloc path, and so no special code is required to
support LMEM, it should just work. IGT of course makes heavy use of
relocs, so that would need an overhaul.
Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
