[Intel-gfx] [PATCH 1/6] RFCish: write only mappings (aka non-blocking)

[Daniel Vetter]

On Tue, Sep 20, 2011 at 10:17:25AM -0700, Eric Anholt wrote:
> On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter <daniel at ffwll.ch> wrote:
> > - Why do we need any patches for gtt non-blocking mmaps? I've re-read our
> >   code, and afaics we're only calling wait_rendering from gem_fault if
> >   obj->gtt_space == NULL. I.e. there's no way the gpu is currently using
> >   the data and hence no way for us to block on it. I think the only thing
> >   needed is a small libdrm batch to enable non-blocking gtt mmaps
> > 
> >   void drm_intel_enable_non_blocking_gtt_mmap(obj)
> > 
> >   which sets a bit somewhere and moves the obj (once) into the gtt domain.
> >   And a corresponding change in gtt_mmap to disable the set_domain call.
> >   This only works as long as no one else access the object from the cpu
> >   domain, but afaics we'll use non-blocking mmaps only for unshared
> >   buffers, so that should be fine.
> > 
> >   I might also just be dense and not see the issue ...
> 
> This was what I was looking for.  Ben was concerned that while warming
> up towards steady state, the page faults for new pages of the giant
> vertex buffer (for example) would end up blocking in the fault handler.
> I really have a hard time caring about that case.

Well, that can easily be handled by just prefaulting the full range on the
enable_non_blocking call. The thing I was concerned about was when we need
to move around the bo in the gtt to make some space and shoot down the
mappings to do so: On the first fault the bo is naturally not busy, but on
subsequent faults on other parts of the bo the gpu might already be using
it. But I've double-checked, and it looks like with your revert (commit
e92d03bf) we should be safe.

Now for cpu coherent mmaps on machines/kernels support llc caching: Would
you prefer libdrm to transparently use that for non-blocking maps if
available, or is an explicit feature-check with a sepearte cpu map
function preferred? I'm thinking of adding a new map_non_blocking
functions to add to libdrm that either uses gtt mmaps, or cpu mmaps if
they're coherent. The risk I'm seeing with that approach is that future
hw gens might have slightly different semantics for these (e.g funny
games with swizzling) so transparently using one instead of the other may
end up in headaches.  Otoh for untiled buffers to upload vertices, pixels,
whatnoelse, we should be fairly safe. And cpu mmaps for tiled buffers are
broken already, thanks to bit17 swizzling.

I think I can etch out a bit of time and whip up an rfc patchset in the
coming days.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48