On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter <dan...@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.
pgpQsfirDpQSh.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
