Radeon Gallium3D MSAA Performance (R300g)

[oibaf]

I obviously fail at using launchpad, but how do you get to the packaging sources from that page? I'd like to see the patches you used in the latest build.

Couldn't find the packaging source nor patches clicking around.

Click on View package details -> select the package -> download the .tar.gz (or other compression format) package(s).

[curaga]

Note that in my PPA I added a patch to properly build with optimizations (disabling the recent changed behavior which is still being discussed on mesa-dev).

I obviously fail at using launchpad, but how do you get to the packaging sources from that page? I'd like to see the patches you used in the latest build.

Couldn't find the packaging source nor patches clicking around.

[oibaf]

Thanks, I'll look into it next week, I must run now.

[marek]

I just tried manually compiling mesa now (I make sure to do a make clean before every compilation and verify the -O flag and -DEBUG printed at the end of configure match what expected), this is what I get:

• with --enable-debug + patch to revert -O0 and get -O2 -> 58.5 fps
• without --enable-debug 60.1 fps

It's not a big difference here, I also only did 2 run to be sure with similar result (and you may notice the fps near to ~60 but I used vblank_mode=0). Strangely, however, it's a little slower than my yesterday run (~74 fps). On which app do you see the bigger difference?

With RV730:

glxgears - 5900 FPS, with debug 3900 FPS
torcs - 33 FPS, with debug 14 FPS
nexuiz - 56 FPS, with debug 54 FPS (okay that is GPU-bound with graphics options maxed out)

[oibaf]

To me, there is a big difference in performance with --enable-debug, so big that I can't even use the flag for development. I supply my own gcc flags through the CFLAGS environment variable if I want some level of debugging with all gcc optimizations enabled.

I just tried manually compiling mesa now (I make sure to do a make clean before every compilation and verify the -O flag and -DEBUG printed at the end of configure match what expected), this is what I get:

• with --enable-debug + patch to revert -O0 and get -O2 -> 58.5 fps
• without --enable-debug 60.1 fps

It's not a big difference here, I also only did 2 run to be sure with similar result (and you may notice the fps near to ~60 but I used vblank_mode=0). Strangely, however, it's a little slower than my yesterday run (~74 fps). On which app do you see the bigger difference?

[marek]

To me, there is a big difference in performance with --enable-debug, so big that I can't even use the flag for development. I supply my own gcc flags through the CFLAGS environment variable if I want some level of debugging with all gcc optimizations enabled.

[oibaf]

I suspect the slowness of Phoronix test here is due to this.

[oibaf]

I hope Mesa wasn't compiled with --enable-debug and the Ubuntu PPA with fresh Mesa wasn't used either, because the PPA is using the --enable-debug configure flag (and maybe some other PPAs as well, maybe even Ubuntu itself!!). The behavior of --enable-debug has been changed in Mesa. Newly the flag disables all gcc optimizations, which makes pretty much everything bloody slow.

Note that in my PPA I added a patch to properly build with optimizations (disabling the recent changed behavior which is still being discussed on mesa-dev). I wasn't able to notice any measurable performance difference when enabling --enable-debug (tested some months ago), so I prefer to leave it enabled since it can be useful for debugging mesa as well as games problem. Also I prefer a game asserting and crashing than possibly locking up the system later on.

The test I did with mesa from my PPA are here and are completely different from what get on this article:

• no MSAA: 74.6 fps
• MSAA 2x: 61.1 fps
• MSAA 4x: 41.6 fps
• MSAA 6x: 29.7 fps

[Sidicas]

Especially since the MSAA tests use tons of memory bandwidth compared to non-MSAA tests. The high-resolution just amplifies that effect, meaning MSAA might be a lot less trouble at a 1280x720 resolution that's probably more common at least for those older GPUs.

I agree. I don't like these benchmarks much as they don't seem very logical.

Unless you buy more modern and high end cards, you either get high resolution *OR* you get a low resolution + MSAA. That's pretty much expected.

Dell and HP are still selling a lot of 15" laptops with 1366x768 resolution screens and AMD graphics chips in the sub-$700USD market. I don't know why people buy those low-res laptops, but they sell well... So AA is still very important today as it was years ago, to compensate for low resolutions.

What I would have preferred to see is low resolutions with MSAA vs. high resolutons without MSAA Performance comparison! That would have made sense and if there were some photos up that compared low resolution + MSAA to the high resolution in image quality and performance, it would be even better.. But alas, maybe we ask too much .

Clearly if running a higher resolution looked better and performed better, we could see that MSAA still has a long way to go.. The benchmarks in the article though, really don't say much as most gamers already know turning on AA at a high resolution is a good way to make a nice slide-show on old or low-end cards.

[smitty3268]

As a question, why such a huge screen resolution for a card that is now approaching being seven years old? I still doubt the assertion that most people today have screens that large attached to their standard PCs, but back then it was even more doubtful. I know you want to test the hardware to it's fullest possible extent, but seeing that did kind of bother me.

Especially since the MSAA tests use tons of memory bandwidth compared to non-MSAA tests. The high-resolution just amplifies that effect, meaning MSAA might be a lot less trouble at a 1280x720 resolution that's probably more common at least for those older GPUs.