Hi Michel and Daniel, Return the fake vblank count or return 0 in vblank_get_counter is only the virtual display feature's behavior, and the virtual display feature need to be enabled by set module parameter, so won't affect normal case. And I think the vblank counter will be increased every time when the vsync timer interrupt occurs in virtual display feature is reasonable, so that the 3D app about vblank count could work normally. For the time stamp could be set to limitations for virtual display feature.
Best Wishes, Emily Deng
-----Original Message----- From: Michel Dänzer [mailto:michel@daenzer.net] Sent: Tuesday, August 16, 2016 3:18 PM To: Deng, Emily Emily.Deng@amd.com Cc: amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.
On 16/08/16 04:00 PM, Deng, Emily wrote:
From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf Of Michel D?nzer Sent: Tuesday, August 16, 2016 2:43 PM On 16/08/16 03:28 PM, Deng, Emily wrote:
From: Michel Dänzer [mailto:michel@daenzer.net] Sent: Tuesday, August 16, 2016 12:01 PM On 16/08/16 12:49 PM, Deng, Emily wrote:
Hi Michel, Thanks, I still couldn't see the issue that use a variable to calculate the vblank count when vsync timer interrupt occurs. I just think it only emulates the hardware behavior. And the code change will only in virtual display files which won't touch drm layer. I incline to not modify the code in drm layer or amdgpu other codes, because it may lead to other issues .
I see it basically the other way around: We are currently pretending to the DRM core code that we have a reliable hardware vblank counter and timing even in the virtual DCE case, when we really don't. We should stop pretending and instead communicate the lack of these hardware facilities in the virtual DCE case as intended, otherwise we'll
probably run into issues sooner or later.
[[EmilyD]] Hi Michel, yes, you are right, we are pretending a hardware vblank counter in virtual DCE case to drm layer. But can you specific some
cases that we must communicate with drm layer that we don't have the vblank counter.
I described all the necessary steps (that I know of; there may be more) in https://lists.freedesktop.org/archives/amd-gfx/2016-
August/001342.html .
[[EmilyD]] Hi Michel, I means can you detail the reasons or cases that we should communicate with drm layer when don't have the vblank counter
instead of pretending a hardware vblank counter in virtual DCE case.
The DRM core code expects the get_vblank_counter hook to use a reliable hardware counter. If that is not the case, it should always return 0.
Similarly, drm_calc_vbltimestamp_from_scanoutpos expects the get_scanout_position hook to return accurate scanout position values based on reliable hardware registers.
If we pretend to return accurate values from these when we actually can't, the DRM core code may provide incorrect vblank counter / timestamp values to userspace, or worse.
Those are just off the top of my head, there may be more along the same lines.
-- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer