On Fri, Oct 04, 2024 at 08:49:51AM +0200, Sebastian Andrzej Siewior wrote: > On 2024-10-02 19:58:08 [+0300], Ville Syrjälä wrote: > > > These patches were not picked. Did I forget something or was this just > > > overseen? > > > > This looks quite poorly justified. Eg. you seem to be now > > leaving interrupts enabled (and even preemption enabled I > > guess) when we're racing against the raster beam. On first > > blush that seems like a recipe for failure. > > I can't really parse this. I may leave interrupts enabled in vblanc code > (the first two patches). vblank evasion 101: We need to write a boatload of registers atomically within one frame. We try to guarantee that by checking if we're too close the point at which the hardware latches said registers, and if so we defer the update into the next frame. raster scan/time -> .....vertical active.........><...vertical blank...><...vertical active...><...vertical blank <VBLANK_EVASION_TIME_US> ^^ ^ ^ || | | registers are /| registers are / | latched here | latched here | | If we're somewhere | in here we delay | writing the registers... ...until we are about here and then we have most of the frame to write all the registers. Though since we use an interrupt to wait for this point interrupt latency does eat into the budget a bit .....vertical active.........><..vertical blank...><... <VBLANK_EVASION_TIME_US> ^ <-. | | registers are / | latched here | If we're somewhere to the left of this point we proceed to write the registers immediately and now in the worst case we have exactly VBLANK_EVASION_TIME_US to write all the registers So once vblank evasion has declared things to be safe we might have as short a time as VBLANK_EVASION_TIME_US to write all the registers. If the CPU gets stolen from us at that point we can no longer guarantee anything. The magic value has been tuned empirically over the years, until we've found something that seems to work well enough, without being too long to negatively affect performance. -- Ville Syrjälä Intel