Quoting Michał Winiarski (2017-09-12 13:47:24) > To create an upper bound on number of GuC workitems, we need to change > the way that requests are being submitted. Rather than submitting each > request as an individual workitem, we can do coalescing in a similar way > we're handlig execlist submission ports. We also need to stop pretending > that we're doing "lite-restore" in GuC submission (we would create a > workitem each time we hit this condition). This allows us to completely > remove the reservation, replacing it with a compile time check. > > v2: Also coalesce when replaying on reset (Daniele) > v3: Consistent wq_resv - per-request (Daniele) > v4: Squash removing wq_resv > > References: https://bugs.freedesktop.org/show_bug.cgi?id=101873 > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > Cc: Jeff McGee <jeff.mcgee@xxxxxxxxx> > Cc: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx> > Cc: Oscar Mateo <oscar.mateo@xxxxxxxxx> > Signed-off-by: Michał Winiarski <michal.winiarski@xxxxxxxxx> Matches my expectations, Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Just pondering the interaction with gen8_cs_irq_handler(). Since we are now tweaking port_count(), it is theoretically possible that we get a cs-interrupt. That seems entirely harmless as the guc tasklet checks the breadcrumb anyway. Just something to keep in the back of the mind when reviewing the interactions between execlist.port[] and guc. But I'm wondering if we should be masking the cs-interrupt on switching to guc... I don't believe we are in gen9_enable_guc_interrupts(). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
