On Wed, 2010-12-29 at 10:37 +0100, Maarten Maathuis wrote: > On Wed, Dec 29, 2010 at 10:35 AM, Maarten Maathuis <[email protected]> > wrote: > > On Wed, Dec 29, 2010 at 10:01 AM, Mario Kleiner > > <[email protected]> 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 > >> [email protected] > >> 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. > _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
