Re: [PATCH 3/6] drm/i915: Split the batch pool by engine

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 03/19/2015 12:04 PM, Chris Wilson wrote:
> On Thu, Mar 19, 2015 at 11:58:17AM +0000, Tvrtko Ursulin wrote:
>> How about retire all rings and then the inactive batch search with a
>> global pool becomes only O(num_rings) at worst? Might be worth
>> saving memory resource (multiple pools) vs. trivial traversal like
>> that?
>
> There isn't a memory resource issue here though. The pool is made out of
> easily reclaimable objects, and is ultimately limited by just how many
> batches can be submitted whilst the GPU is active. The principal issue
> is finding a new buffer to use for the next batch. Splitting by engine
> is also likely to have nice secondary effects like grouping of batch
> sizes.

True on the last bit, yes.

Also, I was under the wrong impression that only backing storage gets 
discarded and pool objects remain. Maybe it was like that some time back 
in some initial version, no idea now.

Anyway with this misconception cleared I agree resource problem is much 
smaller, although I still wonder how big or small exactly would be a 
difference in dynamic numbers of allocated pool batches between 
global-pool-but-fixed-inactive-lookup and per-ring-pool scenarios.

Especially since you'll later add buckets and then per ring pools with 
buckets sounds not as optimal, both from design point of view and from 
resource usage point of view, as single bucketed pool with efficient 
object lookup would be.

So I still don't like it, but it will work and behaves better than 
before, so will r-b it when you add the missing destructor.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx