[Intel-gfx] [PATCH] intel: non-blocking mmaps on the cheap

Eric Anholt eric at anholt.net
Wed Sep 21 20:11:18 CEST 2011


On Wed, 21 Sep 2011 10:19:13 +0200, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> This adds a new mode to map gem objects in a non-blocking way. This
> needs to be enabled on a per-object basis with object_enable_nonblocking.
> 
> The new kernel interface required to get the caching level/coherency
> is not yet wired up. All the code to transparently choose between gtt
> mappings or (if coherent) cpu mappings is already in place, though.
> 
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Ben Widawsky <ben at bwidawsk.net>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
> Hi Eric,
> 
> Not really tested, but can you please take a quick lock and see if this is
> suitable for mesa and ack the general approach?

It doesn't quite look like what I want for Mesa, but close.

Don't-block-I-know-what-I'm-doing is not a long-term property of a
mapping for GL, it's something you say when you're getting a pointer to
a piece of the existing mapping, and you may ask for normal blocking
mode again later.  So I'd rather see the the map/unmap track "oh, we
already set to GTT and we haven't done something that would have knocked
it out of there, so no need to go set to GTT again", instead of setting
a flag.  Also, I think you need to re-set to GTT after a CPU mapping on
!llc, since clflushing is coarser granularity than GL buffer mappings
(byte boundary).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20110921/3c719916/attachment.sig>


More information about the Intel-gfx mailing list