Nouveau - Dec 2010 - CRTC video scanout position for high precision vblank timestamping?

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

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.