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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
