Re: [PATCH] drm/hyperv: add a parameter to disable the vblank timer

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 19.10.26 um 17:40 schrieb Lanfeng Wei:
> Hi Thomas,
>
>> Yeah, what's the cause of it? Switching off features does not fix any
>> bugs or improve the status quo.
> You are right that the module parameter is only a workaround for users
> affected; it does not fix the underlying scheduling problem.
>
> The cause is that the synthetic vblank timer is used to pace completion
> of atomic updates triggered by dirtyfb, in addition to providing
> synthetic vblank events. In Xorg's software-cursor path, pointer motion
> damages the primary framebuffer and the damage is instantly submitted
> via DRM_IOCTL_MODE_DIRTYFB. The Hyper-V dirtyfb path performs a
> synchronous atomic commit, and with the vblank timer enabled that commit
> can wait for the next simulated vblank. Under continuous pointer motion,
> these commits dominate the update path and delay normal client updates,
> resulting in sever frame-rate drops.
>
> This particular regression results from the combination of the blocking
> dirtyfb path, synthetic vblank pacing, and the absence of a Linux DRM
> cursor plane in Hyper-V. While the Hyper-V video protocol does have a
> hardware-cursor command path, the upstream hyperv_drm driver currently
> exposes only a primary plane. Cursor plane support was deferred during
> the initial upstreaming [1]. Without a cursor plane, Xorg has to fall
> back to software cursor-rendering path and it competes with periodic
> graphical updates on the primary plane.
>
> So the proper long-term fix could be adding cursor plane support in the
> Hyper-V DRM driver, which may take some time. Providing that the stated
> purpose of the offending commit is to rate-limit display updates, while
> its current implementation regresses the existing software-cursor path,
> I think adding a switch or reverting the commit until the requested
> features in the driver is ready, is a reasonable short-term fix.

The problem is that module parameters are impossible to remove in 
practice. Once in place, someone always depends on it. They also 
increase the number of states to test.  Avoiding them is usually a good 
idea. Especially as workarounds for bug or regressions.


I'm not familiar with the Hyper-V protocol, so I have a question. Why is 
it hard to implement cursors? From the link at [1], I assume that cursor 
support was left out because the simple-kms pipeline did not support 
cursor planes. This has long been resolved: the simple-kms pipeline is 
gone and hyperv_drm runs on the regular DRM framework.  Unless there's 
anything special with the Hyper-V protocol, cursor-plane support should 
be do-able in a single patch. [^1]

Best regards
Thomas

[^1] See 
https://elixir.bootlin.com/linux/v7.2.11/source/drivers/gpu/drm/ast/ast_cursor.c 
for an example of how this looks. Most of it is hardware-related, but 
hyperv would likely be similar in concept.

>
>> We had another fix for a problem with vblank timers:
>>
>> https://lore.kernel.org/dri-devel/20260914110004.211027-1-tzimmermann@suse.de/
>>
>> Did you validate that this fix is unrelated?
> Yes I tested that fix and confirmed that it is irrelevant. It solves
> issues with excessively long frame durations, however this problem is
> found in normal frame updates (in my case 60Hz / 16.7 ms per frame, way
> below INT_MAX).
>
> Best regards,
>
> Lanfeng Wei
>
> [1] https://lore.kernel.org/dri-devel/20200622110623.113546-1-drawat.floss@gmail.com/

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg)