If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Thank you, when I upgrade my vid card, I would prefer it to be an amd again.

We all know how much nvidia does to improve the open source drivers....
And although I do not use the open source drivers, for me as a Linux fan that does go a long way.

But currently judging from the steam forums, it would be an bad idea.

I am having fun with serious sam3, on Linux but I had to lower the resolution, on Linux.
( just to make clear, I am not whining over a few fps. )

That sort of brought me to a sudden realization - what if AMD didn't focus on both the open source and Catalyst drivers? By splitting up development teams for open source and closed source, that basically means half the attention for both products. Personally, I'd rather they focus all on one and not the other. I would prefer focus on the open source drivers just so they get a chance to catch up (and because they support more hardware and OGL-unrelated software), but I also prefer focus on the Catalyst drivers because those are a much shorter distance from operating head-to-head with Windows. I personally use the Catalyst drivers - aside from having to hold back my xserver version, I don't seem to get ANY problems with it. I think much of the complaining about Catalyst is from un-knowledgeable users or people who like to linger on past errors. This is a shame, considering Linux itself is suspect to those problems, so you'd think it's own users would realize this.

On the other hand, AMD could also just hire more devs, but we all know they can't afford that yet.

That sort of brought me to a sudden realization - what if AMD didn't focus on both the open source and Catalyst drivers? By splitting up development teams for open source and closed source, that basically means half the attention for both products. Personally, I'd rather they focus all on one and not the other. I would prefer focus on the open source drivers just so they get a chance to catch up (and because they support more hardware and OGL-unrelated software), but I also prefer focus on the Catalyst drivers because those are a much shorter distance from operating head-to-head with Windows. I personally use the Catalyst drivers - aside from having to hold back my xserver version, I don't seem to get ANY problems with it. I think much of the complaining about Catalyst is from un-knowledgeable users or people who like to linger on past errors. This is a shame, considering Linux itself is suspect to those problems, so you'd think it's own users would realize this.

On the other hand, AMD could also just hire more devs, but we all know they can't afford that yet.

The team working on the Linux side of Catalyst shares its code base with the Windows version. It is not like they spend a huge amount of resources on the Linux driver. Most things OpenGL related are shared between the supported operating systems. By spending a small amount of resources on the Linux Catalyst version they get the benefit thousands of hours spent into the Windows version.

The team working on the Linux side of Catalyst shares its code base with the Windows version.
It is not like they spend a huge amount of resources on the Linux driver. Most things OpenGL related are shared between the
supported operating systems. By spending a small amount of resources on the Linux Catalyst version they get the benefit
thousands of hours spent into the Windows version.

The ss3 opengl speed issues are NOT linux specific, they are crossplattform, you can change the renderer to opengl on windows too (not via the menu however). The decreased speed affects nvidia as well, the flickering textures are ati only however. They can be fixed when you press alt+enter twice as soon as you are in the menu and NOT in a level, when you do it in a level you can forget everything, then it is unplayable slow.

The ss3 opengl speed issues are NOT linux specific, they are crossplattform, you can change the renderer to opengl on windows too (not via the menu however). The decreased speed affects nvidia as well, the flickering textures are ati only however. They can be fixed when you press alt+enter twice as soon as you are in the menu and NOT in a level, when you do it in a level you can forget everything, then it is unplayable slow.

Are you replying to me?
Who said those OpenGL bugs are Linux specific?

Edit: My point was that the "apparently" little effort of Linux-specific code provide for most of the woes.
I don't think it's little effort. At least it doesn't look like.
Ok, it could be that only two guys hacking that X11-related stuff...

The ss3 opengl speed issues are NOT linux specific, they are crossplattform, you can change the renderer to opengl on windows too (not via the menu however). The decreased speed affects nvidia as well, the flickering textures are ati only however. They can be fixed when you press alt+enter twice as soon as you are in the menu and NOT in a level, when you do it in a level you can forget everything, then it is unplayable slow.

From the steam Linux forums, I know this to be true.

I have not tried it myself, but the opengl performance is on windows as bad as on Linux.
A few steam on Linux users have tested it.

I only compared opengl on Linux with Dx on windows.
As soon as more enemies show up, I do not really notice a difference on windows,
on Linux however I have a total cave in, of the fps.

Something about Croteam, I posted problems I had with ss3, on the steam forum for serious sam3.
I got a reply within 24 hours..... They tried to help, and I am on openSUSE.

Some companies care about their customers.
If amd does, then they are damn good in hiding it.

And what really makes me sad, Valve has published a few articles, they explained why games should run faster on Linux.
Not by much though just a few fps.

When we started with Linux, the initial version we got up and running was at 6 FPS. This is typical of an initial successful port to a new platform.
Performance improvements fall into several categories:

Modifying our game to work better with the kernel
Modifying our game to work better with OpenGL
Optimizing the graphics driver

OpenGL versus Direct3D on Windows 7

This experience lead to the question: why does an OpenGL version of our game run faster than Direct3D on Windows 7? It appears that itís not related to multitasking overhead. We have been doing some fairly close analysis and it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows. Now that we know the hardware is capable of more performance, we will go back and figure out how to mitigate this effect under Direct3D.

On the other hand, AMD could also just hire more devs, but we all know they can't afford that yet.

Isn't this way of thinking part of the problem? AMD now has a bad image for Linux gamers because they don't have enough driver developers to actually deliver a sufficient product. So not having enough developers furthers their money problems. They should hire developers to get a better product in the long run instead of saving money now with having to pay fewer developers, but lowering product quality.

You should know that intel+nvidia have got access to source engine code, if needed they could tell the devs how to increase speed that it works best with their drivers. I don't know if amd has got access and if they are willing to do the same.