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

[Deng, Emily]

Hi Michel and Daniel,
     I just tryed Michel's advice: return 0 in vblank_get_counter, and set dev->max_vblank_count = 0 ,
and found the adev->ddev->vblank[crtc].count also can increase which makes the 3D app with vsync can
work properly as well. But I don't know the principle. Anyway I will take Michel's advice about vblank count, 
and send a patch later.

Best Wishes,
Emily Deng

> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of
> Deng, Emily
> Sent: Tuesday, August 16, 2016 5:14 PM
> To: Michel Dänzer <michel at daenzer.net>; Daniel Vetter
> <daniel.vetter at ffwll.ch>
> Cc: dri-devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org
> Subject: RE: [PATCH] drm/amdgpu: For virtual_display feature, define a variable
> for vblank count of cpu vsync timer.
> 
> 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
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx