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

[Daniel Vetter]

On Tue, Sep 20, 2011 at 03:19:53PM -0700, Ben Widawsky wrote:
> On Tue, 20 Sep 2011 13:06:43 +0200
> Daniel Vetter <daniel at ffwll.ch> wrote:
> > - I'm sorry having suggested to implement the clflush ioctl, I think
> > it's a foolish idea, now. Non-blocking mmaps is a performance
> > optimization, needing to sync caches with clflush is very much the
> > opposite. So I think we can dustbin this.
> 
> I disagree. I think it's nice function to add for people too lazy to do
> micro-optimizations. The flushing of the full object is almost
> guaranteed to make performance worse though, that should really only be
> for testing purposes.

Let me whip up a simple patch for libdrm to show why I think we don't need
this.

> >   Now non-blocking cpu mmaps make very much sense on llc/snooped
> > buffer objects. So I think we actually need an ioctl to get
> > obj->cache_level so userspace can decide whether it should use
> > non-blocking gtt mmaps or cpu (non-blocking) cpu mmaps. We might as
> > well go full-circle, make Chris happy and merge the corresponding
> > set_cache_level ioclt to enable snooped buffers on machines with
> > ilk-like coherency (i.e. that atom thing I'm hearing about ...). But
> > imo that's material for non-blocking mmaps, step 2.
> 
> I'd need to research this a bit more, let me defer response on this
> part. By the way, which set_cache_level ioctl are you referring to?

The set_cache_level ioctl that doesn't exist yet ;-) Essentially something
to set/get obj->cache_level, so that Chris can use snoopable bos on !llc
machines. But as I've said, that's probably something for the extend
non-blocking mmap support and not something we need right away.

Cheers, Daniel

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