Radeon Software Crimson Edition Will Reportedly Offer Better Linux Performance

[xeekei]

Won't this only apply to GPUs supported by it (300-series and higher)?

It would only apply to GPUs actually using the AMDGPU kernel driver, yes.

[dungeon]

Why not bring the latter driver up-to-par performance-wise?

Nothing will stop you for doing so, it is opensource drivers - anybody who can code might try to do something about perfromance... Catalyst OpenGL is mostly per app driver approach, so they did profiles . On the other hand ask any opensource devs what they think about that idea

First question will be - Is it easy to maintain?
No.
OK who will maintain that?
We
Who are we? Go away

Basically... what's the point in keeping the proprietary driver around instead of phasing it out and improving the open-source driver?

It is same point as Wayland was not on Desktop 5 years ago. Which means X is used, you have users to support and even now that Wayland is not actually even finished yet.

It is really like that, if openosurce drivers at some point in time are really better AMD will happely drop some parts of Catalyst... until then they have some users to support.

[pete910]

Only skim read it, anything on freesync ?

[computerquip]

Opensource extremists again

Opensource drivers should implement threaded GL and shader cache, with those you will be mostly where Catalyst is now by perfromance in gaming

I use both Catalyst and radeon drivers and i don't complain, why some else complain i dunno

Uh... a shader cache doesn't help with the realtime performance, only shader compilation. This would be nice but there are other more important issues... it would also be nice if OpenGL would accept Spir-V as an extension which would immediately remove a lot of the syntactical parsing required at runtime.

Threaded GL is also more or less a myth. For one, OpenGL already does certain operations asynchronously, such as rendering itself. You draw, it immediately returns, and hopefully the operation is done by the time you flip buffers (otherwise it must wait until it is). The point of GL_THREADED_OPTIMIZATIONS with nvidia is to off-load certain CPU-based operations (such as glDrawPixels I think) which should be avoided in the first place, especially since most drivers don't support such a thing.

EDIT: I'm no graphics driver developer. This is simply from behavior I've observed during my testing, perhaps ignoring details of the specification itself.

[Brillus]

It's understandable that fglrx does have some benefits over the open-source driver... but isn't that just all the more reason to focus on the open-source driver instead?

From my general understanding, we have one driver that has pretty good performance in some situations, but you have another driver with more platform support, stability, and flexibility, but lacking in performance in the situations where the former driver excels. Why not bring the latter driver up-to-par performance-wise? Or is there other reasons where Catalyst/fglrx excels that isn't performance (and can't those same reasons also be improved on open-source)?

Basically... what's the point in keeping the proprietary driver around instead of phasing it out and improving the open-source driver?

I am almost certain, that if AMD ever will switch to fully OpenSource, this will not be Mesa, but their own project.

1) Mesa hates per App Optimizations, what is a major reason why fglrx is faster.
2) AMD still need full controll of the COde in sense they tell with features (not) go upstream.

[dungeon]

Uh... a shader cache doesn't help with the realtime performance, only shader compilation. This would be nice but there are other more important issues...

Threaded GL is also more or less a myth.

I just said what nvidia and Catalyst drivers *both* have those todays and mesa drivers lack it, so if you think performance from those driver features are not important for mesa drivers and you can get that perfromance somewhat differently then OK

EDIT: I'm no graphics driver developer. This is simply from behavior I've observed during my testing, perhaps ignoring details of the specification itself.

I am not driver dev too, also during my testing i found that Catalyst's MCCaps and GLCache made most of the difference in performance compared to radeonsi driver.

Yeah *performance* is all that together - higher frame rate, faster loading, less stutter, etc...

[humbug]

Good stuff from AMD. Hope that a significant part of the improvements are general openGL optimizations and not just application specific stuff.

[mmstick]

It's understandable that fglrx does have some benefits over the open-source driver... but isn't that just all the more reason to focus on the open-source driver instead?

From my general understanding, we have one driver that has pretty good performance in some situations, but you have another driver with more platform support, stability, and flexibility, but lacking in performance in the situations where the former driver excels. Why not bring the latter driver up-to-par performance-wise? Or is there other reasons where Catalyst/fglrx excels that isn't performance (and can't those same reasons also be improved on open-source)?

Basically... what's the point in keeping the proprietary driver around instead of phasing it out and improving the open-source driver?

It would make more sense to focus entirely on the open source drivers, but I would imagine that most of their developers are only experienced with programming Catalyst on Windows where no such open source drivers exist and for which any OpenGL improvements they make in Catalyst on Windows will also improve performance on Linux.

Now that they are moving to AMDGPU they can more or less let their small open source team handle the Linux DDX/DRM driver side while they just focus on Catalyst GL/D3D and not have to worry about their old broken Linux/Xorg drivers.

Many of the models in the 300 series still aren't supported by AMDGPU so these owners are pretty much better off with the open source drivers. Tonga and Fury, on the other hand, will get all the benefits of AMDGPU with Catalyst as well as open source drivers. The open source drivers already match Catalyst in a lot of areas -- just missing support for threaded GL that Catalyst uses in games supported by 'profiles'.

[mmstick]

Uh... a shader cache doesn't help with the realtime performance, only shader compilation. This would be nice but there are other more important issues... it would also be nice if OpenGL would accept Spir-V as an extension which would immediately remove a lot of the syntactical parsing required at runtime.

Threaded GL is also more or less a myth. For one, OpenGL already does certain operations asynchronously, such as rendering itself. You draw, it immediately returns, and hopefully the operation is done by the time you flip buffers (otherwise it must wait until it is). The point of GL_THREADED_OPTIMIZATIONS with nvidia is to off-load certain CPU-based operations (such as glDrawPixels I think) which should be avoided in the first place, especially since most drivers don't support such a thing.

EDIT: I'm no graphics driver developer. This is simply from behavior I've observed during my testing, perhaps ignoring details of the specification itself.

All of the performance gains that Catalyst has over the open source drivers is essentially threaded OpenGL. You will notice that games that Catalyst has profiles for have a significant increase in performance over the open source drivers precisely because they are enabling multithreaded OpenGL. NVIDIA isn't the only one with threaded GL now.

[dungeon]

Good stuff from AMD. Hope that a significant part of the improvements are general openGL optimizations and not just application specific stuff.

General stuff isn't advertised, so when some game titles have performance advertised that likely means profiles are done for those

I can only agree rendering distance perf is screwed most of the time on Catalyst especially when someone develop on nvidia hardware , they might do there something more generic in that case and everybody should be happy with perf. Is it cliping, culling or whatever limitation hits there... he, he, something there even unrelated to just threading optimization taking place and seems to me some kind of CPU cap related again, BOs, IBs limit, occlude, draw calls, primitives... well everything can be Give me source code of Catalyst AMD i will found it

He, he, 2m10s or 7m40s distance in this video seems like worse case... more then 3 times slower then DX

But port is bad really anyway, as AMD on Windows actually beats that nVidia on Linux - that is most obvous bad port