High level APIs and efficiency.

[smackababy]

So, with all the talk about AMD's Mantle and Nvidia claiming Direct X doesn't actually degrade performance a lot, what is the truth?

I've only really developed for PC and just really started using DX, so I am curious of the real impact.

I remember there being a lot of talk when DOS was going away that losing the low level access would make games worse, but that never really happened to my knowledge.


Currently, is DX really that inefficient? And if so, by how much is it really going to improve with low level access?

This really doesn't have to even pertain to gaming high / low level APIs. For instance, if I write machine code, will it actually perform significantly faster than writing code that uses an interpreter?

 

[Jaydip]

So, with all the talk about AMD's Mantle and Nvidia claiming Direct X doesn't actually degrade performance a lot, what is the truth?

I've only really developed for PC and just really started using DX, so I am curious of the real impact.

I remember there being a lot of talk when DOS was going away that losing the low level access would make games worse, but that never really happened to my knowledge.


Currently, is DX really that inefficient? And if so, by how much is it really going to improve with low level access?

This really doesn't have to even pertain to gaming high / low level APIs. For instance, if I write machine code, will it actually perform significantly faster than writing code that uses an interpreter?

Yes it will but there is a trade off.For e.g if the competition comes up with something drastically better you will have to do the same things over again.Dx is not inefficient at right hands but it can be if the developers are lazy enough.There are lot of deprecated functions in the newer api but the old engines probably still use them.The problem with dx is that it has not evolved at a faster pace.Without looking at the api it is impossible to tell how much will mantle improve upon dx but as it supports only a subset of hardware the optimization will be relatively easy.

 

[brandonb]

DirectX isn't inefficient. It's actually quite efficient.

However, DirectX has a pipeline and does a lot of things behinds the scenes that you have to use when programming for it. Take a look at the DirectX pipeline.

http://msdn.microsoft.com/en-us/library/windows/desktop/ff476882(v=vs.85).aspx

As you can see there, there's a handful of little boxes, and all the steps required for rendering. Some of those steps can be configured by the developer (such as pixel shader stage) and some of them not able to be configured. Plus the glue between the steps.

Take for example. You want to display a JPG (texture) on the screen. You have to take a quad (2 triangles that fill the entire screen) assign the texture, and sent it through the pipeline so things work out in the end. This runs the geometry shader, the vertex shader, the pixel shader, and so on.

With Mantle. You could potentially just send commands to it and bypass the pipeline all together. Maybe just tell the graphics card to copy the JPG (texture) memory location and write to the frame buffer. No need to make a quad, or to run through the various stages. Just "memcpy". So it would end up faster. But then at the cost of less flexibility. Pixel shaders wouldn't run so special effects would not happen. Again, this allows the developers the option, while with DX, you didn't have the option.

Now on the other hand. With Mantle, if you want to develop with it. You have to pretty much write your own pipeline, and in the end, if you cloned DirectX chances are, it would run the same speed. See, there is nothing wrong with DirectX, but with Mantle you can override/change things to suit to your needs, remove functionality to gain speed, and so on. This opens the doors for people to build their own DirectX or Graphics API if they choose to. Prior to mantle, all this was closed source/up to the driver teams.

The classic programming case of "speed vs. flexibility" DirectX is flexible. Mantle can be fast. To make Mantle as flexible as DirectX its speed will be reduced to that of DirectX (more than likely). That is not to say DirectX is inefficient.

 

[beginner99]

For instance, if I write machine code, will it actually perform significantly faster than writing code that uses an interpreter?

What do you mean with an interpreter? Something like php?

then yes but other language like Java (JVM) not always. Yes machine code is faster but its much much harder to get right and often it's not needed at all.

It's a trade off: Do you want ultimate performance or compatibility and easier development? Consoles = the earlier, PC = the later. Thats why consoles can do pretty amazing things given the crappy hardware.

 

[Cogman]

What do you mean with an interpreter? Something like php?

then yes but other language like Java (JVM) not always. Yes machine code is faster but its much much harder to get right and often it's not needed at all.

Yup. The main benefit of compilers is consistency. They may not always produce the absolute fastest machine code, but they will always produce pretty good machine code (referring to lower level languages).

Every day, compilers are generating code that is better and better. The cases where a human can beat a compiler are shrinking every day.

 

[smackababy]

What do you mean with an interpreter? Something like php?

then yes but other language like Java (JVM) not always. Yes machine code is faster but its much much harder to get right and often it's not needed at all.

It's a trade off: Do you want ultimate performance or compatibility and easier development? Consoles = the earlier, PC = the later. Thats why consoles can do pretty amazing things given the crappy hardware.

I mean like the difference between writing code in native machine code vs writing something like BASIC that uses an interpreter to interpret the code into machine code. Similar to a compiler, except a compiler doesn't translate it at run time, but at compile time.

 

[Cogman]

I mean like the difference between writing code in native machine code vs writing something like BASIC that uses an interpreter to interpret the code into machine code. Similar to a compiler, except a compiler doesn't translate it at run time, but at compile time.

Are you talking about statically generated code vs dynamically generated code?

Thus far, the fastest code comes from static code generation (in most cases). This isn't always true. For example, Java isn't statically compiled (really, it is compiled to a bytecode, but for the most part that bytecode converts pretty readily back to straight java).

Java is interesting because something it does better than Statically compiled languages is inheritance. Java can beat C++ when it comes to virtual inheritance because it can make assumptions while running that C++ just can't make. For example, lets say you have a collection of object X with function Y on it. If the majority of the collection (or all of it) is the exact same concrete type Z, java will make that assumption while running avoiding any sort of VTable look up. C++ simply can't do that right now. It has to do the extra vtable look up because it can't make any assumptions about what object is in the collection.

However, GC and other issues generally get Java slower than C++ generally.

The potential for JITed languages to be faster than statically compiled languages exists, it just hasn't happened yet. It may never happen because the JITed languages generally aren't focused on raw speed, but rather on developer speed.

 

[BrightCandle]

I suspect the Vista driver model is one reason why AMD has started to go this route. The pipeline got dramatically more complicated, convoluted and introduced latency in order to protect the operating system from the graphics drivers crashing.

The other driving force is likely deferred rendering and the way in which people are already working out ways to skip stages in the pipeline in DirectX. Part of the reason was limited performance on the consoles but partly because more and more of the functionality is being moved into shader programs and away from the fixed function. Lighting is the classical one that is defaulted in todays DirectX and then the result is enhanced in shader programs to actually light the scene properly.

Performance of draw calls might be the reason why they say they are doing it, but its the capability limitations and the fact that big AAA developers are bypassing the DX pipeline in odd ways combined with building their own pipeline to an extent that is driving this. So long as NVidia and Intel can support the API as well it has a future, otherwise it probably doesn't as its performance impact is likely to be quite minimal as we aren't usually limited by draw calls in todays games. Future games might use a lot more draw calls, but only if its possible on all the cards.