To the AMD people: Money wasted.

[crazycheese]

All Nvidia does is sit back and reap the benefits yet nothing but praise for them and their just works driver!

I guess they do that. They claimed that their "attached" gfx stack is much more advanced than current linux one, so they did put a lot of effort there. Its just that effort is theirs and no one else, although they do demand money from everyone to build it. One of the reasons I use 4770 with lacking r600g. I'm touching points what will make it less lacking and this faster in this thread, nothing else.

For AMD, if you would have a demanding 3D game(both available for Linux or Windows), you would need to install a proprietary driver(which is lacking compared to nvidia). Or buy and install Windows, buy/get(if free) Windows version and "proudly" dualboot. Wine cuts that path a lot(in half, only windows version needed, not windows). Good working AMD native 3D driver would cut that part even more. Good working AMD opensource 3D driver would completely remove any issues.

[barkas]

Sorry, I read your #1 as "dropping fglrx". If you meant pursuing a two-driver approach for #1 then I agree in principle.

The problem is that "consumer" covers a very wide range of usage scenarios, and some of those scenarios value workstation-like attributes more highly than the things a typical consumer or enterprise client user would value.

Our approach is to support both driver paths and work towards having enough overlap in capabilities that we don't have a "hole in the middle". Consumer and enterprise client users will tend towards the open driver, workstation and gaming users will tend towards the Catalyst driver, but I don't think saying *this* driver is for consumer, *that* driver is for workstation covers all the scenarios sufficiently.

Note that comments about "only N open source developers" are missing the whole point of open source drivers -- that progress is *not* limited to what AMD developers can do. The open source driver dev community is a lot larger than just our people.

In my experience your approach is to do both drivers in an equally half-assed way.
I'm a bit frustrated by that because the ATI hardware is great, but the software has been less than perfect practically forever.
I have to admit that the windows driver is quite good by now, but linux isn't that great, possibly because the driver team is tiny.

Most companies have had to learn that it's not as easy as open-sourcing it and the driver will be written by someone. Usually the company itself has to do the bigger share of development.

[crazycheese]

amd does also have agreement with blizzard and crossover to bring the blizzard games on linux with wine on amd hardware.
you really can play every blizzard game in wine with amd hardware.

....

"I just don't think that it's AMD's responsibility to be fixing wine"

they do because they pay crossover for this.

So, thats coming true.
Instead of porting games to platforms or writing them in cross-platform style, the developers are using wine(windows) as interface on other systems.

More than that, AMD is paying wine developement instead of opensource or even fglrx development for native driver.

That makes my day.

[Wyatt]

Gee, first that time traveler from last century came to herald the death of PC gaming (), and now we have people that apparently slid out of an alternate reality where everything is black and white and VESA does 3D. Kansas, this is not. :P

[pingufunkybeat]

Why do you shift 3D to DirectX or Windows(directly or indirectly via Wine)?

Because these are Windows programs, written for a completely different operating system, and running them under Linux will never be anything more than a collection of clever hacks.

3d applications written for Linux have always worked for Linux. Your problem is not 3d, or the lack of it, it is the fact that you're running programs that you're not supposed to run on Linux, and people who wrote these programs will tell you not to run them under Linux.

Working native 3D stack is one problem less between Steam and Linux or Newgrounds-like community for 3D games and Linux.

There is a working native 3d stack, and it works with most native games.

The actual problem is that companies do not write Linux games. And this is not AMD's fault. Your problem is not the 3d stack, but the fact that games for Linux pretty much do not exist. It would be nice if WINE hacks worked better, but I'm not holding it against them. Native 3d works fine (though there is room for improvement, for sure).

[crazycheese]

Because these are Windows programs, written for a completely different operating system, and running them under Linux will never be anything more than a collection of clever hacks.

How, apart from drawing starting window, getting input and loading libraries are they different? Heck, you can replace the Direct3D binding via OpenGL simply by using different backends in the engine. And if its all plane procedural mixed code, it barely can grow past the size where appying "hacks" is too time consuming.

The actual problem is that companies do not write Linux games. And this is not AMD's fault.

Simply as that?
Or because the only possible functional 3D hardware in linux, which works without hacks is from nvidia? Get the amount of normal Joes interested in linux(mostly for wasting whole less money and saving world from stupid perverse monopoly). Minus normal Joes that do not own AMD cards. Minus normal Joes that are happy with Wine. What is left is probably only me. True?

[crazycheese]

come one your statement is just worst at all.

wine is an opensource project and wine is useing openGL.

what is wrong by supporting opensource and openGL ? ? ?

if amd does not support wine/opensource/openGL then its bad if they do support it is also bad..

you are just a joke if you are really serious about this statement.

Mono is also opensource project...

Wine should get out of the freaking way, if they are here for linux, and not only for money.

Wine should provide a compability layer if this compability is needed.
Wine should NOT pose itself as the true solution to linux 3D.
Watch what winelib is and put wine on same side as mono.
Have notepad start in linux, have mscorefonts required to be installed, have windows kernel replacing linux - gnu/windows that is. Ahahaha.

[mirv]

How, apart from drawing starting window, getting input and loading libraries are they different? Heck, you can replace the Direct3D binding via OpenGL simply by using different backends in the engine. And if its all plane procedural mixed code, it barely can grow past the size where appying "hacks" is too time consuming.

It's not quite that simple you know.

Simply as that?
Or because the only possible functional 3D hardware in linux, which works without hacks is from nvidia? Get the amount of normal Joes interested in linux(mostly for wasting whole less money and saving world from stupid perverse monopoly). Minus normal Joes that do not own AMD cards. Minus normal Joes that are happy with Wine. What is left is probably only me. True?

Nothing has stopped Id from making games. Almost all their games work without hacks with AMD for me - I have only one minor issue (doesn't prevent any gameplay) with quake4, but I can't test it on nvidia hardware, so don't know if it's AMD specific.

[pingufunkybeat]

How, apart from drawing starting window, getting input and loading libraries are they different?

Well, the libraries are all different, which is why WINE has to implement all of the (undocumented) Windows API and map them through native Linux libraries. Except the x86 instruction set, EVERYTHING is different.

Yes, well-designed games don't have a problem because platform-specific code is isolated. This doesn't mean that pretending that you are Windows, faking a C:\ drive and all the Windows configuration files and dlls is anything else but a hack.

Or because the only possible functional 3D hardware in linux, which works without hacks is from nvidia?

Weasel words. "functional" "without hacks", etc.

All manufacturers provide drivers for their cards, and they all work well for Linux software (including Linux games). Some of them open, some of them closed.

Your definition of "functional" is emulating another operating system.

[crazycheese]

Well, the libraries are all different, which is why WINE has to implement all of the (undocumented) Windows API and map them through native Linux libraries. Except the x86 instruction set, EVERYTHING is different.

Yes, well-designed games don't have a problem because platform-specific code is isolated. This doesn't mean that pretending that you are Windows, faking a C:\ drive and all the Windows configuration files and dlls is anything else but a hack.

If your words were true libsdl would be 4Gb in size. Gcc would be 100Gb in size.
The "hacks" with the lack of code is disasming the closed code and replacing the win32 calls with those close to posix/linux which will make execution slower. One more reason wine should not play a superman - it should stay as it is - a free winapi implementation. Just as mono is free .net implementation. Both with capability to drag your linux into gnu/windows.

With ability of source code, it is tracking down functions and specific platform code and replacing it with posix/linux code.

Sometimes significant amount of work is required in both cases, but your words are simply not true, unless you are trying to "port" a registry defragmentation program to linux. Then, true, you will have to introduce the registry to linux.

Weasel words. "functional" "without hacks", etc.

All manufacturers provide drivers for their cards, and they all work well for Linux software (including Linux games). Some of them open, some of them closed.

Your definition of "functional" is emulating another operating system.

Whats uncertain about my words, is #1 post also weasel words? No one simply registers and publishes an aggregated post with details just because his card does not work as expected.

My definition of functional is following:

Having an opensource operating system installed, inserting hardware and having recongnised and made usable using opensource driver, then going to linux gaming site, finding a game and having it automatically downloaded installed and playable. Everything within 5 minutes, everything for free (or payed account, but only in case there is SENSE for it to be payed, real work done for that money) and without any "compability layers".