[Nouveau] CRTC video scanout position for high precision vblank timestamping?

[Ben Skeggs]

On Wed, 2010-12-29 at 10:37 +0100, Maarten Maathuis wrote:
> On Wed, Dec 29, 2010 at 10:35 AM, Maarten Maathuis <madman2003 at gmail.com> wrote:
> > On Wed, Dec 29, 2010 at 10:01 AM, Mario Kleiner
> > <mario.kleiner at tuebingen.mpg.de> wrote:
> >> Hello all,
> >>
> >> i have recently implemented some patches to the drm core and to the intel
> >> and radeon kms drivers to provide high precision timestamping of vblank
> >> intervals and for timestamping of pageflip bufferswap completion. This is
> >> needed to properly implement the DRI2 sync & swap bits and their support for
> >> the oml_sync_control extension.
> >>
> >> The patches are in drm-next and will hopefully land in the 2.6.38 merge
> >> window. Now i'd like to add support for the nouveau kms driver as well.
> >>
> >> I had a look at the current nouveau code in drm-next. Implementing the
> >> patches shouldn't be a problem, it is mostly copy & paste from radeon/intel
> >> kms + a little bit of adjustments and then testing.
> >>
> >> Problem: The code needs to query the current video scanout position of a
> >> given crtc. My missing bit of information is the location and format of the
> >> MMIO registers which presumably exist on nvidia gpu's to provide this
> >> information. I know the gpu's support this, because the NVidia proprietary
> >> drivers on both MS-Windows and MacOS/X provide a function to query this info
> >> from userspace (Windows DirectDraw-7 GetScanline() function, OS/X
> >> CGDisplayBeamposition() function). Unfortunately the nvidia blob on Linux
> >> (and Linux/X11 itself) to my knowledge doesn't support such an api, so i
> >> can't simply mmio-trace the blob to find the relevant register. Also afaik
> >> the rules-ng database and the current driver source code don't document the
> >> location of such a register.
> >>
> >> I've already made friendship with renouveau and hacked it a bit for my
> >> purpose, but playing with it for an hour on a Geforce 8800 and staring at
> >> dumps didn't get me lucky that easily.
> >>
> >> I thought i'd ask if any of you have by accident stumbled across such a
> >> register or would have any good hints how i could narrow down the search.
> >> Otherwise i'll hack up renouveau to do a bit of pattern matching, searching
> >> for characteristic patterns in the brute force way and praying to the gods
> >> of computing that this won't take forever. To my surprise I already had to
> >> learn that apparently just reading the wrong registers can cause display
> >> corruption and crash the whole machine.
> >>
> >> Any helpful comments highly appreciated.
> >>
> >> Thanks,
> >> -mario
> >> _______________________________________________
> >> Nouveau mailing list
> >> Nouveau at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/nouveau
> >>
> >
> > If you promise to (get someone to) document them i'll tell you the
> > ones for my NV96 (probably the same registers on all geforce 8 and
> > upwards) :-)
> >
> > 0x616340: CRTC0 vertical scanline (lower 16 bits, upper 16 bits empty)
> > 0x616344: CRTC0 horizontal scanline (lower 16 bits, upper 16 bits is a
> > counter that increments every display cycle)
> >
> > 0x616B40: CRTC1 vertical scanline
> > 0x616B44: CRTC1 horizontal scanline
> >
> > I found these by simply dumping the entire range modesetting related
> > registers. At the time they didn't help me (the issue of swapbuffers
> > remains unsolved on this generation of hardware, it didn't interest me
> > *that* much). I don't know what exactly you are doing, but a lot of
> > stuff is done through pushbuffers (even modesetting) so there are no
> > "instant" registers that i know of.
> >
> > With respect to older cards, i think the VGA spec should offer some
> > help. That data has been duplicated into normally accessible
> > registers. If you're lucky Francisco Jerez will reply, he might know
> > the exact registers.
> >
> > I wish you much fun and happiness.
> >
> > Sincerely,
> >
> > Maarten.
> >
> > --
> > Far away from the primal instinct, the song seems to fade away, the
> > river get wider between your thoughts and the things we do and say.
> >
> 
> In my infinite wisdom i swapped the vertical and horizontal regs,
> these are the right ones:
> 
> 0x616340: CRTC0 horizontal scanline (lower 16 bits, upper 16 bits is a
> counter that increments every display cycle)
> 0x616344: CRTC0 vertical scanline (lower 16 bits, upper 16 bits empty)
> 
> 0x616B40: CRTC1 horizontal scanline
> 0x616B44: CRTC1 vertical scanline
Ah, I should've waited 10 minutes before doing the same here.  Ah well,
I can confirm at least on NV84, I can't imagine it differs at all on any
nv50+ board either.

Ben.
>