Catalyst 10.1 Still Trash In Heaven, But Good News

[phoronix]

Phoronix: Catalyst 10.1 Still Trash In Heaven, But Good News

We have just received official word from Unigine that they still are not ready to release their OpenGL Linux version of their Unigine Heaven benchmark. "Unfortunately we were asked by a hardware vendor not to release current version :(," said Denis Shergin, the Unigine Corp CEO...

http://www.phoronix.com/vr.php?view=Nzk2MA

[waucka]

I would really appreciate it if AMD would do one of the following:
1. Get their act together with fglrx
2. Abandon fglrx and throw their full weight behind xf86-video-radeon

While I appreciate AMD's support for free drivers, the fact of the matter is that the free drivers do not support things like OpenGL 3. It's annoying that I have to choose between a free driver that doesn't support the technologies I want and a non-free driver that *poorly* supports the technologies I want. Oh, and decent 2D acceleration in fglrx would be nice.

[V!NCENT]

I would really appreciate it if AMD would do one of the following:
1) Either get OpenGL 3.x support with their next release, or;
2) Shut up and just tell the Unigene folks to not wait for them to come with a driver that does OpenGL 3.x instead.

BTW Fglrx should be called Fgl IMO, because it's geared for workstations and AMD just so happens to allow it to work on Radeon cards.

The FLOSS drivers (be greatful they release docs and lend paid-for programmers) are geared for regular consumer computers with Radeon cards.

"ATI sucks! Put some weight behind the linux drivers"
*ATI does this*
"AMD sucks because the driver doesn't work (yet)! Please release the specs so we can make our own"
*AMD does this*
Some random dude: "I would realy appreciate it if..."
ME: "Stop whining"

[blindfrog]

OGL 2.1 is more than enough. All I need is a decent performance for Team Fortress 2 through wine and free drivers are getting close.

[rohcQaH]

2. Abandon fglrx and throw their full weight behind xf86-video-radeon

As far as you're concerned, they do. fglrx is mostly maintained for the workstation customers (and has to be maintained for them), but AMD isn't throwing lots of man-power at it to quickly implement consumer-features like video acceleration or shiny, but useless heaven demos.

Instead, they're developing the OS drivers. They already work very well in a lot of use cases, as far as we can see features are prioritized by end-user needs and the drivers are constantly improving.

If you're saying that the OS drivers don't mature fast enough then that's probably a valid criticism, but it's debatable if development could be sped up by just transfering all fglrx developers to a codebase they don't even know. (besides, if you hate fglrx so much, would you really want those developers to work on the OS drivers? )

[bridgman]

I would really appreciate it if AMD would do one of the following:
1) Either get OpenGL 3.x support with their next release, or;
2) Shut up and just tell the Unigene folks to not wait for them to come with a driver that does OpenGL 3.x instead.

I don't think this is an OpenGL 3.x issue, it's about retrofitting the newest tesselation hardware support (which is *not* part of any OpenGL spec today) into an existing OpenGL 3.2 driver via extensions.

[Sockerdrickan]

AMD's GLSL compiler is really bad. It doesn't support floating point temporaries... I thought GPUs were for floating point operations.

[bridgman]

Are you talking about the fglrx compiler or the open source one ?

I'm pretty darned sure that the fglrx compiler *does* support floating point variables (I think the open source one does as well but not 100% sure off the top of my head) - if you're talking about fglrx is there a specific issue or scenario you are talking about ?

[Sockerdrickan]

Are you talking about the fglrx compiler or the open source one ?

I'm pretty darned sure that the fglrx compiler *does* support floating point variables (I think the open source one does as well but not 100% sure off the top of my head) - if you're talking about fglrx is there a specific issue or scenario you are talking about ?

The proprietary driver does not support floating point. At least not in an OpenGL 3.2 context. The following code will produce black fragments:

out vec4 color;

void main() {
   color=vec4(1.0)*0.99;
}

[agd5f]

All shaders ops are floating point unless you specifically request integers. Older hardware didn't even support integer ops.