Re: [PATCH v2 16/37] drm/i915/lmem: support pread

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Jul 30, 2019 at 2:05 PM Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Daniel Vetter (2019-07-30 09:58:22)
> > On Thu, Jun 27, 2019 at 09:56:12PM +0100, Matthew Auld wrote:
> > > We need to add support for pread'ing an LMEM object.
> >
> > Why? Usage outside from igts seems pretty dead, at least looking at iris
> > and anv. This was kinda a neat thing for when we didn't yet realized that
> > doing clflush in userspace is both possible and more efficient.
> >
> > Same for pwrite, iris just dropped it, anv doesn't seem to use it. And I
> > thought mesa plan is to drop the old classic driver for when we'll need
> > lmem. It's not much, but would allow us to drop a few things.
>
> From the opposite perspective, it should only be a wrapper around code
> that is being used internally for similar transfers. (One side-effect is
> that it can be used to poke more directly at those internals.) It is also
> not clear what the preferred strategy will be in future, especially as
> people start discussing migration-on-pagefault.

Hm, where do we look at migrate-on-pagefault?

I mean aside from the entire resurrection of the mappable deamon
because apparently we can't design apertures for pci bars which are
big enough (unlike amd, which fixed this now). But that's just an
lmem->lmem migration to squeeze it into the right range (and hey we
know how to do that, we even have the old code still).

> It comes down to whether the maintenance burden of maintaining a
> consistent API is worth the maintenance burden of not!

Yeah it's minor, but then pwrite has some irky corner-cases (I
stumbled over the vlc wtf that originally motivated the introduction
of the pwrite hook, and the reintroduction of the page-by-page pwrite
for shmem that's not pinned). So it's not the cleanest uapi we have
since almost a decade of gunk now sitting on top. And when I went
looking at iris/anv it seems like we've sunset it for good going
forward. Note I'm not going for complete removal, just not allowing it
if you set lmem as one of the placements of your bo. So pwrite into an
upload buffer in smem, mapped through the TT to the gpu, would still
be fine. Which I guess should cover all the igt pwrites for
batchbuffers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx