On 12/29/2010 10:44 AM, Ben Skeggs wrote:
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.
Wow, that was fast! Thanks! I'll get some good sleep now and then give
it a try on my GF-8800. This is probably also useful to implement the
.get_vblank_counter() hook properly. Currently it hooks up to
drm_vblank_count() which is problematic, as .get_vblank_counter() is
meant to query the hardware for the purpose of reinitializing
drm_vblank_count() after a long vblank irq off period.
I'll let you know how it goes, hopefully with some nice patches asap.
If somebody knows about similar NV40 and earlier registers, keep it
coming :-)
Is the range from NV_PCRTC0_OFFSET to NV_PCRTC0_OFFSET + NV_PCRTC0_SIZE
a good starting point for a search on NV40 and earlier?
thanks,
-mario
_______________________________________________
Nouveau mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/nouveau
