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 <[email protected]> > Cc: Daniele Ceraolo Spurio <[email protected]> > Cc: Jeff McGee <[email protected]> > Cc: Michal Wajdeczko <[email protected]> > Cc: Oscar Mateo <[email protected]> > Signed-off-by: Michał Winiarski <[email protected]>
Matches my expectations, Reviewed-by: Chris Wilson <[email protected]> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
