[Intel-gfx] [PATCH v7 2/5] drm/i915: Use batch pools with the command parser

[Bloomfield, Jon]

> -----Original Message-----
> From: Nguyen, Michael H
> Sent: Thursday, December 11, 2014 8:13 PM
> To: intel-gfx at lists.freedesktop.org
> Cc: Bloomfield, Jon; Brad Volkin
> Subject: [PATCH v7 2/5] drm/i915: Use batch pools with the command parser
> 
> From: Brad Volkin <bradley.d.volkin at intel.com>
> 
> This patch sets up all of the tracking and copying necessary to use batch pools
> with the command parser and dispatches the copied
> (shadow) batch to the hardware.
> 
> After this patch, the parser is in 'enabling' mode.
> 
> Note that performance takes a hit from the copy in some cases and will likely
> need some work. At a rough pass, the memcpy appears to be the
> bottleneck. Without having done a deeper analysis, two ideas that come to
> mind are:
> 1) Copy sections of the batch at a time, as they are reached
>    by parsing. Might improve cache locality.
> 2) Copy only up to the userspace-supplied batch length and
>    memset the rest of the buffer. Reduces the number of reads.
> 
> v2:
> - Remove setting the capacity of the pool
> - One global pool instead of per-ring pools
> - Replace batch_obj with shadow_batch_obj and hook into eb->vmas
> - Memset any space in the shadow batch beyond what gets copied
> - Rebased on execlist prep refactoring
> 
> v3:
> - Rebase on chained batch handling
> - Squash in setting the secure dispatch flag
> - Add a note about the interaction w/secure dispatch pinning
> - Check for request->batch_obj == NULL in i915_gem_free_request
> 
> v4:
> - Fix read domains for shadow_batch_obj
> - Remove the set_to_gtt_domain call from i915_parse_cmds
> - ggtt_pin/unpin in the parser block to simplify error handling
> - Check USES_FULL_PPGTT before setting DISPATCH_SECURE flag
> - Remove i915_gem_batch_pool_put calls
> 
> v5:
> - Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after
>   the parser (danvet, from v4 0/7 feedback)
> 
> Issue: VIZ-4719
> Signed-off-by: Brad Volkin <bradley.d.volkin at intel.com>
> ---

Reviewed-by: Jon Bloomfield <jon.bloomfield at intel.com>