On Tue, Sep 20, 2011 at 10:17:25AM -0700, Eric Anholt wrote: > 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.
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: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
