[Intel-gfx] [PATCH 3/6] drm/i915: Split the batch pool by engine
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Thu Mar 19 07:01:37 PDT 2015
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
More information about the Intel-gfx
mailing list