Slashdot Mirror
Open Source AMD Driver Now Supports OpenGL 3.3 — and It's Getting Faster
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."
Because 3.3 is a subset of 4?
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.
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.
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.
Getting everything done is the enemy of getting something done.
This works both ways, unfortunately.
PlusFive Slashdot reader for Android. Can post comments.
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.
Help I am stuck in a signature factory!
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. :)
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.
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! :)
systemd is not an init system. It's a GNU replacement.
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.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Catching up to the closed AMD drivers is a pretty low bar if we are talking about Linux performance...
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.
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. 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.
Live today, because you never know what tomorrow brings