[PATCH] drm/amdgpu: For virtual_display feature, define a variable for vblank count of cpu vsync timer.

[Deng, Emily]

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 at daenzer.net]
> Sent: Tuesday, August 16, 2016 3:18 PM
> To: Deng, Emily <Emily.Deng at amd.com>
> Cc: amd-gfx at lists.freedesktop.org; dri-devel at 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 at 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 at 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