Quoting Daniele Ceraolo Spurio (2020-01-29 23:58:59) > The workarounds are a common "feature" across gens and submission > mechanisms and we already call the other WA related functions from > common engine ones (<setup/cleanup>_common), so it makes sense to > do the same with WA application. Medium-term, This will help us > reduce the duplication once the GuC resume function is added, but short > term it will also allow us to use the workaround lists for pre-gen8 > engine workarounds. > > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> > Cc: Matthew Brost <matthew.brost@xxxxxxxxx> Ok, we've already made the apply functions gentle and not blow up when called on early gen, and moving the apply into a common path doesn't hinder future plans. The only counter argument is that this is building a midlayer, and that the point of vfuncs is that you call into the backend and the backend picks and chooses which helpers to use. So we have to be really confident that this is truly universal and not a trap for future. But at the same time, we're quite adapt at deconstructing when we need to. Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
