DRI2 vs. DRI3 Radeon Linux OpenGL Performance

[duby229]

You know that some people have 144Hz monitors, there are now also Freesync monitors with 30Hz-144Hz range so higher then 60 does matter.

If you have a 144hz monitor then tweak for that instead.

[dungeon]

If you have a 144hz monitor then tweak for that instead.

I don't have it now, but i might buy one in future... there are also some overclockable to 200Hz monitors so you never know what one want to use - any range matters.

[Guest]

For me on arch man radeon | grep DRI gives:

Enable DRI2 page flipping. The default is on. Pageflipping is supported on all radeon hardware.

very strange indeed.

That might be for a different option (for me, that text is under the "EnablePageFlip" option, which is under the DRI3 option). But if the DRI grep only shows the pageflip thing; your radeon driver may not have support for DRI3 then.

And this article proves exactly why rendering way above screen refresh is stupid. It doesn't matter. I'll bet you that if time was taken to configure the game for best settings to get close to 60hz average they would perform exactly the same. Which means that what has been taken as overall performance has been wrong all along.

The only metrics that make sense measuring are those that you'll be playing at.

I was messing with Xonotic last night; leaving FPS capped at 60 with vsync had my FPS dropping well below that at times. Disabling vsync (vblank_mode=0) easily allowed Xonotic to maintain above 60 fps most of the time.

[duby229]

I was messing with Xonotic last night; leaving FPS capped at 60 with vsync had my FPS dropping well below that at times. Disabling vsync (vblank_mode=0) easily allowed Xonotic to maintain above 60 fps most of the time.

Well, vsync can help reduce tearing, but that not what I'm saying, Leave vsync off, but tweak game and graphic settings to get close to your monitors refresh rate. It all about playability, so if settings cause frame rate to drop too low, then it needs further tweaking.

[dungeon]

I was messing with Xonotic last night; leaving FPS capped at 60 with vsync had my FPS dropping well below that at times. Disabling vsync (vblank_mode=0) easily allowed Xonotic to maintain above 60 fps most of the time.

There is cl_maxfps cvar in Xonotic to cap yor frame rate to desired value.

Btw. there is cl_curl_enabled which Michael should disable in phoronix benchmark, to not benchmark network with Xonotic and also to not have that update now message to flow around

edit: Yeah problem with traditional vsync is if let say your screen is 60Hz, but on moment fps rate goes at least 1 fps bellow that value then it tries to vsync again to 30Hz likely which introduce throttling and that makes things looks even worse.

[profoundWHALE]

There is cl_maxfps cvar in Xonotic to cap yor frame rate to desired value.

An in source games, while in the game I know that you can:
~ to open the console
max_fps 65

And it'll be easier to maintain that because your GPU won't try to render 200+ fps in an empty room. I say 65 because it'll always be a little bit less than that which definitely gives me tearing.

Btw. there is cl_curl_enabled which Michael should disable in phoronix benchmark, to not benchmark network with Xonotic and also to not have that update now message to flow around

He likes to benchmark real world use (aka, the average user) meaning only flags that would be default. Anything special AFAIK would mean something like this which just has DRI2 vs DRI3

edit: Yeah problem with traditional vsync is if let say your screen is 60Hz, but on moment fps rate goes at least 1 fps bellow that value then it tries to vsync again to 30Hz likely which introduce throttling and that makes things looks even worse.

Yeah. The goal of vsync is consistent frame times over latency

Anyways, regarding the performance, it's always good to see improvements with no regressions.

[dungeon]

He likes to benchmark real world use (aka, the average user) meaning only flags that would be default. Anything special AFAIK would mean something like this which just has DRI2 vs DRI3

He should really disable that in Xonotic Real world average user will update his game when message box fly around like that

Openarena 0.8.8 benchmark has nothing to do what user will get by default from that game, etc...

[SystemCrasher]

When running the Xonotic open-source first person shooter with its maximum visuals, the R9 290 and HD 6870 continued to deliver greater frame-rates with DRI3 enabled.

...and what happened to R7 370? One of most dumb and annoying misfeatures of benchmarks at phoronix is lack of half results for half tests without any single word about reason begind this. Has R7 370 crashed under load? Has it failed to deliver reasonable performance? Or this test has been just considered pointless and skipped?

[SystemCrasher]

Yeah. The goal of vsync is consistent frame times over latency

First and foremost goal of vsync is to replace frames in CRTC's framebuffer at "proper" ("vblank") times. You see, when you carelessly update picture in CRTC's framebuffer at arbitrary time "just because you already computed new frame", it often happens CRTC already started throwing frame into the wire. If you change image right when CRTC throwing it into the wire, half-old, half-new frame goes to the wire. Since frames could be different, there could be visible border somewhere in the middle of frame received by display. If it happens a lot, users are swearing about "tearing". So it could be important to change frames only when CRTC does not throws data into the wire, if you value picture quality over latency. Generally, all changes and re-configurations should happen during vblank times unless one is okay with distorted/weird picture, flickering, tearing and other fancy stuff.

As far as I understand, idea behind Freesync is that CRTC could be is able to "defer" throwing frame into the wire to some degree, if it turns out you need more time to finish rendering. Vblank is "extended", CRTC does not throws half-old, half-new frame, but rather waits for complete new frame, which is then thrown into the wire once it ready and put in place. It results in tear-free picture, even if GPU being somewhat late to compute some frames. As such, there is no constant FPS at this point.

...and btw, if I remember, opensource graphic stack makes assumptions that FPS is constant. It has been true for decades. But not anymore.

[dungeon]

...and what happened to R7 370? One of most dumb and annoying misfeatures of benchmarks at phoronix is lack of half results for half tests without any single word about reason begind this. Has R7 370 crashed under load? Has it failed to deliver reasonable performance? Or this test has been just considered pointless and skipped?

I guess that should be ALARM!!! for any GCN 1.0 user to check Xonotic Ultra If something crashes it will be easy to bisect from low, maybe offsetmapping that was crashing llvm earlier here and there.