Phoronix Readers Are Still Mostly Relying Upon Proprietary Linux GPU Drivers

[Nille_kungen]

I use open-source (radeon), it's quite good.
But : it needs 4 FIRMWARES (blobs, closed source)
R600_rlc.bin RS780_me.bin RS780_pfp.bin RS780_uvd.bin
So open source doesn't mean "100% open source" actually.

Atleast there rather small

ls -lh /lib/firmware/radeon/{RS780_*,R600_rlc.bin}
-rw-r--r-- 1 root root 3,0K nov 13 04:41 /lib/firmware/radeon/R600_rlc.bin
-rw-r--r-- 1 root root  21K nov 13 04:41 /lib/firmware/radeon/RS780_me.bin
-rw-r--r-- 1 root root 2,3K nov 13 04:41 /lib/firmware/radeon/RS780_pfp.bin
-rw-r--r-- 1 root root  89K nov 13 04:41 /lib/firmware/radeon/RS780_uvd.bin

You may be surprised: http://www.intel.com/content/www/us/...downloads.html
(Technically they're PowerVR, but, y'know.)

I didn't think anyone actually use it since it needs really outdated software to work and is full with bugs.
I got some intel PowerVR hardware and i don't run linux on it.

[bridgman]

re: DPM for radeon, that was only 2-1/2 yrs ago and was a pretty significant chunk of code as well:

http://www.phoronix.com/scan.php?page=news_item&px=MTM5NjE

[GreatEmerald]

I didn't think anyone actually use it since it needs really outdated software to work and is full with bugs.
I got some intel PowerVR hardware and i don't run linux on it.

As you can see on the website I linked to, it needs really outdated versions of Windows too. So on my Oak Trail tablet I have both Windows and Linux installed (though of course the latter is using gma500-gfx instead of emgd).

[Kano]

I am sure your open source star shines much brighter than those from binary driver users. I hope you wiped all Windows partitions 10 times not that they could give a bad light on you while you play games.

Your comments are very unfair against other Linux users - there should be no competition on who is using more open source than others - especially while playing games!

[Cyber Killer]

I tried to use the mesa drivers on OpenSUSE 13.2 with my Radeon R7 250X (got it as a replacement for a broken HD7770, which should run ok with mesa, but it's no longer produced :-( ) and while it seemed to run good, the system couldn't last an hour without a kernel panic. Everything went fine after I installed fglrx (except I get constant desktop glitches).

A new OpenSUSE version came out this month, I'll be sure to try mesa drivers again in this version.

[Awesomeness]

I think many Intel users also use another GPU like nvidia

Most PCs sold are laptops. Although there are laptops with a secondary GPU (I own one myself), it's hardly the majority. Intel-only models are the norm. Therefore I stand by my assessment that the poll is BS.

[Ardje]

Though ARK survival is unplayable - but it seems to be very poorly optimized in general.

Although a great game, on an R9-270, a core i7 920 and fglrx 15.9 it's barely playable on the lowest settings.

[Nille_kungen]

Most PCs sold are laptops. Although there are laptops with a secondary GPU (I own one myself), it's hardly the majority. Intel-only models are the norm. Therefore I stand by my assessment that the poll is BS.

Well it depends in what country you are located, in some countries there is hard to find laptops whitout an secondary GPU.
The point was that many might answer blob when infact they use open source + blob.
This poll on twitter doesn't say a thing more then that many phoronix readers doesn't use twitter.

[SystemCrasher]

Works for me

Not sure what exactly works for you. Calling ath9k_htc 120% open?

Seriously though, I think it's even better to treat the driver and microcode/firmware images separately and stop at 100% for each.

Speaking for myself, I consider best "treatment" for proprietary blobs to be an axe in their head :P. Because these blobs tend to be abused a lot and used for doing various dirty, treacherous, unwanted and troublesome things. You see, this approach once has been taken in proprietary software. Giving spark to open software, where it happens other way. Something to think of...

There is a whole continuum of complexity in those images, with the state machine tables for our GDDR5 memory controller (the MC microcode) at one end and (probably) the on-chip networking code in a NIC at the other.

TBH last ting I need or want is NIC running smartass microcode. This opens whole venue for stealthy, unobvious attacks/backdoors/etc. And as practice shows, one can really count on backdoors, hacks and bugs would be plaguing this stuff. While I can understand some things are easier to do in microcode, vendors are getting bitching on it, imlementing unwanted or even exceptionally harmful misfeatures like backdoors, DRM, etc. Giving a birth to "treacherous computing". Somehow I'm not fond of treating users like an idiots who only deserve total pwnage.

You can make a good case that the networking code in a NIC is "doing the same thing as a driver would", but you would have a very tough time making that case for most of the microcode images in an AMD GPU or CPU.

Speaking for myself I would aggressively avoid microcoded NICs for security reasons. Furthermore, I would do heavy evaluation of ways to pwn/backdoor system I'm implementing for my customers as well, etc.

It is very likely there is not going to be proper description what microcode does, what it can do, but in case of NIC it can access network, and probably do some dangerous things like DMA. So NIC like this is imediately classified as "very dangerous" and "potential backdoor". That's what you get for putting DRM, backdoors and other bootguard like crap to hardware. Trust is easy to lose and hard to regain. And no, there are no reasons to trust blobs.

Though, say, MC state machine seems to be "relatively harmless". E.g. even if it happens to be turing-complete and can expose nasty attitude, I have major trouble to imagine how it can pwn main system in more or less efficient and working ways. So I do not have major objections against ucode of MC state machine on GPU side.

The one exception I could agree with is recent MEC microcode, which implements a low-level scheduler for compute queues, and which IMO only makes sense to perform on-chip rather than in the driver because it allows very rapid scheduling (down to 1ms granularity) without having to wake up the CPU that frequently. Still tempted to move that functionality back to the driver in Linux even if we leave it in microcode for Windows.

Quite an interesting edge case. I guess driver side would allow far more advanced policies/limits/etc (like it happened to CPU scheduler) and at the end of day it seems GPUs are going to be more or less like special kind of CPUs, so when someone would want advanced policies, ucode scheduling can quickly turn to restriction. But yeah, I can imagine waking up CPU isn't good. As purely crazy and theoretical idea, I can imagine it can be smart to do CPU and GPU scheduling in one shot, saving on wakeups, and using CPU-side latency. Though I can imagine current infrastructure is nowhere near allowing such a wild and strange things, and while it more or less settled for CPUs, I guess there is way to go for GPUs and AMD is pioneering this direction. Well, AMD has been always good in this .

So GPUs got VM, schedulers and so on. Seems multi-tasking on GPU is going to be norm. And Xeon Phi is just ahead of its time and just damn overpriced, as well as anything else from Intel . They had chance to show how to do it right. But it would not happen, somehow. I.e. I would rather count on GPUs evolving more of Phi-like things gradually.

And don't get me started on CPU microcode

Speaking for myself I've got really fed up with crap like signed ME firmware from intel during boot sequence and somesuch. And if hardware manufacturers would insist on it, somehow I already got idea I'm not going to use x86 as my next mobile device at all. You see, opensource software is getting used to create open hardware, and the very same process spins up for hardware. And it easier to do with something non-x86, obviously. Because x86s are overengineered crap with shitload of legacy under the hood. And so I can have blob-free boot sequence. Especially on main CPU, where I really care about it.

[twriter]

I use the AMD open source drivers.

I don't use twitter.