On Tue, Sep 20, 2011 at 03:19:53PM -0700, Ben Widawsky wrote: > On Tue, 20 Sep 2011 13:06:43 +0200 > Daniel Vetter <dan...@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: 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
