Vulcan don't have shit on dx12 and it will stay the standard sorry the pipeslines are just way too easy for dx12 a crossed multiple systems

Microsoft should be in panic mode?

Lmao

Keep hating.

People are not leaving Windows. It's the most used OS and universally known.

Why the hell do people still think that you only need one code-path for multiple devices with Vulkan. That's just not true. You must still implement different code-paths for different devices. Just some basic operations may just be the same.
Also DX12 still has some things beside the graphics API inside, nobody is talking about. Sound, input devices etc, everything is included in DX12, while Vulkan is only the graphics part.

One can use their own graphics API's on Xbox. You aren't restricted to DX except for some system level functions which are built into the Xbox API. Vulcan is useable on X1, or any custom built solution that a dev can come up with....which is quite rare or non-existent nowadays.

In any case, porting between Vulkan/OGL and DX is common, and they share many of the same features to make it even simpler compared to past iterations of the API's. In general, on consoles, even if a dev is using Vulkan or DX, they wills till modify it to suit their needs. The really low level stuff uses the same processes between the chips, the developer just has to be aware of how many of those processes can be used at one time. The reason it's probably better to use DX on Xbox is because the system is designed around the API, and can perform DX tasks with quite a bit of efficiency, thus making it more beneficial, and less work, to simply "port" the code over to DX....which isn't as hard as it sounds. Vulkan, or some variant, is still the primary starting point for most games that are multi-plat though.

That being said, there is no such thing as one code path. If that's what a dev wants, they will have to use a fairly high level API or framework, and that isn't ideal for demanding games because too much power is wasted in the process. However, if a dev is good, they can encapsulate their code to be able to adapt it easier between different API's, and adjust where needed if a system can't do certain things. More often than not, a game engine is used, and the better modern game engines handle all that for the dev, but likely needs device specific optimization.

There isn't really anything "special" about DX12. It's a nice API, and has it's advantages over Vulkan. But Vulkan is just as good in terms of the render pipeline, and is more adaptable due to it's ability to allow more custom code to be attached to it and either circumvent or supplement aspects of the pipeline which don't suit a particular developers needs. DX12 allows this on consoles to some degree, but it can cause compliance issues if done without considering code security and isolation.

You are right though that Vulkan, for the grand scheme of things, actually does have the advantage. Quite a bit actually, and is in use on more devices than MS has available to them. That's just because MS locks DX behind Windows, and it's not available to use on non Windows systems. For games though, they still get Windows support, and thus DX support, because that is where the gamers are.

Luckily going forward, the distinction of DX and Vulkan will be less of a thing in GPU's, as there is more harmony between the two API's through GCN.

@Mulando

Those other, non graphics part of the API are often not used as most game engines have their own built in solutions to such things. Most of them allow for using those extra things though. On Xbox, I believe the only one that is required to be used is the input part of the API. Everything else is up to the dev, and they can forgo DX graphics API's altogether if they wanted to, although I can't imagine why they would. If you notice in most games, there is usually some 3rd party sound solution at play. Developers coding specifically for Windows PC would likely use more of the DX functions available.

@LastcenuryRob26m ago
["Panic mode"....Really? Somehow I very much doubt MS is in panic mode especially since DX12 is pretty darn good.]

Well, you and others may not see it, but there is some kind of mode and its to try to keep developers from using other Operating systems. As well as other frameworks. Other than Windows as the developers. Go to code base for what ever framework. They happen to be going to.

Now Microsoft. Has Built into Windows 10 :

http://www.pcworld.com/arti...

Top it off Microsoft. Also done this:

http://www.theverge.com/201...

If those. operating. Systems were of no consequence, why would Microsoft invest, take resources and put those resources toward adding support for such in Windows 10 OS? Its very simple .

Microsoft. Want to keep the consumer and development community to use Windows 1st before other Eco systems..upto this point Microsoft. Has never had to add Linux command line or an Apple 🍎 OS or a open source OS built into their Windows Operating system this is not just 3rd party doing this..this is Microsoft themselves doing this , so after all of these years with Windows 98 on to Vista , windows 7, or Windows 8.1.

Why would Microsoft now have to invest Time and Money and Resources into another OS outside of their own Windows OS, but now not just make software for those Other operating systems, but now include directly into the Windows 10 Operating system itself and has done so with the start now? Even after unifying the Xbox & PC Eco system..

Its very simple, those other Operating systems has enough Consumers using those Operating systems and enough Developers using another Operating system to build Games & Applications. Without needing or having to use or even for that matter using Windows OS or its DirectX graphical Api..that Microsoft. Now needs to offer such Consumers and developers this option.
They Had no choice, Or it could or may end up getting worse for Microsoft as a company not to do such..

What MS considers open and what the rest of the industry does are two different things.
Does DX12 run on Mac? No
Linux? No
Android? Ios? No No.

It's the exact opposite of open

It doesn't even run on Windows 7 or 8... or Xp. Its closed to Windows 10. Thats the point of this whole story.

Open to MS means people can write their software to it without restriction. Not that they can use it wherever they want to, for whatever purpose they want to. DX is free to license, and there is no restriction on the software itself, but it most definitely isn't an open API if one were to use the proper use of the term open in relation to such things.

Keep in mind that the benefit of more abstraction layers is typically better compatibility in the long term. In terms of performance difference, it is minimal. We are often talking low single digits and it isn't even always clear who the winner is.

For developers, it is far more important to have proper support, a big community and knowledge sharing combined with efficient processes to create what they want. Performance is pushed, but only after all the other consideration are satisfied first.

"In terms of performance difference, it is minimal"

Uh huh. Yeah, and what are your qualifications for making that kind of assumption? Abstraction makes porting easier, and less need to write different code between devices or platforms. The performance hit is there, minimal or not, and while it may not seem like much on a single process or function, when you multiply that by thousands of processes, all running hundreds or thousands of times a second, it most definitely isn't minimal.

What's this single digits we're talking about? Is it an integer value? A double? Is it a percentage hit to performance? While for the most part, a "winner" may not be clear, the winner is more often than not the non abstracted implementation. How many bits of extra processing data before it becomes too much, and the developer hits a wall, because now they have code which isn't optimized to the system?

You are greatly unqualified to talk about abstraction layers. You don't really understand anything about interfaces or software/hardware protocols, so I'm having a hard time understanding why you would try to speak on it so authoritatively as if an abstraction layer is nothing to be concerned about. When DX12 was first announced, the idea of less abstraction layers was the godsend to cure all the overhead that existed within PC game programming. Now adding back in abstraction layers is OK?

What long term compatibility needs to be thought of? Is the dev writing their code to a specific device and that code needs to last through the ages, or are they writing to a platform which will already have the interpretive abstraction layer it needs to run that code going forward? That was the whole point of consoles going to x86, that they wouldn't have to worry about this constant incompatibility, and that the processes were more understood by the mainstream programmer. So they should build to that, and whatever GPU processes may be available to them through GCN to maintain that compatibiility going forward, not writing to some library which may or may not be supported in the future...but would be because it'll be running on a platform that is compatible. You don't need abstraction for compatibility, you just need the hardware or platform that can interpret the code properly.

For developers, by which I assume you mean game developers, it's important to be able to have the flexibility to achieve what they want, and if they have to go through abstraction layers, it means they will have less flexibility to do so, because it means they will have to write to an abstraction layer which may not support what they're trying to do. Abstraction layers exist to make coding easier. Not make it faster or more optimized.

What you're talking about here isn't some single abstraction implementation used to allow for some portability, you're talking about an overall API level abstraction layer which will have a real hit on performance. There are many abstraction layers that get put into a game design either from a game engine or the developer themselves for whatever reason. They do so because the "supported" and provided API's abstraction isn't good enough.

On consoles, why in God's name would you now be saying that not using low level implementation is perfectly fine? Consoles gain their power advantage through low level implementation, not abstraction, and I'm sorry, but any abstraction is a hit to performance. Performance isn't pushed through abstraction, sloppy optimization is, and we all now how well poorly optimized games run on any system. That is essentially what you are saying is now OK.

@dont

Please don't talk about tech like a developer would if your not qualified to do so. Rainslacker has proven many times over that he is quite knowledgeable with programming, APIs and in general anything related to software development.

Let the real experts explain how development works. Many times Rainslacker manages to explain software development in a manner that's easy for unqualified people to understand. That's why I appreciate his knowledge because while I'm no software developer, his explanations makes it easy for people like me to understand the subject and that's something that I highly value.

Meanwhile your comments (and lack of knowledge on the subject) only confuse those who are not experts that want to learn more about it.

Please if your not qualified to talk about software development please don't. There are others like you who want to learn from experts instead of unqualified people.

Yep, Agreed. That's what I was getting at. The word directX 12 = more power, That's how it's chalked up. Maybe better optimization per iteration which might help push the game out the door a bit quicker. Might help you get a handle of some resources your recently could from the metal but yeah, Never will it exceed the limit of the hardware.

Another concept with hardware that is lost is theoretical performance vs real world. Basically these technologies are to harness more of the theoretical performance or resources to obtain closer to that point then what the currently real world state is, an api helps to do that but so does an engine or a framework as well all in tandem and of course Hyper-V interations. Strictly speaking from a hardware software relationship.

Most people should at least know what a protocol or an interface is if they are talking about technologies per say, Libraries is more of a programmer thing but yeah.. agreed.