November 26th, 2009


radeon display port working

Finally got some time to take another look at radeon displayport support.

I wrote initial userspace modesetting patches in June to get EDID and by mid July I had it to the stage where I could
get a display if I started X, then used xrandr to switch to a different mode. I ran out of time to continue investigations then.

Last week Alex Deucher rebased my code into the latest DDX and cleaned up a lot of the insanity in it. At the same time I started porting the code to the kernel for KMS support. Alex also picked that up and made the userspace and kernel drivers pretty much act the same. However at the end of this neither of us actually had reliable display port support.

So this morning I discovered that actually every second modeset was working, with ones in between turning off power to the monitor, so I moved a few things around in the displayport link training initialisation code and voila reliable userspace displayport. I then ported the same fix to the kernel and it didn't make it work. Another 2-3 hours of guessing found a missing
return statement which meant we ended up with a version 0 DP identification which broke stuff. With that fixed, KMS displayport started working.

Where can I get this?
UMS/DDX: git:// displayport branch
KMS: git:// drm-radeon-dp branch

a) When r600 grows IRQ support we need to use the hotplug irq to detect the monitor appearing/disappearing
so we can retrain the link with it, otherwise unplugging the monitor means it won't be there on replug,
unless you change modes, for userspace we probably need to use a timer to detect if the monitor goes away or we lose
b) cleanup code, maybe see what we can share with Intel.
c) merge, I'd say we can nearly merge the UMS code to master, and KMS can definitely go in the next merge window.

[updated for pedants].

radeon kms 3D speed regression

So Phoronix pointed out we have a KMS/DRI2 3D regression vs UMS/DRI1, two things sprang to mind wrt to places we lost some of this so I did a quick benchmark on my laptop.

Thinkpad T60P, rv530 FireGL V5200, Intel Core Duo T2500 CPU 2Ghz, 1600x1200 LCD

F-12 mostly.

So I ran openarena with Eric Anholt demo at 1400x1050 (not fullscreen)

5 tests, non-kms, kms out of the box, kms with color tiling, kms with vsync remove, kms with vsync removed + colortiling

non-kms: 840 frames 25.3 seconds 33.2 fps 9.0/30.2/55.0/6.7 ms
kms-nontiled: 840 frames 38.2 seconds 22.0 fps 9.0/45.5/81.0/9.4 ms
kms-tiling: 840 frames 31.6 seconds 26.6 fps 19.0/37.6/72.0/7.2 ms
kms-nontiled-novsync: 840 frames 35.7 seconds 23.5 fps 15.0/42.5/77.0/8.9 ms
kms-tiled-novsync: 840 frames 28.7 seconds 29.2 fps 11.0/34.2/66.0/7.6 ms

So there is some explaination of where some of the performance went, I'll definitely enable KMS tiling on r300->r500 where
we should have enough stuff in mesa to deal with all the sw fallbacks (gallium may need some work). The vsync vs non-vsync thing isn't something I really want to change, basically when DRI2 does the back->front copy it doesn't do it when the scanout is in the area being copied so with DRI1 you'd get tearing, with dri2 you get none. We'll also get DRI2 page flipping support at some point, which for a fullscreen app should really improve things. Besides that I'm sure there is lot of optimisation that can be done in the KMS codebase to improve this situation. I (or someone else please feel free) need to break out the profiling tools (perf, sysprof etc) and track down where we can do better.

At the moment the priority is still to make things work first, then make them fast.