AMD Offers Mantle For OpenGL-Next, Pushes Mantle To Workstations

[Guest]

i can't undertand why ppl supports so much amd, i really can't, having a amd card in linux is the worst nightmare, but ok continue supporting them, better decision in my life:

last year sell all amd cpu and gpu ,buy intel and nvidia

Can't stand NVIDIA nor Intel personally. Not a fan of NVIDIA's proprietary bs (Tegra, PhysX, etc). And Intel is just shady (lack of better word; they release garbage graphics drivers for Windows; a driver group I'm with made the drivers better, and Intel threatened to sue).

AMD has done nothing wrong as far as I'm concerned. Drivers (in my experience) aren't nearly as bad as people claim.

[brosis]

AMDs open source drivers still require closed source microcode and firmware...If you want to be truly open you have to use an older NVIDIA card with nouveau.

Nouveau extracts microcode from closed driver, doesn't it?
Intel is microcode-free, but loads it at UEFI stage.

The only question is if we have microcode-free system(1) or microcode which is open(2), and:
1) its something from 199x
2) its not happening as requires opensource hardware, so many people have reasons of not buying

[blackout23]

Nouveau extracts microcode from closed driver, doesn't it?

No it doesn't. Nouveau provides it's own free Firmware for most cards. On some newer cards it might not be perfect. For these you can use an extracted firmware and start with nouveau.config=NvGrUseFW=1.

http://nouveau.freedesktop.org/wiki/InstallDRM/

NV04 - NV30: No firmware used.
NV40 - NV50: No firmware needed. The Nouveau driver generates the ctxprogs and related state internally (commits 48c6dfb8 and 266229a5).
NVC0: Free firmware provided by the driver, presumably working.
NVD0: Free firmware provided by the driver but imperfect (commit 902530693ef38f3bb007efae594e54443d84fa56)
NVE0: Free firmware provided by the driver, presumably working (commit eca15296a9c2a5d5d7d8281a710ba4bd0c2e7cd3) The proprietary firmware is not readily available, you need to extract it yourself (instructions)

[OneTimeShot]

AMDs open source drivers still require closed source microcode and firmware...If you want to be truly open you have to use an older NVIDIA card with nouveau.

Lolz... I like Open Source, but I'm not that crazy! Maybe one day we'll have completely open source hardware too, but until then I'm happy to consider firmware "an integral part of the hardware black-box that I bought". It's a shame though: when I was a kid I was really into electronics - no hope of that for the current generation.

Note that NVIDIA firmware is reverse-engineered - as you say NV don't allow their official firmware to be redistributed, which AMD do. Presumably someone could RE the AMD blob if they cared enough.

[Creak]

I've read a lot of posts saying that AMD cards just have poor performances and I find it pretty unfair.

I have a Radeon HD 6870, obviously with the free drivers, and I can run all my Steam games. I admit that most of them are indie games (Blocks that matter, Limbo, Bastion, Don't Starve, FTL, Super Meat Boy, ...), so they're not very GPU consuming. But I also have Metro: Last Night, Civ 5, Team Fortress which run pretty well on my old card. To be perfectly honnest, it's not as perfect as I could have on Windows, but heh, if that really was my priority, I'd be on Windows!

And about OpenGL 4 and OpenCL, although it's a nice to have, the vast majority of games uses OpenGL 3.3 extensions. Game developers don't use the cutting edge technologies, using them means limiting your market share and they really don't want that (trust me on this, I'm a game developer). And OpenCL is simply never used in games, it's used in professional apps. The only optimization technology we use in the CPU are the SIMD intrisics (MMX, SSE1, SSE2, SSE...). And again, we don't use the last ones because it will limit the market share (or simply not be supported by other platforms like PS4, Xbox One, Android, etc...).

To me, and this is highly subjective, being open source is way more important than performances. That's why I prefer AMD, because they're adopting a long term strategy (and also I have nothing to do to have my card fully detected out of the box).

Finally, I know the drivers aren't perfect, but the bright side of that is that each time I launch a game after an update of my system, I see real differences

[DrYak]

About the Nvidia vs. AMD debate, a few point which weren't brought back on this thread:

- AMD directly helps (paid developers, released code, released specs) for their whole range of GPU cards.
vs.
- Nvidia has promised to finally join the opensource band-wagon... but currently they only helps by releasing tiny bits (2D code and specs, nothing 3D) for their Terga line (The ARM embed line of GPUs). Only very recently did they give some bread-crumbs help on power management and reclocking.
So although on the long term, when Nvidia finally get their shit together they are going to be useful for Nouveau team and opensource drivers, currently, their impact is still completely insignificant. (But well, at least it's good to see their on the right track).


- AMD binary drivers might be less polished... but they actually work with Linux. They support more or less all the current APIs (including Randr. Also, e.g.: their Linux drivers also run on libDRM and use a DRI infrastructure, etc.).
In addition of that: the long term plan is that catalyst will morph into a proprietary 3D OpenGL/OpenCL libraries which runs above the same low-level (same kernel module, etc.) as the opensource drivers. You just exchange Mesa's Gallium3D's vs. Catalyst's OpenGL/CL/etc. Everything stays the same underneath.
vs.
- Nvidia binary drivers work... because they are basically just the Windows drivers recompiled under Linux. Meaning that they don't use all the official Linux. Instead they use their own way under Linux, which's great when it work, and you're screwed if it doesn't work under Linux. (e.g.: the long time it took them until they support Randr correctly. e.g.: the lon clusterfuck around DMA-BUF (though linux kernel dev aren't helping, but given the long backstory you can't really blame them), e.g.: broken "optimus" under Linux on most laptops (cf. Linus' "fuck you"), e.g.: it's 2014 and they still don't do Kernel-mode-switching, etc.)
So yeah, Nvidia hardware and drivers are great... If you're on a desktop PC. Otherwise, on a laptop, you're in for a world of pain, as you'll hit a ton of corner cases where thinks go shit because the driver doesn't collaborate nicely with the official Linux stack (e.g: suspend/resume problems, garbage on screen, very bad screen-plugging auto-detection, lots of hacking required to get Intel&Nvidia GPUs playing along, etc.)


- Nvidia help game developper by giving them embed Nvidia-developers working among the game-dev's team... but here again their are known to do things "the Nvidia way". Meaning that their drivers aren't that great (they don't necessarily follow the standards as closely as they should), and that the "great performance code" that they help writing is similarily quircky and not standard compliant. Part of the reason that games work better on Nvidia hardware/driver is also because the game code is half broken and does unusual stuff that the Nvidia driver happen to tolerate because it doesn't follow standard itself.
vs.
- AMD developers and engineers have a reputation of knowing their OpenGL standard to the perfection.


And about Mantle/OpenGL-Next going Linux:
- at least they are supposed to be very light-weight APIs that don't stand in the way between the hardware and the game developer. And on Linux, Mesa's Gallium3D's infrastructure make it easy to add new state trackers for new API. In addition to that, Gallium3D exposes very nicely the low-level components of graphic cards. Meaning that if OpenGL-Next and Mantle are as low-level and close to metal as announced, it shouldn't be that much difficult to develop a tracker for them. As a reference, see the (now defunct) Direct3D 10/11 Gallium3D state tracker (or to a lesser extent the currently talked about new DirectX 9) developped to help Wine. As Direct3D is supposed to be at lower level and less complex than OpenGL, they were put together much faster than Mesa's GL tracker. I would expect similar speedier development. (Specially since the Intel/AMD/Fedora/Suse/Steam/etc. opensource developer working with them will not need to catch up with 10 years worth of old-api legacy).

[Commander]

About the Nvidia vs. AMD debate, a few point which weren't brought back on this thread:

- AMD directly helps (paid developers, released code, released specs) for their whole range of GPU cards.
vs.
- Nvidia has promised to finally join the opensource band-wagon... but currently they only helps by releasing tiny bits (2D code and specs, nothing 3D) for their Terga line (The ARM embed line of GPUs). Only very recently did they give some bread-crumbs help on power management and reclocking.
So although on the long term, when Nvidia finally get their shit together they are going to be useful for Nouveau team and opensource drivers, currently, their impact is still completely insignificant. (But well, at least it's good to see their on the right track).


- AMD binary drivers might be less polished... but they actually work with Linux. They support more or less all the current APIs (including Randr. Also, e.g.: their Linux drivers also run on libDRM and use a DRI infrastructure, etc.).
In addition of that: the long term plan is that catalyst will morph into a proprietary 3D OpenGL/OpenCL libraries which runs above the same low-level (same kernel module, etc.) as the opensource drivers. You just exchange Mesa's Gallium3D's vs. Catalyst's OpenGL/CL/etc. Everything stays the same underneath.
vs.
- Nvidia binary drivers work... because they are basically just the Windows drivers recompiled under Linux. Meaning that they don't use all the official Linux. Instead they use their own way under Linux, which's great when it work, and you're screwed if it doesn't work under Linux. (e.g.: the long time it took them until they support Randr correctly. e.g.: the lon clusterfuck around DMA-BUF (though linux kernel dev aren't helping, but given the long backstory you can't really blame them), e.g.: broken "optimus" under Linux on most laptops (cf. Linus' "fuck you"), e.g.: it's 2014 and they still don't do Kernel-mode-switching, etc.)
So yeah, Nvidia hardware and drivers are great... If you're on a desktop PC. Otherwise, on a laptop, you're in for a world of pain, as you'll hit a ton of corner cases where thinks go shit because the driver doesn't collaborate nicely with the official Linux stack (e.g: suspend/resume problems, garbage on screen, very bad screen-plugging auto-detection, lots of hacking required to get Intel&Nvidia GPUs playing along, etc.)


- Nvidia help game developper by giving them embed Nvidia-developers working among the game-dev's team... but here again their are known to do things "the Nvidia way". Meaning that their drivers aren't that great (they don't necessarily follow the standards as closely as they should), and that the "great performance code" that they help writing is similarily quircky and not standard compliant. Part of the reason that games work better on Nvidia hardware/driver is also because the game code is half broken and does unusual stuff that the Nvidia driver happen to tolerate because it doesn't follow standard itself.
vs.
- AMD developers and engineers have a reputation of knowing their OpenGL standard to the perfection.


And about Mantle/OpenGL-Next going Linux:
- at least they are supposed to be very light-weight APIs that don't stand in the way between the hardware and the game developer. And on Linux, Mesa's Gallium3D's infrastructure make it easy to add new state trackers for new API. In addition to that, Gallium3D exposes very nicely the low-level components of graphic cards. Meaning that if OpenGL-Next and Mantle are as low-level and close to metal as announced, it shouldn't be that much difficult to develop a tracker for them. As a reference, see the (now defunct) Direct3D 10/11 Gallium3D state tracker (or to a lesser extent the currently talked about new DirectX 9) developped to help Wine. As Direct3D is supposed to be at lower level and less complex than OpenGL, they were put together much faster than Mesa's GL tracker. I would expect similar speedier development. (Specially since the Intel/AMD/Fedora/Suse/Steam/etc. opensource developer working with them will not need to catch up with 10 years worth of old-api legacy).

Does AMD support KMS with their blob?
Also Catalyst utterly crap in linux if you ever tried to do something that uses the card. Trying to contact the AMD devs take's ages and even then they wont support it to the fullest because linux desktop is not their market. Xorg infinite loops each day because of the driver crashing when trying to use it or hell performance that is worse then a cheaper nVidia card. (Had 6970 that performed about 50% worse than GTX260+)
AMD did also managed to destroy compatibility with my adapter that I used to have my 3 monitor setup. Contacted support and they said it was not on their "supported list" even though it was the same identical device just re-branded.

Hell i have Wine profiling bugs that limits functionality when Catalyst finds out Wine is running. Multimonitor issues where mouse gets corrupted, heard it on Windows? yeah its still here on Linux. (3+ years or so now)

If i got an issue with nVidia just post it on their devtalk linux forum or even the nVidia IRC on freenode and get a direct answer or debug the issue with the devs.

Opensource all way but comparing Catalyst to a functional driver is still a long way.

[ownagefool]

Y'know what amazes me? How everywhere you go, people think it's actually possible for one brand to be better than the other. At the moment, nvidia has a better experience as a whole.

Part of the problem is people who state this as a fact. Indeed, if you game on linux and want absolute max performance over everything else, you'll be better served with the blob and probably better served with nvidia. However, if you want a desktop that just works, you probably want Intel. If want want the best performance you can get with the least hassle, you want to cherry pick an AMD.

[droidhacker]

I'm actually quite amazed that anyone can say anything good about nvidia. Every time I touch their hardware, its a nightmare. Recently, had to deal with a laptop with an nvidia -- installed Fedora on it, display working (nouveau), but performance stank. So installed the blob, blacklisted all the modules that they say you have to blacklist, regenerated the initrd, rebooted, and..... black screen. Tried a few other things, and it ended up that their blob just doesn't bloody work. Back to nouveau and its high temperatures and extreme slowness. Better to show something than nothing, and it really wasn't worth it to waste a lot of my life trying to make that junk work. AMD means that the thing actually *works*, performance is plenty fine, temperatures are nice and low. No screwing around with crap that doesn't work.

[log0]

I'm actually quite amazed that anyone can say anything good about nvidia. Every time I touch their hardware, its a nightmare. Recently, had to deal with a laptop with an nvidia -- installed Fedora on it, display working (nouveau), but performance stank. So installed the blob, blacklisted all the modules that they say you have to blacklist, regenerated the initrd, rebooted, and..... black screen. Tried a few other things, and it ended up that their blob just doesn't bloody work. Back to nouveau and its high temperatures and extreme slowness. Better to show something than nothing, and it really wasn't worth it to waste a lot of my life trying to make that junk work. AMD means that the thing actually *works*, performance is plenty fine, temperatures are nice and low. No screwing around with crap that doesn't work.

You will always find people who have/had issues with this or that hardware I think. I've had nVidia and AMD hw, and no issues whatsoever with both.

But then, I am having a Windows partition for commercial apps/games and Linux for FOSS, running open source drivers for quite some time (Intel/AMD). Why make your life harder than it is.