Radeon™ GPU Analyzer 2.3 for Direct3D® 12 Graphics
Earlier this year, RGA 2.2 shipped with a new mode of the command line tool that added support for Direct3D® 12 compute pipelines. RGA 2.3 …
It’s Time to Open up the GPU
I have met enough game developers in my professional life to know that these guys are among the smartest people on the planet. Those particular individuals will go to extreme lengths to extract the last bit of performance or functionality from a computer system. Graphics engineers in particular are on a quest to bend the hardware to their will. Their passion, smarts and dedication has enabled successive waves of real-time graphics technology breakthroughs in console and PC game titles. To achieve these results, developers need to gain information about the hardware, use specific tools to analyze it and write efficient code to control it. More often than not, innovative results are only possible via the exchange of knowledge that happens within the game development community. While whole conferences are dedicated to this information sharing, it is often in more modest settings that inspiration takes form. Dinner conversations, plan files, developer forums or chats are common catalysts to graphics greatness.
Yet there are hurdles getting in the way of productivity and innovation. It can be difficult for developers to leverage their R&D investment on both consoles and PC because of the disparity between the two platforms. Console games often tap into low-level GPU features that may not be exposed on PC at the same level of functionality, causing different — and usually less efficient — code paths to be implemented on PC instead. Worse, proprietary libraries or tools chains with “black box” APIs prevent developers from accessing the code for maintenance, porting or optimizations purposes. Game development on PC needs to scale to multiple quality levels, including vastly different screen resolutions. Triple monitor setups, 4K support or dual renders for VR rendering require vast amounts of GPU processing power yet brute force rendering only gets you so far. There is still a vast amount of graphics performance still untapped, and it’s time to explore smarter ways to intelligently render those increasing numbers of pixels. “Opening up” the GPU is how we solve this.
GPUOpen marks the beginning of a new philosophy at AMD. It is the continuation of the initiative we started with Mantle where we embarked upon a journey to give game developers more efficient ways to drive the GPU. A couple of years later and the game development world is now rejoicing in the advent of standard and explicit graphics APIs such as Microsoft’s DirectX® 12 and Khronos’ Vulkan™. Now is time to do even more for developers.
Today is the day we launch GPUOpen.
GPUOpen is composed of two areas: Games & CGI for game graphics and content creation (which is the area I am involved with), and Professional Compute for high-performance GPU computing in professional applications.
GPUOpen is based on three principles:
The first is to provide code and documentation allowing PC developers to exert more control on the GPU. Current and upcoming GCN architectures (such as Polaris) include many features not exposed today in PC graphics APIs, and GPUOpen aims to empower developers with ways to leverage some of those features. In addition to generating quality or performance advantages such access will also enable easier porting from current-generation consoles (XBox One™ and PlayStation 4) to the PC platform.
The second is a commitment to open source software. The game and graphics development community is an active hub of enthusiastic individuals who believe in the value of sharing knowledge. Full and flexible access to the source of tools, libraries and effects is a key pillar of the GPUOpen philosophy. Only through open source access are developers able to modify, optimize, fix, port and learn from software. The goal? Encouraging innovation and the development of amazing graphics techniques and optimizations in PC games.
The third is a collaborative engagement with the developer community. GPUOpen software is hosted on public source code repositories such as GitHub as a way to enable sharing and collaboration. Engineers from different functions will also regularly write blog posts about various GPU-related topics, game technologies or industry news.
By Developers, For Developers
A critical design goal was to have GPUOpen created by developers, for developers, keeping marketing elements to a minimum. The creation of the Radeon Technology Group led by Raja Koduri was key in turning GPUOpen into a reality and I am very excited that this project is now being launched.
Today is the birth of GPUOpen and like any newborn it has some growing to do. As we add new content over the next few months we will be listening to developers feedback and respond as needed.
It’s time to open up the GPU.
Nicolas Thibieroz is the Director of Worldwide Game Engineering at AMD. Over the years, he and his team have helped countless numbers of PC game developers tame the GPU to make faster and better-looking games. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied.
So I’m poking around GPUOpen.
VERY VERY nice. There’s lot’s of stuff, lots of eye candy, very pretty, well implemented. The nav is a bit unusual, but within a minute I’m pretty comfortable with moving around the content.
Here’s my biggest “WOW”. Every single thing I’ve looked at, in both Games and Compute, has a link to Github.
THAT
IS
AWESOME
Great to hear! Can this mean better GFX drivers for Linux? Awesome!!! 😀
Quite likely. With proper documentation it will be much easier for open source driver developers to make a quality FOSS driver. I can even imagine voluntary devs joining forces with AMD devs to create a good FOSS driver. I’d love that.
Congrats and good luck with GPUOpen. Try to get the community behind you, there are plenty of folks unhappy or even pissed with the blue and green competition. Turning that to your advantage by supporting and helping people to help your cause (but not by trying to discredit others, please) should help in gathering momentum. And please, don’t forget that at this time you need developers behind you, users will only follow afterwards, so do support and enable developers first and foremost.
It’s a great development, but a lot of libraries in GPUOpen are Windows only at present, because they rely on DX11 and etc. Are there any plans to port them to Vulkan to enable using them on Linux and other platforms outside MS ones?
Vulkan is an efficient “explicit” graphics API and AMD is very excited about the potential it provides to get closer access to the GPU on different platforms. This API is an important part of our future plans.
I’m talking about things like GeometryFX, TressFX and such (which are part of GPUOpen). Right now they don’t use Vulkan for their 3D and compute features. They rely on DX11 / DirectCompute, which makes it impossible to use them on Linux or any other system outside MS ones.
What I’m asking is, if there is some (short / long term) plan to switch them from using MS proprietary APIs to cross platform and open APIs like Vulkan? That would make GPUOpen really open in all senses of the word.
Are those APIs *necessary* in Vulkan? I’m not familiar with Vulkan’s public API, but that’s the first question I’d answer before pursuing this. It may be the case that the functionality you’re looking for is already surfaced in Vulkan, which would make these APIs redundant.
Those APIs are high level libraries for managing physics and other effects. Vulkan on the other hand is a low level API to access 3D and compute functionality of the GPU. I.e. they aren’t comparable. High level APIs are using the lower level ones. You don’t need to use something like GeometryFX, but if you need physics you’ll need to implement all that on your own in such case (or find an alternative like Bullet and etc.). Vulkan can be compared to OpenGL and OpenCL, not to high level stuff like TressFX and GeometryFX.
Heh.. Just because they currently rely on DX11, doesn’t mean that they’re undoable- you’ll need to re-work them for OpenGL or Vulkan anyhow… Since they’re here (or, rather on GitHub under the GPUOpen banner…), it’s only a matter of someone being willing to DO that re-work…
That was my point exactly. I was asking if such plans already exist, or not.
That’s awesome ! Thanks AMD for choosing altruism and free software 🙂
Please could you port your direct x 11/12 features to Vulkan when it will be released ?
And please accelerate the openCL development of Bullet the physics engine, this will give to AMD a better alternative than physx.
That’s a priority.
And another feature request, could you optimise this for GCN ? https://github.com/glennw/webrender
This is the gpu part of servo, which is the layout engine of the future pushed by mozilla and Samsung. In end 2016, all browser will use it and if thanks to this optimisations AMD had better perf in browning than nvidia, this could be a game changer for AMD 😉
Wow, good job on the new site AMD. Pretty good looking if you ask me…
So, is the source code for AtomBIOS being released then? Under Linux currently all AMD GPUs rely on binary blobs between the OSS driver and the hardware. It would be excellent to have a fully open source stack if you are now advertising a “commitment to open source”.
good job AMD.
i am amazed at your atitude. Will Benefith AMD in the long run… Nvidias aproach is allways proprietary stuff ( seems like apple but with graphics cards) Best of luck… i still use my amd 280x to my gamming needs and never disapoint 🙂 my oldie reliable hd5770 its now in a production pc and not on my home 🙂
What library are you using for scrolling on the mobile webpage? It’s very smooth.
Is there any way to use AMD GCN instruction set directly in OpenGL or DirectX shaders?.
Can I implement this in Unity games?
Yes. The MIT license is a permissive open source license.
Very beautiful site, but can you add the possibility to edit comments ?
Also this would be great if the website was opensourced, people should report bugs and features (for exemple using piwik instead of Google analytics)
Love the idea and while I’m going to be digging through the repos soon.
One thing that I’ll mention here in addition to sending to Robert – releasing source is one thing, but for it to be a real open source ecosystem surely AMD has to consider that devs will also want to be able to submit suggestions for improvement, fixes, etc. Please consider something like Gerrit for this if not already in the works, it SURELY beats pull requests in Github.
“I have met enough game developers in my professional life to know that these guys are among the smartest people on the planet. ”
Uh huh. I have met some very, very mediocre games developers in my time. Maybe we go to different conferences.
Very nice!
So when are you open sourcing the GPU driver? Preferably for Linux.
E.g. https://wiki.gentoo.org/wiki/Amdgpu
I’m fairly hyped about this. Good things are coming folks, I just know it 🙂
Wait a second… TressFX 3.0 tells me that a “AMD Radeon™ GCN-based GPU (HD 7000 series or newer)” is a prerequisite. Does this mean it’s no longer cross-platform? Or is this just for authoring?
TressFX 3 is compatible with other GPUs too. This is listed in the requirements.
Any plans for Windows support on the GPUOpen Compute side? There are 5 tools listed and they are primarily for Linux:
– HIP (Linux Only)
– ContinuumAnalytics (Linux Only)
– HC Compiler (Linux Only)
– HSAILGDB (Linux Only)
– SystemHealthMonitor (Primarily Linux, little support for Window)
So if you’re opening up the GPU, will you be providing source code for the binary firmware files currently required by the free software drivers?
Pls… It’s already provided since many years, and with the entire doc and ISA.
Don’t confuse with the Nvidia jail
Finally, AMD realizes that opening up its hardware will improve its position in the market.
When decisions are made to disregard the open source community it harms businesses more than they realize. The typical argument from major hardware vendors is that the open source community represents only a small share of the home user market and can therefore be disregarded. Power users such as developers, security professionals, and administrators typically employ open source software. Disenfranchising the power users who are the gatekeepers to purchasing decisions of families, friends, and businesses really hurts hardware vendors. For example, many years ago when I couldn’t get an ATI gpu to work on my thinkpad running linux. There were a lot of hacks but it never worked right. I said you know what, I’m not buying products from theses guys because they blew me off when I needed support.
Since then I’ve probably owned a dozen computers in my home. I earned a bachelors degree in an IT discipline, I’m working on a masters, and I have several IT certifications. I now work in the IT sector. I make hardware purchasing decisions at work. Refusing to support me so I could get my GPU working has made me almost exclusively an intel buyer for about a decade.
Does that mean that I am loyal to intel? Absolutely not. In fact, it is my hope that AMD will evaluate their position in the market and decide to open up its firmware because doing so would make their hardware more useful. You will also benefit from harnessing the brain power of your end users. Intel has been implicated in the snowden releases as surreptitiously implanting malicious microcode in its CPUs. The security community is looking at migrating away from AMD-64 to ARM and POWER8, which is silly because the architecture is fine but the corporate policies of secrecy keeping the products black boxes is incompatible with people concerned with their privacy.
Have you ever thought about including a little bit more than just your articles?
I mean, what you say is important and all. Nevertheless think
about if you added some great pictures or videos
to give your posts more, “pop”! Your content is excellent but
with images and videos, this site could certainly be one of the most beneficial in its field.
Awesome blog!
we all know that the GPU is responsible for the computer graphics and handle the display and visualization of the system but form this article I get some wonderful information about the launch GPU open.