The Performance Gains Made By AMD's RadeonSI Open-Source Driver In Two Years

[geearf]

Nice review but I see a few issues with these tests:
- You don't switch only the graphics stack, but the whole OS. Sure I don't believe that GCC4 to GCC5 could give the kind of number variation we see, but something here, something there... it adds up (or removes?). At the end it's not so fair the graphic stack.

- You don't compare the rendering between the various platforms tested. I mean if something is faster because it renders wrongly that's not great. On the other hand, if the rendering is better on top of being faster, well that's awesome (more awesome than just knowing it it faster), but we don't get that information from these graphs..

[andrei_me]

- You don't switch only the graphics stack, but the whole OS. Sure I don't believe that GCC4 to GCC5 could give the kind of number variation we see, but something here, something there... it adds up (or removes?). At the end it's not so fair the graphic stack.

I believe the idea of this benchmark is to check the out-of-the-box perfomance evolution...

Besides, AFAIK there is hardware enablement and fixes that only comes through a kernel update, not only through Mesa et al.

[gigaplex]

I believe the idea of this benchmark is to check the out-of-the-box perfomance evolution...

Besides, AFAIK there is hardware enablement and fixes that only comes through a kernel update, not only through Mesa et al.

You can upgrade the kernel without switching out the whole OS, compiler toolchain etc.

[Michael_S]

Nice review but I see a few issues with these tests:
- You don't switch only the graphics stack, but the whole OS. Sure I don't believe that GCC4 to GCC5 could give the kind of number variation we see, but something here, something there... it adds up (or removes?). At the end it's not so fair the graphic stack.

I think switching operating systems makes sense because most end users aren't going to manually update their kernel and Mesa. I ran Ubuntu 13.04, 13.10, 14.04, then 14.10, then 15.04, then 15.10 alpha specifically to get better Radeon drivers. I don't have the patience to update the kernel and Mesa on 14.04.

( Then I gave up and installed another distribution because I've been hit by variations of this bug: https://bugs.launchpad.net/ubuntu/+s...y/+bug/1311316 with a lock screen with no password prompt on Unity at least once a week for three )($%^*($%&$ years. )

[charlie]

I ran Ubuntu...I don't have the patience to update the kernel and Mesa....Then I gave up and installed another distribution....

When people say they run Ubuntu I automatically assume they are challenged. This is how a SLACKWARE user compiles their kernel:

Custom alias commands in '.alias' or '.bashrc':

This updates the kernel from git and configure new kernel options:

alias cdkup='cd /usr/src/linux ; git pull --rebase && make oldconfig'

This compiles and installs the kernel (if you use lilo):

alias cdkm='cd /usr/src/linux && sed -i "s@\(export.*INSTALL_PATH\) ?= /boot@\1=/boot@g" Makefile && make all -j${threads} && make modules_install && make firmware && make firmware_install && make install ; sed -i "s@\(export.*INSTALL_PATH\)=/boot@\1 ?= /boot@g" Makefile'

The number of threads your cpu has (in the line above) is determined in the following line you can put in your '.bash_profile' or '.bashrc' file:

export threads="$(($(lscpu | grep -E "^CPU\(s\):|^Thread" | sed -e:a -e "/$/N; s@C.*\([0-9*]\)\nT.*\([0-9*]\)@\1*\2@;Ta")))"

So just type, "cdkup" and "cdkm" and set your microwave to 3 minutes for your frozen dish and your kernel should be done before your food is ready.

For compiling mesa and others I just type, "bu ati.modules" (custom .bash_profile environment) and logout and login to make sure the new modules load.

SLACKWARE superior. Ubuntu users inferior.

Disclaimer: I still haven't figured out how to cross compile 32-bit mesa yet even with the seemingly outdated instructions Xorg. For a workaround I will build 32-bit mesa on 32-bit Slackware and migrate the packages to the 64-bit Slackware.

[geearf]

I believe the idea of this benchmark is to check the out-of-the-box perfomance evolution...

Besides, AFAIK there is hardware enablement and fixes that only comes through a kernel update, not only through Mesa et al.

I think switching operating systems makes sense because most end users aren't going to manually update their kernel and Mesa. I ran Ubuntu 13.04, 13.10, 14.04, then 14.10, then 15.04, then 15.10 alpha specifically to get better Radeon drivers. I don't have the patience to update the kernel and Mesa on 14.04.

While I understand what you guys are saying, I still think it's unfair.
You're looking at way too many changes to review "only" the graphics stack, if you say this is a gaming review of Ubuntu on certain graphic cards, I have no problem with this.

As for the hardware enablement thing, well as gigaplex said you could update the kernel without updating the whole OS (though I guess the kernel still has a huge number of changes... I wonder if only taking agdf or dave's tree and applying them to the old Linux tree would work)

[nslay]

When people say they run Ubuntu I automatically assume they are practical. This is how a SLACKWARE user compiles their kernel:
<insert relatively detailed and time consuming instructions here>

Fixed that for you.

[sabun]

Fixed that for you.

Hahaha, nice

[Michael_S]

When people say they run Ubuntu I automatically assume they are challenged. This is how a SLACKWARE user compiles their kernel:

Custom alias commands in '.alias' or '.bashrc':

This updates the kernel from git and configure new kernel options:

alias cdkup='cd /usr/src/linux ; git pull --rebase && make oldconfig'

This compiles and installs the kernel (if you use lilo):

alias cdkm='cd /usr/src/linux && sed -i "s@\(export.*INSTALL_PATH\) ?= /boot@\1=/boot@g" Makefile && make all -j${threads} && make modules_install && make firmware && make firmware_install && make install ; sed -i "s@\(export.*INSTALL_PATH\)=/boot@\1 ?= /boot@g" Makefile'

The number of threads your cpu has (in the line above) is determined in the following line you can put in your '.bash_profile' or '.bashrc' file:

export threads="$(($(lscpu | grep -E "^CPU\(s\):|^Thread" | sed -e:a -e "/$/N; s@C.*\([0-9*]\)\nT.*\([0-9*]\)@\1*\2@;Ta")))"

So just type, "cdkup" and "cdkm" and set your microwave to 3 minutes for your frozen dish and your kernel should be done before your food is ready.

For compiling mesa and others I just type, "bu ati.modules" (custom .bash_profile environment) and logout and login to make sure the new modules load.

SLACKWARE superior. Ubuntu users inferior.

Disclaimer: I still haven't figured out how to cross compile 32-bit mesa yet even with the seemingly outdated instructions Xorg. For a workaround I will build 32-bit mesa on 32-bit Slackware and migrate the packages to the 64-bit Slackware.

charlie,

Here's the thing. I hate Microsoft, and Apple, and Google. I think proprietary operating systems for computers and smart phones are inherently untrustworthy, and any network-enabled proprietary application is also inherently untrustworthy. I would like to see the entire world move towards Linux, or FreeBSD, or GNU/Hurd, or Firefox OS, or ReactOS, or anything that's fully open.

I know how to use bash aliases, I know how to use sed, and I know my way around Make. I even downloaded, manually compiled, and installed my kernel a few times before - including on Slackware, though it's more than ten years back.

But I can't expect my wife the physical therapist, my sister the librarian and my brothers with their degrees in theoretical math or history, my friend the paralegal, my friend the geologist, etc... to learn those things. They all could learn them if they wanted to. But I have a hard enough time convincing them free software is the right choice for privacy and security, let alone convincing them free software is the right choice for privacy and security and they need to spend a hundred work hours equivalent learning what they need to know to get it running.

So even though I could use Slackware, or Linux from Scratch, or Arch, I'm focused on learning Ubuntu, and Linux Mint, and OpenSUSE because I think those are the distributions that I will have the easiest time convincing non-technology professionals to use.

I respect your skills. Enjoy Slackware, I have nothing against it. But I'm not avoiding Slackware because I lack the skill to use it. I'm avoiding it because I can't recommend it. (Edit: and to be fair, I'm now avoiding Ubuntu in favor of Xubuntu because of that perennial screen locking bug.)

[duby229]

charlie,

Here's the thing. I hate Microsoft, and Apple, and Google. I think proprietary operating systems for computers and smart phones are inherently untrustworthy, and any network-enabled proprietary application is also inherently untrustworthy. I would like to see the entire world move towards Linux, or FreeBSD, or GNU/Hurd, or Firefox OS, or ReactOS, or anything that's fully open.

I know how to use bash aliases, I know how to use sed, and I know my way around Make. I even downloaded, manually compiled, and installed my kernel a few times before - including on Slackware, though it's more than ten years back.

But I can't expect my wife the physical therapist, my sister the librarian and my brothers with their degrees in theoretical math or history, my friend the paralegal, my friend the geologist, etc... to learn those things. They all could learn them if they wanted to. But I have a hard enough time convincing them free software is the right choice for privacy and security, let alone convincing them free software is the right choice for privacy and security and they need to spend a hundred work hours equivalent learning what they need to know to get it running.

So even though I could use Slackware, or Linux from Scratch, or Arch, I'm focused on learning Ubuntu, and Linux Mint, and OpenSUSE because I think those are the distributions that I will have the easiest time convincing non-technology professionals to use.

I respect your skills. Enjoy Slackware, I have nothing against it. But I'm not avoiding Slackware because I lack the skill to use it. I'm avoiding it because I can't recommend it. (Edit: and to be fair, I'm now avoiding Ubuntu in favor of Xubuntu because of that perennial screen locking bug.)

I agree with 100%, but I just don't think Canonicals products should be the ones. They have proven to be anti-community. They only care about themselves. They do spy on you and they sell it just like spyware. I don't see any difference from Canonical and any other malware vendor.