On Tue, Sep 20, 2011 at 10:16:39PM +0100, Chris Wilson wrote: > On Tue, 20 Sep 2011 13:06:43 +0200, Daniel Vetter <dan...@ffwll.ch> wrote: > > 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. > > That's not enough to make me completely happy. I also have the use-case > of wanting to efficiently handle compositing with client allocated > memory i.e. persistent ShmPixmaps, where coherency either needs to be > transparent to the client or (worse) synchronicity imposed by the server.
I know, just snoopable bo support only makes you half-happy and you need fancy stuff in addition ;-) But if your sna branch can halfway easily profit from simle snoopable bo support on !llc machines, I think that'll give us an easy way to check api sanity for the new ioctl. -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
