[Intel-gfx] [RFC] Reduce idle vblank wakeups
Anyone have any further thoughts on this? -- Matthew Garrett | mjg59 at srcf.ucam.org
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
Anyone have any further thoughts on this? -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [RFC] Reduce idle vblank wakeups
On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett wrote: > On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote: >> On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote: >> >For Radeon, I'd have thought you could handle this by scheduling >> >an irq >> >for the beginning of scanout (avivo has a register for that) and >> >delaying the vblank disable until you hit it? >> >> For Radeon there is such an irq, but iirc we had some discussions on >> this, also with Alex Deucher, a while ago and some irq's weren't >> considered very reliable, or already used for other stuff. The idea >> i had goes like this: >> >> Use the crtc scanout position queries together with the vblank >> counter queries inside some calibration loop, maybe executed after >> each modeset, to find out the scanline range in which the hardware >> vblank counter increments -- basically a forbidden range of scanline >> positions where the race would happen. Then at each vblank off/on, >> query scanout position before and after the hw vblank counter query. >> If according to the scanout positions the vblank counter query >> happened within the forbidden time window, retry the query. With a >> well working calibration that should add no delay in most cases and >> a delay to the on/off code of a few dozen microseconds (=duration of >> a few scanlines) worst case. > > Assuming we're sleeping rather than busy-looping, that's certainly ok. > My previous experiments with radeon indicated that the scanout irq was > certainly not entirely reliable - on the other hand, I was trying to use > it for completing memory reclocking within the vblank interval. It was > typically still within a few scanlines, so a sanity check there wouldn't > pose too much of a problem. I think there's a simpler fix: just keep the hardware and software counts in sync -- if everything is working correctly (even with all these crazy races), the difference should be constant. Patch coming momentarily. --Andy
[Intel-gfx] [RFC] Reduce idle vblank wakeups
2011/11/16 Matthew Garrett : > On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel D?nzer wrote: > >> I thought the main reason for the delay wasn't broken hardware but to >> avoid constantly ping-ponging the vblank IRQ between on and off with >> apps which regularly neeed the vblank counter value, as that could make >> the counter unreliable. Maybe I'm misremembering though. > > If turning it on and off results in the counter value being wrong then > surely that's a hardware problem? I've tested that turning it on and off > between every IRQ still gives valid counter values on sandybridge. This, and the thread that contains it, might be interesting: http://permalink.gmane.org/gmane.comp.video.dri.devel/53201 In summary: there was some resistance to doing this in January, but I couldn't find any legitimate reason. --Andy
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
2011/11/16 Matthew Garrett mj...@srcf.ucam.org: On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel Dänzer wrote: I thought the main reason for the delay wasn't broken hardware but to avoid constantly ping-ponging the vblank IRQ between on and off with apps which regularly neeed the vblank counter value, as that could make the counter unreliable. Maybe I'm misremembering though. If turning it on and off results in the counter value being wrong then surely that's a hardware problem? I've tested that turning it on and off between every IRQ still gives valid counter values on sandybridge. This, and the thread that contains it, might be interesting: http://permalink.gmane.org/gmane.comp.video.dri.devel/53201 In summary: there was some resistance to doing this in January, but I couldn't find any legitimate reason. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC] Reduce idle vblank wakeups
On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote: On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote: For Radeon, I'd have thought you could handle this by scheduling an irq for the beginning of scanout (avivo has a register for that) and delaying the vblank disable until you hit it? For Radeon there is such an irq, but iirc we had some discussions on this, also with Alex Deucher, a while ago and some irq's weren't considered very reliable, or already used for other stuff. The idea i had goes like this: Use the crtc scanout position queries together with the vblank counter queries inside some calibration loop, maybe executed after each modeset, to find out the scanline range in which the hardware vblank counter increments -- basically a forbidden range of scanline positions where the race would happen. Then at each vblank off/on, query scanout position before and after the hw vblank counter query. If according to the scanout positions the vblank counter query happened within the forbidden time window, retry the query. With a well working calibration that should add no delay in most cases and a delay to the on/off code of a few dozen microseconds (=duration of a few scanlines) worst case. Assuming we're sleeping rather than busy-looping, that's certainly ok. My previous experiments with radeon indicated that the scanout irq was certainly not entirely reliable - on the other hand, I was trying to use it for completing memory reclocking within the vblank interval. It was typically still within a few scanlines, so a sanity check there wouldn't pose too much of a problem. I think there's a simpler fix: just keep the hardware and software counts in sync -- if everything is working correctly (even with all these crazy races), the difference should be constant. Patch coming momentarily. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
