TearFree causes periodic wakeups

Enabling TearFree is causing 120 or 60 interrupts per second on the GPU for as long as it is enabled and screen is on. Without TearFree, there's no periodic interrupts if nothing is updating the screen.

What is causing the unnecessary interrupts? It's presenting an unfortunate dilemma for laptop users (tearing vs. CPU energy consumption).

moved from xorg/driver/xf86-video-amdgpu#44 (moved)

Enabling TearFree is causing 120 or 60 interrupts per second on the GPU for as long as it is enabled and screen is on. Without TearFree, there's no periodic interrupts if nothing is updating the screen.

TearFree is supposed to generate interrupts only if there have been any updates to the screen as well. Maybe some client keeps redrawing the same contents. In which case, the same thing should happen without TearFree but with a compositing manager which uses OpenGL or the Present extension directly. (Not to mention interrupts generated by the GPU drawing itself, even without either)

It's possible there's a bug in the TearFree logic which is supposed to bail out when there have been no updates though. If you suspect so, I'd start by looking at why neither of the following matches in amdgpu_scanout_do_update:

	if (!xf86_crtc->enabled ||
	    !drmmode_crtc->scanout[scanout_id] ||
	    extents.x1 >= extents.x2 || extents.y1 >= extents.y2)
		return FALSE;

	pDraw = &drmmode_crtc->scanout[scanout_id]->drawable;
	if (!amdgpu_scanout_extents_intersect(xf86_crtc, &extents))
		return FALSE;

It would also be interesting to see the output of xrandr in this case.

It's presenting an unfortunate dilemma for laptop users (tearing vs. CPU energy consumption).

Out of curiosity, do you have any data to quantify the difference in energy consumption?

Out of curiosity, do you have any data to quantify the difference in energy consumption?

Watching battery consumption rate in PowerTop, I see that it settles at 3.11W without TearFree, and at 3.16W with TearFree. So perhaps one could say that on my laptop extra interrupts cost about 0.05 Watts worth of energy usage (or 2% of overall idle power consumption at idle with screen on).

Another interesting observation I made while watching powertop is that amdgpu interrupts cease 5 seconds after a screen update when TearFree is enabled. That is, after an X client redraws, amdgpu interrupts continue arriving for 5 more seconds, and then they go down to near-zero levels. While without TearFree, interrupts don't linger after an update. What could be causing this strange 5-second hold-off with TearFree?

To be clear, I meant that amdgpu continue firing 60 times per second for 5 seconds after an update (and 120 times per second if two monitors are plugged in and TearFree is enabled on both).

Ah! This is probably due to the default value of 5000 for the drm kernel module's vblankoffdelay parameter. If

sudo sh -c "echo -1 >/sys/module/drm/parameters/vblankoffdelay"

fixes the problem, you can add drm.vblankoffdelay=-1 to the kernel command line in the bootloader configuration.

Yes, that must have been the cause. Why is this a global parameter, shouldn't this be a per-GPU configuration item that individual drm drivers can set appropriately?

Yes, that must have been the cause.

"Must have"? So you haven't tested it?

[...] shouldn't this be a per-GPU configuration item that individual drm drivers can set appropriately?

Drivers can ask for vblank interrupts to be disabled immediately, but this is currently not done with amdgpu DC:

        if (!amdgpu_device_has_dc_support(adev)) {
                if (!adev->enable_virtual_display)
                        /* Disable vblank IRQs aggressively for power-saving */
                        /* XXX: can this be enabled for DC? */
                        adev_to_drm(adev)->vblank_disable_immediate = true;

@hwentland @kazlaus it might be time to try enabling this?

"Must have"? So you haven't tested it?

Oh, sorry about the ambiguity. I have tested that before writing the response, it helps.

added AMDgpu DC labels

This patch should fix it. 0001-drm-amdgpu-display-set-vblank_disable_immediate-for-.patch

mentioned in commit agd5f/linux@3d1508b7

mentioned in commit agd5f/linux@92020e81

mentioned in issue #1933 (closed)

mentioned in issue #1859

Unfortunately this seems to have regressed. I'm upgrading from 5.17 where it worked without issues, to 6.2 (at -rc8 now).

1. The above commit was reverted due to issue #1887
2. Therefore on 6.2 I again need explicit drm.vblankoffdelay=-1
3. At unpredictable time (random number of hours of uptime) something related to vblank ceases to work properly:
4. At first, mpv and glxgears do not show the first frame
5. After a minute or so, glxgears runs at 3000+ fps instead of expected 60, and mpv exhibits severe audio/video desync.
6. Firefox doesn't redraw interactively, but shows updated content if I switch to a different workspace and back.
7. No new messages in dmesg.

I'd like to find what broke this, but without an easy reproducer that seems tricky. Suggestions would be welcome.