?

Log in

No account? Create an account
airlied
airlied
:.:..:.

July 2017
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

airlied [userpic]
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.

Comments
(Anonymous)

Hi Dave, my main problem with kms performance at the moment is in compiz. On my rv380 compiz with ums and the cpu at 1 GHz (cool'n'quiet enabled) gives me 120 fps on a static display and 60 fps with the effects enabled (for example rotating the cube); on kms (2.6.32rc7) with the cpu at the same speed I get 60 fps with a static display (it's ok, it matches the refresh rate), but only 24-30 fps when rotating the cube. Even forcing the performance governor and keeping the cpu at 2.5 GHz I don't get more than 40 fps.

On the other hand, I tested kms for hours and it was perfectly stable, it's a great thing and probably more important than performances, now.

Thanks!

Thank you for your work in this area. Intel and radeon are really exciting, having some well supported graphics devices for Linux.

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

Excellent. I like that attitude. Particularly since I have to boot with nomodeset at the moment, because KMS breaks things. I'd rather have working KMS than blazingly fast performance on someone else's box :-)

(Anonymous)
Not only performance

With kms enabled I experience colour artefacts and refresh problems, in my setup (F12, with ATI Technologies Inc Mobility Radeon HD 3400 Series).
Using the nomodeset grub arg, the colour artefacts are gone, although I still experience some refresh problems, specially with Firefox and Eclise, because I spend a lot of time with these applications.
I've tried setting XAA in xorg.conf, but it doesn't solve the problem.

Re: Not only performance

AGP?

(Anonymous)
Re: Not only performance

Nope, I have a toshiba laptop:

(II) Module vgahw: vendor="X.Org Foundation"
compiled for 1.7.1, module version = 0.1.0
ABI class: X.Org Video Driver, version 6.0
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(==) RADEON(0): RGB weight 888
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(--) RADEON(0): Chipset: "ATI Mobility Radeon HD 3400 Series" (ChipID = 0x95c4)
(--) RADEON(0): Linear framebuffer at 0x00000000c0000000
(II) RADEON(0): PCIE card detected

If you need any info please let me know and I will open a bug in bugzilla.

I'm all for making things work first, and them getting them in shape for general use, but wouldn't it be wise to make sure there are no major regressions before pushing them as default?

New features are great, but people will always notice regressions faster.

a) not really since Fedora is meant to be a place for leading edge technologies to happen, I've never pushed this for any other distro.

b) Also 3D speed regressions aren't a major regression, your PC not turning on is.

c) Like say we add GL2.0 to a graphics card but only if we accept we need to take 20% FPS hit on some games, what do you do? You'll always get whiners, easier to just push through and finish it instead of worrying.