AMD GPUOpen: Doubling Down On Open-Source Development

Status
Not open for further replies.
I can understand why AMD is going more towards an open software agenda. It is hard to work with big companies and develop your own proprietary software with low R&D budgets.

I am all for it but I do think in the end they are expecting companies to actually pick up and do this more on their own instead of nVidia who tends to work with the companies.

One downside I see is the more access you give companies to your GPU itself, the more issues that are bound to come up. Yes you can get more performance but there is a reason why most everything in Windows runs through the API layer first, it prevents the hardware from crashing and taking Windows with it like it used to back in the Windows 9x days.

Maybe this will work out for the best, maybe it wont. Only time will tell.
 
Ill believe the Linux support when I see it. People seem to have good luck with AMD Linux support but I dont. I have yet to have an install go well when using the official drivers.

 
This article is just one more example of why people need to stand behind AMD, we need their competition in the marketplace.
A monopoly by INTEL or NVIDIA is something that is good for no one expect INTEL or NVIDIA.
 
Ill believe the Linux support when I see it. People seem to have good luck with AMD Linux support but I dont. I have yet to have an install go well when using the official drivers.
Same here, but I hear that the unofficial drivers are better, I haven't gotten a chance to try them yet.
 
More likely open source because they can't seem to write good drivers lately ! No I am not an AMD hater either, they just have the stupidest bugs that shouldn't make it past QA, like the MS Surface 4 does !
 
More likely open source because they can't seem to write good drivers lately ! No I am not an AMD hater either, they just have the stupidest bugs that shouldn't make it past QA, like the MS Surface 4 does !

Both companies Nvidia and AMD have had very bad drivers from time to time... So that is not a reason to open source push this time.
I think that pure reason is that Freesync aka adaptive sync can win because AMD and Intel both support it and so can every other company if they want to.
OpenGPU can win, if AMD, Intel and all other GPU maker support it. The AMD is in so tight spot that it can not make big closed system, without being cornered in very tight spot.
 
I can understand why AMD is going more towards an open software agenda. It is hard to work with big companies and develop your own proprietary software with low R&D budgets.

I am all for it but I do think in the end they are expecting companies to actually pick up and do this more on their own instead of nVidia who tends to work with the companies.

One downside I see is the more access you give companies to your GPU itself, the more issues that are bound to come up. Yes you can get more performance but there is a reason why most everything in Windows runs through the API layer first, it prevents the hardware from crashing and taking Windows with it like it used to back in the Windows 9x days.

Maybe this will work out for the best, maybe it wont. Only time will tell.

This was also one of the things that separated good companies from bad ones (in gaming that is).
9x Win crashes were very common but there were companies that had constantly stable products, and those products could be quite amazing.

I dont like the idea of limiting the devs throu a barrier because it creates a lazy midset for companies (kinda like fifa from EA).

Today we have a lot of games going throu Win API and still being unplayable anyway, so why not reward those companies that want to do things well?
 
I can understand why AMD is going more towards an open software agenda. It is hard to work with big companies and develop your own proprietary software with low R&D budgets.

I am all for it but I do think in the end they are expecting companies to actually pick up and do this more on their own instead of nVidia who tends to work with the companies.

One downside I see is the more access you give companies to your GPU itself, the more issues that are bound to come up. Yes you can get more performance but there is a reason why most everything in Windows runs through the API layer first, it prevents the hardware from crashing and taking Windows with it like it used to back in the Windows 9x days.

Maybe this will work out for the best, maybe it wont. Only time will tell.
Modern OSs isolate the display driver in such a way that it is extremely rare for it to affect system stability, mostly your screens just go black for a moment until the driver is reloaded (and failing that, a general display driver is loaded).

edit: it's why, when installing / updating your display driver you don't necessarily have to boot your system, and when you do have to, you only do it once... it was different back in the day...
 
I don't see a problem with this, today's games have to be released on such a tight schedule with a crazy amount of detail in their graphics which only adds to the workload as compared to a decade ago.

The only real solution for many companies is to use a pre-made graphics engine which has taken much of the work out of the graphics side, and allows you to focus on the actual game and content.

So having full access to the video card is a great idea as these graphics engines may be able to squeeze out a few more fps compared to your competition on the same 3-4 graphics engines on the market which most games are based on.
 


That is the graphical API, be it DirectX, OpenGL (now Vulcan) or Mantle. It is the barrier between the graphical layer and the kernal which keeps your OS going while the driver crashes, unless it is in a state of constant crashing then it will eventually cause the kernal to panic. It is why since XP we have bee able to have devices fail/crash and normally not crash the entire system.

It has its ups and downs, normally you are sacrificing performance for stability. Mantle and DX12/Vulcan allow more access to the hardware but it all still goes through a API, it is not like when they used to write directly to the hardware itself.
 


That is the graphical API, be it DirectX, OpenGL (now Vulcan) or Mantle. It is the barrier between the graphical layer and the kernal which keeps your OS going while the driver crashes, unless it is in a state of constant crashing then it will eventually cause the kernal to panic. It is why since XP we have bee able to have devices fail/crash and normally not crash the entire system.

It has its ups and downs, normally you are sacrificing performance for stability. Mantle and DX12/Vulcan allow more access to the hardware but it all still goes through a API, it is not like when they used to write directly to the hardware itself.
That is only half true, stability is not exactly easy to get even if you use those APIs. The general idea is that you have to only write 1 code for all hardware. This means that you have to write a lot more code that has to tackle multiple hardware configs which can lead to more possible bugs and compatibility problems. The devs also have to write a lot more code for QA and implement a lot more failsafes.
But at the end of the day this can make an unplayable game play at over 60fps.
 


By stability I meant on the end of the driver. When writing directly to hardware a crash will normally take the kernal along with it which causes Windows to crash.

And of course it makes for better performance but at the cost, as I said, of possible stability and as you mentioned more bugs and things to write for.
 
AMD is taking a lot of high investment, high risk moves that are not just going to help themselves, but the industry as a whole. They are showing accelerated development practices for the first time in a long time and it makes me excited to see what the future holds for them.It is good to know that they have become bored of their stagnant state as well.
 


I highly doubt it. Imagine if for each game you had to install a different drive to get the best performance. That would be a nightmare.
 
Let's be honest here, this is great and all but it won't get Nvidia to budge. Nvidia will continue using GameWorks to further it's monopoly and there's really nothing AMD can do about that. Even if AMD does come out with a card better than Pascal, GameWorks will cripple that advantage. It a double win for Nvidia as well, with GameWorks they can cripple AMD cards and last gen Nvidia cards. Not only do you get people coming from AMD but you force Nvidia users sitting on older cards to upgrade. I'm sure Maxwell is missing Async compute for a reason to do with sales.
 


Imagine, hell I lived it when they were ATI they had separate drivers for all the major programs and for the different versions it was a nightmare that is how ATI started the slide to bankruptcy where AMD bought them. And back then the internet was still new so the techs would mail you the drivers so you had to wait a week for them. I still have nightmares about those times.

It just seems history tends to repeat itself. Why wouldn't a game studio write drivers to make its games run better they wouldn't care about the competition's problems after all.
 
If AMD is serious then they need to go private. I wouldn't buy their stock if forced at gun point.
Unless,
3rd party support is heavily available and credentials are provided.as to who they are.
AMD provides information as to how they will be profitable.
 
On Linux the open source AMD driver is already at ~85-90% the catalyst driver so with a little push from AMD it could easily catch up with and then surpass Catalyst performance.

Though the open source drivers are still only at about OpenGL 4.1 compliance with most of the other extensions from 4.2-4.5 finished but missing a few.

And Vulkan will strip away a lot of control and responsibility from AMD for making drivers and place the burden on graphic engine developers (who are mostly happy to do the work) or individual game developers that develop their own engine (not so keen on the idea).
 
THIS IS WHAT WE NEED!! AMD already has its GPUs inside the Playstation and XBox and some of the PC market. This would have the potential to open it all up and truly have cross-platform support for everything. CUDA code conversion is great as well as that'll mean CUDA only applications won't be restricted to Nvidia. This is the card that AMD needs to take the lead.
 
Simply put, this support of open standards and development while as mentioned above will open expose a lot more problems it will most certainly open a lot more options and sponsor a lot more development. AMD needs this, they want it badly and if they keep up as they have been they will get it.

How many of the last few consoles used AMD gpu`s.... The last two xbox's, the last 3 Nintendo machines along with the current offering from Sony. As a hardware company leaving the software side to others is a fantastic idea, This makes you more marketable and more widely supported. Good work AMD.
 
Simply put, this support of open standards and development while as mentioned above will open expose a lot more problems it will most certainly open a lot more options and sponsor a lot more development. AMD needs this, they want it badly and if they keep up as they have been they will get it.

How many of the last few consoles used AMD gpu`s.... The last two xbox's, the last 3 Nintendo machines along with the current offering from Sony. As a hardware company leaving the software side to others is a fantastic idea, This makes you more marketable and more widely supported. Good work AMD.
I'd argue against that.

As a software developer, if your hardware doesn't with documentation, examples, and support, I don't really want to deal with it unless this is what my bosses wanted and this was the way forward. Imagine getting a microcontroller from STM or Atmel with zero to poor documentation, no examples, and not even a basic library get even basic peripheral functions to work.

This is the reason why GameWorks is popular, it let's the develoepr focus on the development of the application rather than try to fight with the hardware to get it to work.
 
Status
Not open for further replies.