Quoting Ville Syrjala (2020-07-16 20:04:26) > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > WAC6entrylatency is trying to fix excessive rc6 entry latency caused > by the extra delay from FBC_LLC_READ_CTRL, which is there for some > extra sync with uncore for frame buffer caching in LLC. > > Reading through the hsd the recommendation was to set the FBC_LLC_FULLY_OPEN > bit to disable this extra delay entirely. This can be done whenever fb LLC > caching is not used. Ah, is that what it means by 'must not be set unless coordinated with uncore?' Ok. > The alternative suggestion was to reduce the delay to > eg. 0x5 via updated BIOS programming instructions. But all the kbl/cfl > machines I've seen still have the default 0xff programmed. As we never use > fb LLC caching let's just apply the w/a to all skl derivatives to get > consistent rc6 latencies. > > I was able to measure the effect of FBC_LLC_READ_CTRL to rc6 latency > via forcewake. Here's a graph of some of the results: > > sleep;fw_req=1;wait fw_ack==1;sleep;fw_req=0;wait fw_ack==0 > fw_ack==1 duration > 160us +----------------------------------------------------------------+ > | + + $$+ + + | > | $$ $ $ ******$$ ** $ $**$* #########$$######| > 140us |-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$*$$$$$$$$$$$$$$$$ $$$$$$| > | $ * # | > | $ * # | > 120us |$+ * # +-| > |$ * # | > |$ * # # | > 100us |$+ ************######################## +-| > |$ * *# | > |$ ***** ######### | > 80us |$+ * # #### ## +-| > |$ **** ### # # | > | ** #### FBC_LLC_READ_CTRL: 0x8000 ******* | > 60us |-###### FBC_LLC_READ_CTRL: 0xffff #######-| > |## + + FBC_LLC_READ_CTRL: 0x400000ff $$$$$$$ | > +----------------------------------------------------------------+ > 0ms 10ms 20ms 30ms 40ms 50ms 60ms > sleep duration > > The default FBC_LLC_READ_CTRL value of 0xff is documented to give us > a 170usec delay. That tracks well with the knees at 0xffff->~44usec and > 0x8000->~22usec we see in the graph. > > We can see that if we sleep longer than the FBC_LLC_READ_CTRL delay > we always observe the full (~145usec) rc6 wakeup latency. But if we sleep > for less than the FBC_LLC_READ_CTRL delay we see a quicker fw wakeup, > presumably due the hardware not having yet entered rc6 fully. > The other plateaus in the graph I suspect correspond to some shallower > internal rc states. Hmm, so by setting LLC as fully open, there is always a fixed 140us latency for rc6, implying that we always immediately try to enter rc6 rather than after ~50ms. I realize that my rc6 power measurements should be with the display already off and so will not show any effect. :| The graph does imply that there should be a noticeable effect for composited desktops, both in power saving and a latency penalty. 140us is about the same sort of ballpark as all the over startup costs, and one hopes they overlap. > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
