Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open Source AMD Driver Now Supports OpenGL 3.3 — and It's Getting Faster

timothy posted about 8 months ago | from the is-it-good-enough-for-you dept.

AMD 100

An anonymous reader writes "With the latest open source Linux code published today the AMD RadeonSI Gallium3D driver supports OpenGL 3.3 and GLSL 1.50; this is the open source Linux graphics driver used for Radeon HD 7000 series and newer, including the new Hawaii GPUs. The OpenGL 3.3 support appeared in patches spread across Mesa and LLVM that should appear in their next releases. It was also found that the RadeonSI driver is becoming a lot faster and starting to compete with Catalyst, AMD's notorious Linux binary driver."

cancel ×

100 comments

Sorry! There are no comments related to the filter you selected.

Non-free Nvidia driver already at 4.4 (-1)

Anonymous Coward | about 8 months ago | (#46065341)

And 3.3 is very old. This is embarrassing for AMD.

Re:Non-free Nvidia driver already at 4.4 (-1, Flamebait)

leathered (780018) | about 8 months ago | (#46065421)

The real embarrassment is that Windows is already up to 8.1, while the Linux kernel is only at 3.1

If my math is correct that's a whole 5 metric torvalds* better.

Get your shit together Linux!

*I think MS still use imperial ballmers, but I'm not sure.

Re:Non-free Nvidia driver already at 4.4 (0)

dreamchaser (49529) | about 8 months ago | (#46065581)

If that was humor it was a fail. Or maybe you were serious and don't understand what 'OpenGL version' means as opposed to other software ;)

Re:Non-free Nvidia driver already at 4.4 (0)

Anonymous Coward | about 8 months ago | (#46065591)

linux kernel is at 3.13 right now! :)

windows 8.1 is at version 6.3.9600 (just run a ver on a cmd in windows to check!)

finally fedora is at version 20, mint at 16, even slackware is at version 14.1 ... so they are cleary a lot better than windows!! :D

Re:Non-free Nvidia driver already at 4.4 (1)

aliquis (678370) | about 8 months ago | (#46065627)

At least Slackware is at 14.1. .. after a sprint through 4, 5, 6 to 7 to finally catch up to where Redhat was! ;D

Big version numbers - It matters!

Re:Non-free Nvidia driver already at 4.4 (1)

aliquis (678370) | about 8 months ago | (#46065643)

Well, that and Firefox finally having catched up with the development speed of Chrome.

Firefox 26.0! ;D

Firefox - Browser for nerds, version numbering for idiots!

Re:Non-free Nvidia driver already at 4.4 (1)

David Gerard (12369) | about 8 months ago | (#46071669)

Bah, that's nothing - Less [wikipedia.org] is up to version 458. Get it together, Firefox!

Re:Non-free Nvidia driver already at 4.4 (1)

mcneely.mike (927221) | about 8 months ago | (#46065689)

The real embarrassment is that Windows is already up to 8.1, while the Linux kernel is only at 3.1

If my math is correct that's a whole 5 metric torvalds* better.

Get your shit together Linux!

*I think MS still use imperial ballmers, but I'm not sure.

We measure in 'Courics', not torvalds... yes we have our shit together. :)

Re:Non-free Nvidia driver already at 4.4 (1)

Anonymous Coward | about 8 months ago | (#46066205)

Three metric Torvalds should be enough for anybody.

Re: Non-free Nvidia driver already at 4.4 (0)

Anonymous Coward | about 8 months ago | (#46066419)

Sure but IE only goes to 11, while open browsers like Chrome(ium) and Firefox are over 8 bits!

Re:Non-free Nvidia driver already at 4.4 (4, Insightful)

Suiggy (1544213) | about 8 months ago | (#46065521)

How is it embarrassing? Several current and former AMD employees work on the Gallium 3D driver implementation as a side project, people like Tom Stellard. If anything, AMD is reaping the benefits of having opened up their hardware documentation.

Re:Non-free Nvidia driver already at 4.4 (-1)

Anonymous Coward | about 8 months ago | (#46069771)

Several current and former AMD employees work on the Gallium 3D driver implementation as a side project...

I sure hope not. AMD software engineers are a cancer damaging the reputation of otherwise good hardware with their amateurish programming.

Re:Non-free Nvidia driver already at 4.4 (4, Insightful)

wertigon (1204486) | about 8 months ago | (#46065681)

Non-free AMD driver is also up there somewhere. Can't find exact version for Linux but whatever, it's probably at 4.2 or later.

The problem is more that MESA only supports 3.3 - But the free drivers (e.g. Nouveau) does NOT support 3.3 so AMD is actually better at the moment. I do believe Nouveau will get 3.3 support soon however.

The real news here, though, is that performance of the free drivers are catching up to the proprietary drivers. That means AMD can ditch the proprietary drivers completely within a couple of years - which, if they can stay afloat that long, means great news for us Linux desktopers! :)

Re:Non-free Nvidia driver already at 4.4 (2)

Mashdar (876825) | about 8 months ago | (#46066191)

Catching up to the closed AMD drivers is a pretty low bar if we are talking about Linux performance...

Re:Non-free Nvidia driver already at 4.4 (1)

Kjella (173770) | about 8 months ago | (#46069753)

Catching up to the closed AMD drivers is a pretty low bar if we are talking about Linux performance.

Depends on what we're talking. The first is simply catching up to the current standards - does the open source drivers even run the same code as the closed source ones. On this they're 3-4 years behind the "state of the art", OpenGL 3.3 was released in March 2010. The second part is catching up to Catalyst in performance - the open source team has said they don't have the manpower to make as many special cases as the Catalyst team, they're aiming at 60-70% performance. Maybe the open source drivers integrate better than proprietary ones, but if AMD produced an OSS driver that was strictly superior to Catalyst it'd be huge.

Re:Non-free Nvidia driver already at 4.4 (1)

bzipitidoo (647217) | about 8 months ago | (#46066283)

ATI/AMD promised decent performing open source drivers years ago. I would like to have seen this promise fulfilled much sooner. This is progress, but still not all they promised. Couple of years, sigh.

So I've bought in each camp. My 3 most recent computers--2 of which aren't very recent any more-- are an Intel CPU with Nvidia (a fanless GT 610, upgraded from the original 8500GT when the fan went bad), an AMD CPU with Radeon (HD 5400), and the newest is an Intel CPU with Intel's much improved HD line of integrated graphics (HD 4000). It's all low end graphics, just barely good enough to handle high end games at slow framerates and/or small resolutions. I'm more interested in low power, low noise, and reliability. I'm still waiting for a vendor to have high performance and quality open source offerings. Such a thing would inspire me to get a new desktop sooner.

Re:Non-free Nvidia driver already at 4.4 (1)

fast turtle (1118037) | about 8 months ago | (#46066627)

Then you want a Haswell chip with the HD4600 - any of the i5/7/E3 xeon's will do as the performance is much better then the HD4000. The only caveat to using a new Intel CPU is 8GB of memory is the minimum needed to really get any advantage from them. Otherwise stick with what you have

Re:Non-free Nvidia driver already at 4.4 (0)

Anonymous Coward | about 8 months ago | (#46067633)

why 8GB?

Re:Non-free Nvidia driver already at 4.4 (0)

Anonymous Coward | about 8 months ago | (#46067895)

I've heard of using fast DDR3 on AMD APUs, but why does 8 GB on Intel chips make a graphics speed difference (not that 8 GB shouldn't be the minimum anyway)?

Re:Non-free Nvidia driver already at 4.4 (1)

msobkow (48369) | about 8 months ago | (#46068341)

Nouveau can't even support a 1600x1200x32bit 75Hz refresh monitor. It puked for me on anything more than 1280x1024.

Absolutely useless.

Re:Non-free Nvidia driver already at 4.4 (1)

oreiasecaman (2466136) | about 8 months ago | (#46082713)

Absolutely useless for me

FTFY

Re:Non-free Nvidia driver already at 4.4 (1)

Xicor (2738029) | about 8 months ago | (#46066463)

linux hates the proprietary nvidia drivers...i once spent a day trying to install those... i was successful in bricking my computer 3 times before i gave up. i never did manage to actually install the drivers.

Re:Non-free Nvidia driver already at 4.4 (1)

TyFoN (12980) | about 8 months ago | (#46066567)

In arch linux it's as simple as
  pacman -S nvidia

How did you manage to brick the PC btw?
Did it destroy your bios?

Re:Non-free Nvidia driver already at 4.4 (1)

Xicor (2738029) | about 8 months ago | (#46066719)

i meant the OS... had to reinstall. in fedora, normally it would be as easy as yum install, but it wont install while you have any other drivers currently on. if you want to install it, you have to turn off graphical mode and install it... but then it will tell you that it cant because of some stupid file somewhere, which you then have to go modify.... then if you try and install it again after modifying, it will install... but alas, now you cant boot up. you will get stuck on the loading page for fedora, so you go back to the text mode and try to revert your changes and go back to what you had before, and if that doesnt work you have to reinstall the os again.

Re:Non-free Nvidia driver already at 4.4 (1)

jc79 (1683494) | about 8 months ago | (#46067667)

You can install the Catalyst drivers from RPMFusion non-free

yum install akmod-catalyst

No need to run horrible install scripts from self-extracting archives and bork your system.

Re:Non-free Nvidia driver already at 4.4 (1)

Xicor (2738029) | about 8 months ago | (#46068147)

yea, the akmod-nvidia will stop the bootup on fedora 20(at least last time i checked)... it has the same problem.

Re:Non-free Nvidia driver already at 4.4 (0)

Anonymous Coward | about 8 months ago | (#46067279)

I've been running linux for sixteen years, and using the commercial Nvidia drivers for the last eight. Not once have I 'bricked' a machine. What the fuck does that mean in the context of a workstation, anyway? Boot single user already with a few key arguments and repair the system.

As a sysadmin who has run both production servers in a business environment as well as computer science labs at two major universities I say the problem is you.

Re:Non-free Nvidia driver already at 4.4 (0)

Anonymous Coward | about 8 months ago | (#46068517)

It should mean the BIOS is not longer operational, and cannot be recovered without an external reflash

if you're not part of the solution... (0)

Anonymous Coward | about 8 months ago | (#46076277)

Not everyone who wants to (or has to) use Linux has sixteen years of experience administering Linux machines.

It's easy for a beginner to get something wrong when setting up a Linux machine which will prevent X from starting properly. With nothing on screen that says "click here to fix problems", a beginner will have to use another machine to search the internet for help. Meanwhile that first machine is rendered non-functional until the GUI is revived. It might as well be a brick.

And when a beginner searching for clues encounters attitudes like the one you're displaying there, that beginner is likely to say "oh to hell with this, I'm going back to Windows", or "never mind, I'll just get a Mac". And then the problem is you, too.

Re: Non-free Nvidia driver already at 4.4 (1)

waslap (1453217) | about 8 months ago | (#46067753)

You must be extremely unlucky. We have supplied hundreds of linux based systems with only nvidia gpu's to customers and never once bricked a system. To be frank, installing an nvidia driver on linux is a non-event regardless of the distribution.

Re:Non-free Nvidia driver already at 4.4 (1)

AaronW (33736) | about 8 months ago | (#46067983)

I have found the nVidia drivers to be extremely easy to install. I have been running nVidia for years on several computers and generally their drivers just work. I have run into frequent problems with the Intel drivers such that on my netbook if power management kicks in on the screen it will never recover. Years ago I had a nightmare with the AMD drivers and Intel drivers. We had a computer where it was impossible to get the Intel drivers to work at all. We ended up buying a cheap nVidia card because their closed source drivers just work. I have had far fewer problems over the years with the nVidia drivers than I have had with Intel and AMD drivers.

Re:Non-free Nvidia driver already at 4.4 (1)

Xicor (2738029) | about 8 months ago | (#46068161)

this is the opposite experience from what ive had. i have never had any issues with amd cards on linux... but every time i try to do things with nvidia on linux i run into problems. it is possible that my issue is simply nothing other than the drivers not being very good for the newer nvidia gpu, but nonetheless, ive never had a good experience with nvidia on linux

Re:Non-free Nvidia driver already at 4.4 (1)

khellendros1984 (792761) | about 8 months ago | (#46069943)

I've got an AMD HD7870 in my desktop, an Nvidia GTX 540m in my laptop, and an Intel HD3000 in an older netbook. I remember starting the kernel in single-user mode to install the Nvidia driver, but that wasn't hard. The Nouveau driver kind of sucked (bad performance, tearing, etc), but the non-free driver has treated me pretty well.

The AMD installer runs under X. I had a previous AMD video card in here (from about 3 years ago), so I didn't have to do much more than install an updated driver. It doesn't look like I did any customization to the config though, so it was probably pretty close to working as soon as I installed the driver.

The Intel chipset was the only one that "just worked" acceptably with in-kernel drivers. Still, I can't see that I've seen any terrible problems with driver installation on any company's GPU in recent memory.

Re:Non-free Nvidia driver already at 4.4 (0)

Anonymous Coward | about 8 months ago | (#46066559)

Two things:

1) AMD's proprietary drivers are at the same (or close to) OpenGL version as Nvidia's. (They might be at 4.3?)

2) No games that I'm aware of require OpenGL 4+ -- partially because that would preclude large segments of the gaming population (due to hardware that doesn't support OpenGL4+) as well as the fact that OSX only *just* got support for OpenGL4+ in Mavericks (and thus, again, forcing OpenGL4 would preclude a lot of Mac gamers).

In short, you'll find that the vast majority of OpenGL games require, at the highest, OpenGL 3.3. This puts Mesa in a good position. And there's speculation that we'll get OpenGL4 on the dev/git releases by summer.

4.0? (1)

mraeormg (3480869) | about 8 months ago | (#46065343)

Why not start working on 4.0 instead of older versions?

Re: 4.0? (3, Informative)

Therad (2493316) | about 8 months ago | (#46065351)

Because 3.3 is a subset of 4?

Re: 4.0? (0)

Anonymous Coward | about 8 months ago | (#46065377)

But doesn't that mean that they will get 3.3 for free if they go directly with 4.0?

Re: 4.0? (1)

Anonymous Coward | about 8 months ago | (#46065409)

If by "free" you mean "a lot more work" then yes. They can directly go to 4.

Re: 4.0? (1)

Anonymous Coward | about 8 months ago | (#46065511)

Getting everything done is the enemy of getting something done.
Getting 3.3 supported and then 4.0 is probably faster than going for 4.0 directly.
I know that it sounds retarded but in my experience trying to do everything at once usually puts you in a situation where you do the wrong things.

Re: 4.0? (2)

Noughmad (1044096) | about 8 months ago | (#46065529)

Getting everything done is the enemy of getting something done.

This works both ways, unfortunately.

Re: 4.0? (2)

jonwil (467024) | about 8 months ago | (#46065605)

To get to 4.0 they have to do all the work for the things in 3.3 AND all the work for things in 4.0 but not in 3.3. Therefore it makes sense to do all the work for the 3.3 things first so the driver can say "I support OpenGL 3.3" then after that, start working on the rest of the 4.0 support.

Re:4.0? (0)

Anonymous Coward | about 8 months ago | (#46065389)

OpenGL cut out a lot of duplicate (and slow) functionality with 3.1, every OpenGL version after that only adds to 3.1.

Re:4.0? (2)

jones_supa (887896) | about 8 months ago | (#46065597)

Yes, it threw out a lot of legacy functions. But let's not forget that you can do modern, clean shader-based programming even with OpenGL 2.0 if you just leave the deprecated functions out of your code. Even with OpenGL 1.4 through ARB extensions. :)

Re:4.0? (1)

robthebloke (1308483) | about 8 months ago | (#46067339)

So long as you are prepared to use a noticeably different GLSL version to GL3+ (with differing syntax), and don't mind designing your code around pre-HW instancing, and don't mind doing lots of work on the CPU that could be done using transform feedback, and don't mind the lack of vertex array objects, and don't mind manually setting every individual uniform param separately (instead of loading them in a uniform buffer), and don't mind the inability to manually specify the vertex attribute layouts from within the shader, and don't mind the inability to specify the fragment shader outputs (since GL2 only specifies gl_FragColor); then yes you could do 'clean shader-based programming' (albeit a variation of shader based programming that has none of the functionality you'd expect to find in a clean shader-based programming API, thereby forcing you to do far more in C than should really be necessary). The AC was bang on the money, but I fear you've missed the point by quite some margin....

Re:4.0? (0)

r1348 (2567295) | about 8 months ago | (#46065551)

Why not trying having the tiniest clue on what the hell you're talking about?

Re:4.0? (0)

Anonymous Coward | about 8 months ago | (#46065651)

Yes, this. Perhaps by asking a question rather than making a statement. I'd suggest starting with something like "Why not start working on 4.0 instead of older versions?" Then people will reply explaining why they might not have started working on 4.0 instead of older versions.

Re:4.0? (1)

wertigon (1204486) | about 8 months ago | (#46065825)

Because the open source implementations are tied to the MESA project - whatever MESA supports is possible to support, although not required to support.

Anything MESA doesn't support, well, is impossible at the moment.

Re:4.0? (0)

Anonymous Coward | about 8 months ago | (#46066403)

The do hit the low hanging fruit first, Anythin in the current specification is fair game to work on, but in general it makes the most sense to sork up.

...Sigh (0)

Anonymous Coward | about 8 months ago | (#46065347)

Not content with his self referential, self saucing pudding of a site Phoronix, Michael Larabel has taken to posting anonymously on Slashdot!

Re:...Sigh (1)

haruchai (17472) | about 8 months ago | (#46066249)

Hi Mikey!!

The firmware remains proprietary (0)

Anonymous Coward | about 8 months ago | (#46065353)

And you can't do shit without the firmware...

Re:The firmware remains proprietary (2)

CurryCamel (2265886) | about 8 months ago | (#46065419)

This is what I hate about GPU (opensource) drivers. Never EVER can anyone give full explanations on what the heck is going on.
Instead we get oblique hints which more or less equals "RTFS". Or in some rare cases, RTFM.
Every time I try to google this stuff up, I ragequit in despair after two hours.

Re:The firmware remains proprietary (3, Interesting)

jkflying (2190798) | about 8 months ago | (#46065537)

Releasing the firmware source would be pointless, since there is no available compiler which could target the hardware. They'd have to release the compiler and hardware specs as well.

Re:The firmware remains proprietary (1)

adolf (21054) | about 8 months ago | (#46065655)

They'd have to release the compiler and hardware specs as well.

And this is a problem...how, exactly?

Re:The firmware remains proprietary (1)

Anonymous Coward | about 8 months ago | (#46065687)

Well, it probably uses patented crap by half a dozen different companies who will all want a non-zero fee for it to be distributed, if they'll agree at all. The same reason why even 15+ year old games can't be open sourced, because of all the middleware dependencies used to make the trees and clouds and things would have to be licensed too.

Re:The firmware remains proprietary (1)

wiredlogic (135348) | about 8 months ago | (#46066953)

And yet there was a time then IBM provided full schematics and BIOS listings to their original PC for the modest cost of the paper they were printed on.

Re:The firmware remains proprietary (0)

Anonymous Coward | about 8 months ago | (#46067139)

IBM owned the BIOS and the hardware IP, dumbass.

Re:The firmware remains proprietary (0)

Anonymous Coward | about 8 months ago | (#46068275)

This.
Anyone who has ever worked in a company that produces hardware knows exactly why they are hesitant to release anything.
Another major reason is because they don't want their competitors to get a look at the code unless they are absolutely sure that there won't be anything surprising to find in there.

Re:The firmware remains proprietary (1)

jkflying (2190798) | about 8 months ago | (#46082829)

It exponentially increases the amount of code that would have to be reviewed for proprietary secrets and patent infringement. On the other hand, just releasing the drivers wouldn't be as much of an issue, since they just target an interface that doesn't reveal what happens on the other side.

Re:The firmware remains proprietary (0)

Anonymous Coward | about 8 months ago | (#46069701)

Releasing the firmware source would be pointless, since there is no available compiler which could target the hardware. They'd have to release the compiler and hardware specs as well.

Nah, it would help. It might not alone be enough for something useful, but it would not be pointless or useless.

It would have many uses, although not necessarily for people who only want a driver for some particular hardware.

Re:The firmware remains proprietary (1)

Anonymous Coward | about 8 months ago | (#46065603)

if you need to know something, ask in the proper mailling list... all this change everyday, mesa and graphic card drivers are under heavy developement, so the developers are the ones to know best what is going on (and even then, different developers work on different things)

Re:The firmware remains proprietary (3, Informative)

Kjella (173770) | about 8 months ago | (#46066491)

This is what I hate about GPU (opensource) drivers. Never EVER can anyone give full explanations on what the heck is going on. Instead we get oblique hints which more or less equals "RTFS". Or in some rare cases, RTFM. Every time I try to google this stuff up, I ragequit in despair after two hours.

So you're saying you can't write Java without understanding how the JVM is built? The firmware provides you with a very low level API that is very similar to assembler, it's more like runtime-loaded microcode than normal code. If you really care to try, I suggest you start here [x.org] . Basically you place commands into a ring buffer that is read by the command processor (CP) on the graphics card and then executed on the GPU. There's a ton of registers you can set up, tons of commands, tons of formats (like all the texture formats) and while it is documented it's literally thousands of pages all together.

For example, for the Southern Islands generation alone there is:
229 pages of 3D register documentation
298 pages of instruction set architecture
49 pages of programming guide which expands the
54 pages of evergreen/cayman programming guide which expands the
43 pages of R600/700 programming guide.

Those 700 pages only walk you through the very basics of programming the GPU though, like assembler for a CPU. Beyond that there's very little in the way of tutorials, look at the existing source and figure out what it does down to the registers it sets and commands it sends. By the way, if things are not done in the right order the behavior is often undefined and may lead to soft or hard lock-ups. Personally I gave up because I realized the massive complexity of a modern GPU, quite frankly programming it at this level is extremely difficult.

Re:The firmware remains proprietary (4, Insightful)

Anonymous Coward | about 8 months ago | (#46065465)

Both hardware and firmware are proprietary, the main feature of an open source driver is that it replaces binary blobs in kernel space. Basically it makes it easier for kernel developers to track down bugs since they can debug everything that runs within kernel space. While the buggy firmware can still kill your GPU that is isolated from the remaining system and easier to track down than a driver with write access to everything.

Re:The firmware remains proprietary (0)

Anonymous Coward | about 8 months ago | (#46066091)

That's surely not ideal, but it's not really a huge concern unless you really can't live with compromises.

For the future:
http://sourceforge.net/projects/openradeonbios/

Re:The firmware remains proprietary (0)

Anonymous Coward | about 8 months ago | (#46071621)

Interesting, thank you!

competing with catalyst (1)

Anonymous Coward | about 8 months ago | (#46065415)

Fuck a duck they are setting the bar pretty low if their goal is to compete with AMDs Catalyst Drivers, the official AMD Drivers on both Windows & Linux are junk.

AMD should be ashamed of their official drivers, you would think after all these years they would have got a grip of their developers & started to produce some decent reliable drivers but alas this is not the case you have to manually delete files when removing the drivers as the drivers are too fucking dumb to remember where they installed files & on Linux you have to recompile the drivers every time the wind changes direction with kernel updates or xorg updates etc which is like an exercise in pulling teeth.

If you want to do any proper number crunching stuff with your AMD/Ati card the open source drivers aint worth a wank & you're forced to use the crapware official Catalyst Drivers & Associated Extras.

There is a long long way to go before AMD cards will have decent fully functioning open source drivers, but that's not to say there isn't good work being done by developers because there is but AMD & Nvidia both needs to take a large portion of blame with how obstructive they are in holding back open source drivers, which is a shame because both vendors officials drivers produced by their own devs are utter junk in many areas.

Re:competing with catalyst (1)

aliquis (678370) | about 8 months ago | (#46065599)

That's what I was going to say.

"It's easy when you aim low. How are your drivers doing against Nvidias Linux drivers AMD?", though my impression is that they have improved (also relative.)

I have no experience actually using them so I don't know how much suffering it is (even with a good distribution with a drivers package?) and I don't know how much blame should be put on Linux & others (You're of course free to argue that it wouldn't be a problem if the drivers was open-source.)

Re:competing with catalyst (1)

guacamole (24270) | about 8 months ago | (#46065861)

AMD Catalyst drivers are garbage. The other day I installed the latest version (13.something?) on my Samsung notebook and then decided to uninstal them and go back to the old factory video driver version. What happened? Firefox stopped working with some strange errors, IE, and a lot of other applications. It's unbelievable that nearly two decades after Windows 95, there still exist device drivers that can destroy your OS install and force you to install everything. You hear me AMD developers? Your drivers age GARBAGE, both on Windows and Linux (The Linux NVidia drivers were easier to install 13 years ago). Next time I need a good GPU, I just buy Nvidia.

Re:competing with catalyst (0)

Anonymous Coward | about 8 months ago | (#46066193)

Always the same bs ...

There will be plenty of stuff that doesn't work to point at now and in the not so distant future. I don't need "proper number crunching stuff". Do you, really?

The r600g driver works great and gets better all the time thanks to a hand full of devs catching up with man-years of work. My distro works out of the box and it's just so much better than the fglrx days. The open driver is totally usable for a large number of cards.

Re:competing with catalyst (1)

fast turtle (1118037) | about 8 months ago | (#46066667)

Buck a Fuck if you think the AMD driver is shit on Windows - it's all the Ducky Poo Catalyst Control Center that quacks like a moose. I never install anything more then the Radeon Driver from Windows update as it doesn't add the moosely Catalyst Control Center to the system and the latest version depends on dotnet 4 just to work on a windows box.

From a user standpoint, I've found that the Open Driver works well enough for me to get shit done and even game a bit under Wine - framerates can and do drop below 20 at times but hell that happens even in Windows on my card (Ancient Radeon 5670 w/512).

Another useless Phoronix 'benchmark'? (0)

Anonymous Coward | about 8 months ago | (#46065505)

The hilarious thing about Phoronix benchmarks comes together on the last page, where under the graph showing gallium3d and catalyst tied in fumark gpu testing the explication casually tossed was "The Furmark rendering on RadeonSI Gallium3D wasn't correct compared to Catalyst"

What is the point of showing *big improvements in speed* if you don't compare rendering accuracy? They do wrong things much faster than before?

Re:Another useless Phoronix 'benchmark'? (1)

maxwell demon (590494) | about 8 months ago | (#46065647)

An interesting strategy indeed.

I hereby present my constant-time prime factorization algorithm. It works by always returning 2 and 3. Sure, it's not correct (unless you've tried to factorize 6), but it's fast as hell.

Call me jaded, but.... (-1, Flamebait)

adolf (21054) | about 8 months ago | (#46065621)

I'm amused that this is still even an issue.

AFAICT, the state of the art of open Linux video drivers hasn't actually advanced, in the relative scheme of things in at least fifteen years: Things still just barely work, doing somewhat new things, at best.

(Oh, sure: The desktop can be stable...sometimes. But I had a stable...sometimes desktop in 1999, too.)

Re:Call me jaded, but.... (0)

Anonymous Coward | about 8 months ago | (#46065771)

As you wish: you are jaded.

Re:Call me jaded, but.... (1)

jones_supa (887896) | about 8 months ago | (#46065865)

I'm amused that this is still even an issue.

AFAICT, the state of the art of open Linux video drivers hasn't actually advanced, in the relative scheme of things in at least fifteen years: Things still just barely work, doing somewhat new things, at best.

(Oh, sure: The desktop can be stable...sometimes. But I had a stable...sometimes desktop in 1999, too.)

Oh, I see it's exactly the opposite. Sure, the graphics drivers are lacking some features and performance, but there's a lot of energy in development. The Freedesktop and Mesa guys react friendly to bug reports and things get fixed. Also Mesa has paid developers from VMware, Intel and Red Hat working on the project. Also Wayland is advancing quite nicely. On the other hand, if we look at the Linux desktop environments, they are the areas where I hands down see the most bugs. KDE seems to have the best quality assurance right now.

Re:Call me jaded, but.... (1)

fast turtle (1118037) | about 8 months ago | (#46067003)

I've been impressed with Fluxbox both the Dev (Yes single dev) and the stability. Sure it's not a full blown destop environment like KDE/Gnome but you know what? I don't need a full bloated DE either. What I want/need is the god damn window manager to get out of my way while offering multiple desktops so I can configure my work flow as needed on each one and fluxbox does all of this for me.

Very few flaws and when I actually reported a bug to the dev, pretty quick turn around on figuring out what the cause was. My end - not his. Mailing list is actually responsive also so the community works well for it.

What I would have loved the KDE devs do is update the 3x line to use QT4 and later while fixing many of the bugs instead, they hurried off creating a god damn clone of Vista with all sorts of extra eye-candy that people simple didn't find useful. Yes the new plasma system is useful for portables and such but they screwed up Kmail, Amarok and a whole bunch of other apps that actually worked pretty well and then added Akondi and the fucking desktop search plus the stinking Database setup for email/contacts and what not. How much did MS pay them to duplicate the fucking features of lookout express/Live Mail? Stupid ghets, someone needs 2million years using WinMe for that.

Re:Call me jaded, but.... (1)

jones_supa (887896) | about 8 months ago | (#46067023)

Yep. The KDE3 / GNOME2 era was a sweet spot in history. The reliability was pretty good, they ran fast and did everything they needed to.

Re:Call me jaded, but.... (0)

Anonymous Coward | about 8 months ago | (#46065885)

And the status of open Windows drivers is....?

This is really the result of naturally closed source companies giving just enough information to open-source projects to make them work, but retaining just enough information to keep it from working well. This is justified by patent and copyright law.

You are free to use the closed-source Catalyst or nVidia drivers. They are actually faster at some things on the same hardware than their Windows counterparts.

Re:Call me jaded, but.... (0)

VortexCortex (1117377) | about 8 months ago | (#46065925)

'Stable sometimes' is remarkable in the absence of hardware MFGs support. It hasn't really been that long since hardware MFGs have gotten behind support for open source drivers. Now that a AAA game developer / publisher / marketplace has come to the free-side of the source, things are looking bright indeed. [pcworld.com]

Folks are waking up to the reality that it might not be in the best interest of their business strategy rely too heavily on another company for their success. Especially not after MS's reception of W8, it's marketplace, and their shady hardware platform dealings (not informing platform partners, no more pre-release for MSDN access, etc). Even if they fix the issues folks are becoming a bit gun-shy now, rightly so. Why needlessly tie yourself to a ship that might sink or make you walk the plank when it's easy to diversify and get free community support and better PR, thus customer loyalty essentially for free? Starting a new software project (esp. game) it costs nothing extra to ensure it runs on all the major platforms. So, the choice is: Hey, we can make it just work with one OS/platform, or for the same effort, pick up the market share of all the other major OSs too by selecting a cross platform engine / toolkit / compiler at the outset.

Since the olden days the hobbyist / tinkerers / free thinkers could be looked to for indication as to the future market place. PC hobbyists all over online digital distribution and 'social networking' in the BBS era, boom the Internet exploded when exposed more broadly. The demoscene led the way showing nifty tricks in software rasterizing, and later in hardware rasterizing, and later in shaders, before mainstream developers had public products. The homebrew hobbyist gamedev scene has been espousing "cross platform or bust" long before AAA studios realized exclusivity was dumb financially, and now the "indie devs" are echoing sentiments such as "games are art, art shouldn't have planned obsolescence DRM death sentences" and such...

It goes back farther than this: The Renaissance heralded the industrial revolution. Stories about adventure and exploration yielded (re)discovery of America, laymen interest in design progress, space, and technology predicted your nuclear and space ages. It's no mistake the 'wacky' robotic fascination of your late 20th century indicated a largely robotic workforce with huge mechanical organisms for continuous production. Ideas seeded in your 'far-fetched' early adopter culture are converging even now to lead you to the next of your great advancements. Take a look around and see.

I'm jaded too, but my outlook is: Well, finally they got their heads out of that recursive anus -- Wonder how long it'll take AAA and MPAA producers to realize DRM is hurting business, and after that to realize Copyright is artificial scarcity lunacy too: You can ask for enough up front, 'give away', that which you've already been paid you to create, and your competition can't compete with 'free'. Lots of little devs are starting to test the waters of that route: less churn, more stability, free publicity / advertising, more freedom and creativity, zero piracy, simply continue working to continue earning money... just like any other labor market. Just look how long it took those dumb apes to figure out folks buy hardware, not drivers. Everyone alive now will probably be about dead by the time that other stuff happens at this rate, but it'll happen eventually. The market forces of economy work. Just look at the doomed printing press industry. I'm just amazed how long you've clung to the horrible concept of idea monopolies -- those will soon be eradicated as a matter of civil rights: People can sue for patent infringement if a machine thinks about an algorithm? Oh, for kracken's sake.

Sure would be nice if by some strange twist of fate I'm still around when all that comes to pass -- Nothing is more rewarding than free sharing of information and technology allowing a culture to reach its full potential. If I'm still on assignment then, I'll invite you to an interstellar LAN party. Protip: focus on the solution, not the problem.

OUYA fizzled (1)

tepples (727027) | about 8 months ago | (#46068231)

Starting a new software project (esp. game) it costs nothing extra to ensure it runs on all the major platforms.

I don't see how that's the case. It costs a lot of overhead money to target the major consoles. Console makers have been more interested in poaching established studios from other platforms than in nurturing startups. And until very recently, an indie studio had to lease a dedicated office rather than operating out of the developers' homes. OUYA is more open than the other consoles of its generation, with an API familiar to Android app developers and official sideloading, but it appears to have fizzled. What makes Steam Machine, the other open console of this generation, less likely to fizzle than OUYA?

Re:Call me jaded, but.... (1)

adolf (21054) | about 8 months ago | (#46071707)

Stable sometimes' is remarkable in the absence of hardware MFGs support. It hasn't really been that long since hardware MFGs have gotten behind support for open source drivers.

I got modded -1 on my original posting, apparently because the yungin's here are too proud to remember their heritage.

Maybe you remember things differently than I do, but back in MY day hardware either came with (printed!) documentation, or had such documentation a letter away.

Now, granted: We didn't have massively-parallel graphics subsystems back then. But we did have complicated printers, and those printers came with manuals. Along with other hardware.

Creative Labs and Gravis didn't expect you to just "figure it out" from a binary blob, they published programming manuals.

And this doesn't happen these days. Go ahead and try to find an AT command reference for the modem in a not-so-old, still perfectly-useful laptop: Good luck!.

For a minute or two, even a video card (where "video card" means something other than a dumb framebuffer) had proper manuals available.

Manufacturers wanted folks to be able to use their hardware. And developers, on all manner of operating systems, supported it. And end-users used (and bought!) it.

We've gone backwards over the past decade or two. Things have taken a turn for the worse. It's not a recent turn, but it is a turn nonetheless. Manuals are sparse, if they exist at all. Programming information is nonexistent.

We wouldn't even be having this discussion if Intel hadn't published documentation for the 80386. And I couldn't even hear your cries if it were not for Creative Labs publishing a (oft-emulated) sound card spec. Nor would I have ever played a 3D game in *nix if 3dfx weren't reasonably open with their GLIDE interface (which worked quite well).

Just sayin'. I remember 15 years ago, when things almost-sorta-usually worked, and I was happy about that. And today things still just almost-sorta-usually work, and I'm still happy about it...but that doesn't make it a success.

Better than monitor rate. (3, Informative)

complete loony (663508) | about 8 months ago | (#46066005)

Looking at those graphs, for those games, the current open source driver is running above the refresh rate of most monitors.

So while the catalyst driver may be faster, in some cases doubling the frame rate, I highly doubt you'd actually notice the difference.

Re:Better than monitor rate. (2)

Type44Q (1233630) | about 8 months ago | (#46066129)

Looking at those graphs, for those games, the current open source driver is running above the refresh rate of most monitors.

So while the catalyst driver may be faster, in some cases doubling the frame rate, I highly doubt you'd actually notice the difference.

Incorrect; it eliminates the need to run with vsync disabled and the subsequent screen tearing that causes...

Re:Better than monitor rate. (0)

Anonymous Coward | about 8 months ago | (#46066231)

N'yuk- n'yuk-n'yuk! We get it you're trying to be funny, but you just compared apples and oranges, in a case where apples vs apples (both with vsync on) supports the GP's claim, and oranges vs oranges might possibly be a difference, but you still don't know how the driver implements buffer swaps, so you really don't know if tearing would be more or less visible at a higher refresh rates.

Re:Better than monitor rate. (1)

fast turtle (1118037) | about 8 months ago | (#46067069)

The only time V-Sync needs to be used is for an SVGA (analog) connection. Otherwise it slows down the redraw of a Digital Connection such as DVI/Display Port/HDMI. So anyone with one of those connections to their display using V-Sync is an idiot/noob that needs to be gutted.

I've been on a DVI connection for over 3 years and disabled v-sync as soon as I moved. Never seen any tearing even when the game drops below 20FPS (I've seen as bad as 5FPS) but I know my card is obsolete (Radeon 5670 w/512).

Re:Better than monitor rate. (2)

tepples (727027) | about 8 months ago | (#46068239)

HDMI still needs frames to be sent at a constant rate unless the monitor supports G-Sync, which is a very new innovation.

Re:Better than monitor rate. (1)

Anonymous Coward | about 8 months ago | (#46068349)

The only time V-Sync needs to be used is for an SVGA (analog) connection. Otherwise it slows down the redraw of a Digital Connection such as DVI/Display Port/HDMI. So anyone with one of those connections to their display using V-Sync is an idiot/noob that needs to be gutted.

I've been on a DVI connection for over 3 years and disabled v-sync as soon as I moved. Never seen any tearing even when the game drops below 20FPS (I've seen as bad as 5FPS) but I know my card is obsolete (Radeon 5670 w/512).

VSync is for when games are rendering faster than the monitor not slower. You will see tearing if you have a game running at 90fps on a 60Hz monitor.

Re:Better than monitor rate. (1)

Type44Q (1233630) | about 8 months ago | (#46072899)

Tearing or no tearing [on a modern flatpanel] , there will be dropped frames - sending the framerate well below the monitor's 60hz refresh rate - unless the vidcard can sustain a high enough framerate with a common denominator of 60hz (say 120, 180 or 240fps)...

Re:Better than monitor rate. (0)

Anonymous Coward | about 8 months ago | (#46066359)

I find many Linux dweebs fail to understand the importance of high FPS. Let's say you playback a 5 minute demo of Left 4 Dead 2 and the frame rate never falls below 85 FPS on a monitor with a 60hz refresh rate. "Well then, 85 FPS is good enough, it doesn't need to be faster, you'll never notice a problem", you say. Hold the phone. While the demo you ran may have dipped no lower than 85 FPS, that's not to say other parts of the game wouldn't cause it to drop even lower, and if it hits below 60 FPS you're really going to notice a problem with Vsync enabled.

You want as many FPS as possible. The higher the frame rate, the less chance that a moment could pop up where the frame rate drops below 60 FPS and cause serious lag. If you're getting a consistent 200 FPS, that's even better. Maybe you could raise the resolution or enable 8x anti-aliasing. Or crank all the game's effects up to maximum. All while being fairly confident the frame rate will never dip below the monitor's refresh rate. Bottom line is, the more FPS the better. It gives the user a better experience and the higher the FPS, the less chance of lag in other parts of the game.

Re:Better than monitor rate. (1)

complete loony (663508) | about 8 months ago | (#46069691)

No, the frame rate doesn't matter. Sure you don't want to drop below 60fps. But that doesn't mean you need to render more than 60fps.

Above 60fps, without waiting for vsync, only a fragment of your rendered frame can possibly be displayed. I have wondered if graphics drivers can take advantage of this to only run the final fragment shader passes for the fragment of the screen that will be drawn.

Re:Better than monitor rate. (1)

waveclaw (43274) | about 8 months ago | (#46066721)

So while the catalyst driver may be faster, in some cases doubling the frame rate, I highly doubt you'd actually notice the difference.

Above monitor performance FPS seems useless until you factor in multi-monitor, screen resolution and multi-boxing. Or that games are more than movies (looking at you Japanese RPGs) and have to actually take input and do processing in between frames. Being able to drop a few frames for better input might just mean that click that keeps you alive makes it into the game. And when the drive is no longer struggling to get a frame to the screen you can move the performance bottleneck elsewhere (like the network in MMOs).

Given a marginal setup like a lot of these F/OSS developers seem to have, just running multiple clients of an online graphical game can drop you from 120-150fps to the mid 30s-50s on your 60 Hz screen. Some games actively encourage this (Eve Online).

Then lets talk about wine. It's not an emulator, but if your game is already slowed by a thunk that thick the graphics stack better be awesome or your game is going to look like crud.

I'm sure there's something in there for 2D plain old apps, too. Maybe less detectible tearing and artifacts while you drag and drop around your office software.

Re:Better than monitor rate. (1)

complete loony (663508) | about 8 months ago | (#46069725)

Input events are usually time-stamped by the operating system interrupts that captured them. On network games, these timestamps can be used by the server to work out after the fact who shot first. While pro-gamers like to say that frame rates higher than the monitor refresh rate help them win. I have yet to see a double blind study to confirm that it actually helps.

Usually network latency is a much bigger and more noticeable problem for this type of after the fact simulation. But the process can be applied equally well to local input events.

Re:Better than monitor rate. (0)

Anonymous Coward | about 8 months ago | (#46066951)

Most of these games are fairly non-intensive. If Phoronix were to benchmark with more modern ones at high settings, you'd definitely see it below 60fps.

Re:Better than monitor rate. (1)

loufoque (1400831) | about 8 months ago | (#46067005)

Of course, since the only games on the list are Quake 3 and Doom 3, games from 1999 and 2004 respectively.
A modern graphics card can finally run 15-year old games at max speed! What an impressive feat.

Re:Better than monitor rate. (0)

Anonymous Coward | about 8 months ago | (#46067213)

You'd see a much different picture if Phoronix bothered to test games that were relevant, even if they were proprietary and had to be run in Wine.

Re:Better than monitor rate. (0)

Anonymous Coward | about 8 months ago | (#46068025)

That has more to do with the ability of PTS to monitor aspects of the game than anything. Michael has been open to the idea of benchmarking Source games, but they broke compatibility recently and it won't be restored for some time.

Radeon driver is working pretty well now (2, Informative)

Anonymous Coward | about 8 months ago | (#46066305)

I was surpriced how well radeon driver is working. I'm not even using the newest version, but still the driver works considerably better on opengl use cases than it did just few years ago.

Nice effort (0)

Anonymous Coward | about 8 months ago | (#46066509)

It's a good start, but there's a long way to go.

It was also found that the RadeonSI driver is becoming a lot faster and starting to compete with Catalyst

If it is just starting to compete with Catalyst, then it is still unusable. I installed Mint 16 Petra recently on this machine. I used the binary AMD driver (for a Radeon HD 6870), and the video performance was terrible. Sure, everything looked and functioned properly (no crashes or weird artifacts as other ACs are experiencing), but it was slow as dirt! Not only that, but the fan was cranked up and the card was putting off way more heat than it should while idle! What in the actual fuck are you doing, AMD?

Scrypt-Coin GPU mining? What impact does this hav (0)

Anonymous Coward | about 8 months ago | (#46066893)

What impact does this have on mining Scrypt based coins using AMD GPUs?

Re:Scrypt-Coin GPU mining? What impact does this h (0)

Anonymous Coward | about 8 months ago | (#46066981)

Not much, if any. You will already get better performance GPU mining with Linux than with Windows. You'll use OpenCL, not OpenGL, so improvements to OpenGL do not help.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>