On Fri, May 24, 2019 at 06:36:14PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > ICL has so many planes that it can easily exceed the maximum > effective memory bandwidth of the system. We must therefore check > that we don't exceed that limit. > > The algorithm is very magic number heavy and lacks sufficient > explanation for now. We also have no sane way to query the > memory clock and timings, so we must rely on a combination of > raw readout from the memory controller and hardcoded assumptions. > The memory controller values obviously change as the system > jumps between the different SAGV points, so we try to stabilize > it first by disabling SAGV for the duration of the readout. > > The utilized bandwidth is tracked via a device wide atomic > private object. That is actually not robust because we can't > afford to enforce strict global ordering between the pipes. > Thus I think I'll need to change this to simply chop up the > available bandwidth between all the active pipes. Each pipe > can then do whatever it wants as long as it doesn't exceed > its budget. That scheme will also require that we assume that > any number of planes could be active at any time. > > TODO: make it robust and deal with all the open questions > > v2: Sleep longer after disabling SAGV > v3: Poll for the dclk to get raised (seen it take 250ms!) > If the system has 2133MT/s memory then we pointlessly > wait one full second :( > v4: Use the new pcode interface to get the qgv points rather > that using hardcoded numbers > v5: Move the pcode stuff into intel_bw.c (Matt) > s/intel_sagv_info/intel_qgv_info/ > Do the NV12/P010 as per spec for now (Matt) > s/IS_ICELAKE/IS_GEN11/ > v6: Ignore bandwidth limits if the pcode query fails > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > Reviewed-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > Acked-by: Clint Taylor <Clinton.A.Taylor@xxxxxxxxx> Series pushed to dinq. Thanks for the reviews. -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
