nairolf

Silent GPUs FTW!

Mantle is a shit ton of extra work to bring down CPU usage. They are scrapping almost everything they had and built something new. Compare that to the few extensions it needs for OpenGL to improve the situation. Also the stuff they mentioned in the video are all replacements for code that already is in your game. You replace the code that was slow with new code that is fast. Screwing around with code until it works better is exactly what programmers do all day. Also, it's not just NVIDIA that writes these extensions: Sparse Textures (contributed by AMD, NVIDIA) Bindless Textures (contributed by AMD) UBOs (contributed by APPLE, NVIDIA) Shader Storage Buffer Object (contributed by NVIDIA, AMD) Persistent Mapping (contributed by NVIDIA) Multi Draw Indirect (contributed by AMD) (not all of them required, as they said in the video) They are working together to get something they all can support in their current and next gen hardware. Strangely this works for OpenGL but not for Mantle. You first have to invest time to port your game to Mantle and as Gordon Selley from AMD said in his Steam Dev Days talk: (@39:23) "Mantle is not necessarily for everybody. [...] All the safety that takes place in current drivers for GL and Windows is pretty much stripped away [...] It's not for everybody. It's fairly dangerous."

I re-read my last post and I think it sounded quite aggressive. I'm sorry for that. I've read so often that Mantle will be this and Mantle will be that without the people actually knowing what they are talking about. I never said DMA was the way for games to interact with the GPU. I said the extension (which is part of the driver) uses DMA. I also didn't say DMA is vendor agnostic. You wrote: "The only issue here is that these efficient OpenGL extensions would still have to go through the garbage code remnants of piles upon piles of legacy OpenGL code." I responded: "[...] What makes you think an extension needs to go through other legacy code? The extension is written by the hardware manufacturer, they can use DMA." Maybe we are talking about different things? Thanks for that video. I haven't seen this one. (Can't watch right now though.) But this is still not what a programmer needs to write code. I need an actual document that lists every entry point, every structure and callback function and describes in detail how to use them. Do you know of something like this for Mantle? Also example code would be very valuable. As far as I know nothing like that has surfaced yet.

Have you even once seen the code of a OpenGL driver? What makes you think an extension needs to go through other legacy code? The extension is written by the hardware manufacturer, they can use DMA. You sound like you've seen internal Mantle API specifications. How else would you know all that? Do you have a link to the API specs? By the way, Mantle contains legacy code. It uses the same shader language as DirectX! O_O Also the Mantle driver has to use the 14 years old Windows API! The first thing they should do is publish some API documentation, libraries, example code, anything that helps Mantle to get some market share. They have Nvidia and Microsoft against them so they need as much support from game developers as possible. Yet they just don't publish anything usable. Don't call it "open" when it's not open yet. We just have to believe the hype. I'm not against Mantle per se but I find it difficult to believe all that PR and marketing stuff without actual code and API specs to look at. Please AMD, do something!

#1 CryEngine also has an internal OpenGL port. I don't know about the others. #2 Mantle is not available to the general public. So there is no way to compare them at the moment.

They also said that if you use modern OpenGL you won't be bottle-necked by the API: https://twitter.com/grahamsellers/status/383242587609395201 The question is if Khronos (or a different org) wants to be responsible for Mantle. I mean why should they want to work on two competing open APIs at the same time? Also, AMD repeatedly compares Mantle to Direct3D, not OpenGL. Mantle is supposed to kill DirectX. For AMD's OpenGL drivers that is reasonable. For other companies probably not. That was an issue when OpenGL had a feature-driven release model. The committee delayed new API versions until there were enough new extensions that could get promoted into the standard. That lead to fragmentation because ATI/Nvidia/... didn't want to wait for years to get their new features in. So they did their own extensions so that developers could use them if they wanted. Nowadays OpenGL has a schedule-driven release model with two releases a year. So there is less reason to write their own extensions when they can get their stuff supported by an official OpenGL release in less then 6 months. More info The thing that are mentioned in the talk are not at all vendor specific. Also they have fallback solutions and don't need to be used together. That's answered in the Q&A part at the end. You mean the fixed function pipeline? That's gone for quite some time now. They keep removing old and slow stuff from the API since release 3.0 (where the change from feature-driven to schedule-driven happened). modern? OpenGL (it says so in the title of the talk) open? OpenGL suits the graphics hardware available today? OpenGL and in the future? OpenGL

John McDonald (NVIDIA) dedicates the last 15 minutes of the Steam Dev Days talk "Beyond Porting: How Modern OpenGL can Radically Reduce Driver Overhead" to address the "need more draw calls per second" problem. According to him this can be solved with modern OpenGL on current GPUs of the three major vendors. No need to use new APIs like Mantle for that. (He implicitly mentions Mantle in the beginning by saying "[More draw calls] is the motivation for an entirely new API. [...]") Video (should skip to 27:42 automatically) The talk is quite technical but I'll try to summarize it in this post... But first the results: 5-30x increase in number of distinct objects per second ~75% reduced interaction with driver (less CPU load/waste) GPU can be affected negatively (although not too badly) [Compared to the original OpenGL implementation and NOT to Direct3D. But as John said, OpenGL without these tricks is already better than Direct3D.] Summary of the video: PC developers are frustrated that console developers can get 5 to 20 times as many draw calls per second. Direct3D is slow if you need to draw many objects, naive OpenGL is faster but by using a few of the newer OpenGL extensions you can improve that drastically. They used API traces of a real-world application (Unreal Engine 4) and analyzed it to see how they can improve the code. OpenGL function calls cause "state changes" inside the GPU. Think of the GPU as a factory with lots of machines that are all connected together. Each of the machines can be configured to do something specific. Once everything is set up the factory will produce exactly that thing you specified it to produce. The configuration of all machines is called the factory's state. If you want to change what the factory produces you have to change its state. Different state changes have different costs because some machines are more difficult to reconfigure than others. The following diagram shows how the different state changes compare to each other in terms of execution time: Let's try to minimize the state changes as much as possible. The factory doesn't need to be reconfigured completely for each part that you produce. Many similar parts have almost the same production steps: Use Sparse Bindless Textures to eliminate texture changes between draw calls (Place all your needed materials close to the machine that needs them instead of in a warehouse. Prepare everything you need before starting production.) Pack many objects in an UBO, use persistent mappings, use ARB_shader_storage_buffer_object (Don't feed the machine parts individually. Give it a pile of stuff to work on.) Use ARB_multi_draw_indirect to pack multiple draw calls together (Don't produce one thing and then have a meeting with all your machine operators to tell them what to do next. Plan ahead what the next N products will be and give a detailed list to all of the operators.) Results of these optimizations: => With modern OpenGL you can choose at run-time how you balance the workload on CPU and GPU The following image shows the reduction in state changes (OpenGL function calls). Each square is a state change operation. Each line is a draw operation and consists of up to 7 state change operations and one draw call. Because of spacing there are 4 columns that should be seen as one big stream of draw operations (lines). This is only a part of an even longer stream of draw operations so some state changes are not visible at all in this image (red and orange). All of these OpenGL extensions are available on NVIDIA Kepler GPUs and some of them on Fermi. All of them are also implemented by AMD and Intel "for a pretty reasonable fraction of hardware". Here is a (hopefully complete) list of the used OpenGL extensions: Sparse Textures (contributed by AMD, NVIDIA) Bindless Textures (contributed by AMD) UBOs (contributed by APPLE, NVIDIA) Shader Storage Buffer Object (contributed by NVIDIA, AMD) Persistent Mapping (contributed by NVIDIA) Multi Draw Indirect (contributed by AMD) My opinion: If developers decide to move away from Direct3D, why not join the OpenGL club instead of Mantle? OpenGL is vendor-independant, extensible, well tested and optimized and works on most platforms NOW.