Re: [PATCH] drm/i915: Use hash tables for the command parser

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

 



On Mon, May 12, 2014 at 03:49:02PM +0100, Tvrtko Ursulin wrote:
> 
> On 05/10/2014 10:10 PM, bradley.d.volkin@xxxxxxxxx wrote:
> >From: Brad Volkin <bradley.d.volkin@xxxxxxxxx>
> >
> >For clients that submit large batch buffers the command parser has
> >a substantial impact on performance. On my HSW ULT system performance
> >drops as much as ~20% on some tests. Most of the time is spent in the
> >command lookup code. Converting that from the current naive search to
> >a hash table lookup reduces the performance drop to ~10%.
> >
> >The choice of value for I915_CMD_HASH_ORDER allows all commands
> >currently used in the parser tables to hash to their own bucket (except
> >for one collision on the render ring). The tradeoff is that it wastes
> >memory. Because the opcodes for the commands in the tables are not
> >particularly well distributed, reducing the order still leaves many
> >buckets empty. The increased collisions don't seem to have a huge
> >impact on the performance gain, but for now anyhow, the parser trades
> >memory for performance.
> >
> >NB: Ville noticed that the error paths through the ring init code
> >will leak memory. I've not addressed that here. We can do a follow
> >up pass to handle all of the leaks.
> >
> >v2: improved comment describing selection of hash key mask (Damien)
> >replace a BUG_ON() with an error return (Tvrtko, Ville)
> >commit message improvements
> >
> >Signed-off-by: Brad Volkin <bradley.d.volkin@xxxxxxxxx>
> 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>

Nice.

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
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