Re: [PATCH libdrm] intel: Use CPU mmap for unsynchronized map with linear buffers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 17, 2015 at 05:19:02PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote:
> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> 
> On LLC platforms there's no need to use GTT mmap for unsynchronized
> maps if the object isn't tiled. So switch to using CPU mmap for linar
> objects. This avoids having to use the GTT for GL buffer objects
> entirely, and thus we can ignore the GTT mappable size limitation.
> For tiled objects we still want the hardware to do the (de)tiling so
> keep using GTT for such objects.
> 
> The display engine is not coherent even on LLC platforms, so this won't
> work too well if we mix scanout and unsynchronized maps of linear bos.
> Actually, that would only be a problem for an already uncached object,
> otherwise it will get clflushed anyway when being made UC/WC prior to
> scanout. The alreday UC object case could be handled by either
> clflushing straight from userspace, or we could add a new ioctl to
> clflush or mark the object as cache_dirty so that it will get
> clflushed in the future just prior to scanout. I started to think
> that a small nop pwrite would have the desired effect, but in fact it
> would only flush the cachelines it touches so wouldn't actually work
> I doubt we want to pwrite the entire object just to get it clflushed.
> 
> This fixes Ilias's arb_texture_buffer_object-max-size piglit test
> on LLC platforms.

Note that there have been patches to fix mesa/i965 for this issue on
both llc and !llc on the mailing list for a few months.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux