Enjoying Vulkan so far in the recently patched Doom, which netted me a minimum 10% increase in frames per second. I really hope this gets adopted / patched into current games, and those on the horizon. Seems like a big win for cross platform development.
The problem is that Vulkan isn't so much a replacement for OpenGL as it is a library that you can use to write OpenGL in the first place, it's another layer removed, and hence requires quite a lot of work to integrate.
So hold on. Assuming that I understand C++ linking right, you're saying that I should include this 17000-line file in every single cpp unit in my application that uses Vulkan APIs? And people wonder why C++ programs compile so slowly.
You may understand the mechanics of C++ linking (although I doubt it because including a header has nothing to do with linkage, I'm assuming you mean ADL, overload resolution, etc), but it doesn't seem you understand the mechanics of how C++ compilers are built and optimized. Furthermore, how many cpp units do you expect to require the Vulkan API? If it's much more than a few dozen, I would argue you haven't organized your engine well. Source: former graphics engineer.
>And people wonder why C++ programs compile so slowly.
People have been aware of this problem for some time. It's one of the reasons the C++ community is trying to develop a proper module system (or was the last time I checked, which was a while back).
Here's a basic tutorial with comments for the Vulkan C API. Vulkan is a very low level API, so there's a lot of code. It should be straightforward to port the C tutorial to use the C++ API.
I don't know why this is downvoted. Several of the author's claims about C are just wrong. Modern C compilers can warn you about most of these, and literal initializers eliminate the missed zero initializations.
It isn't type-safe in the sense you're used to in C++. But common pitfalls can be avoided if you don't destroy the type information by assigning through a vanilla integer.
enum a { A };
enum b { B };
static enum a a = B;
$ clang -Wenum-conversion -Werror a.c
b.c:4:19: error: implicit conversion from enumeration type 'enum b' to different enumeration type 'enum a' [-Werror,-Wenum-conversion]
static enum a a = B;
~ ^
1 error generated.
The easy ability to assign it to a vanilla integer or cast it implicitly (through an arithmetic operator or comparison for example) is what I mean when I say they aren't typesafe. A warning is also a fair bit weaker than a flat out compile error, although I'll grant that compiling with -Werror (a really challenging thing for most companies) alleviates that.
Yeah, it isn't real type safety. That said, don't assign enums through vanilla integers if you don't have to. :-)
Our engineering organization of 300+ people builds the majority of our code with -Werror (and a bunch of warnings enabled). Just an anecdote, of course.
Whoa now that is cool! Are there any games out there that currently use this C++ API of Vulkan? Very curious to know if there are any major issues with using it versus the direct C API.
I'm not very knowledge regarding Vulkan so hopefully that isn't a stupid question but I want to brush up on my C++ skills and play with this!
Also how similar is Vulkan to SDL? I used to use SDL quite a bit back in the day and it was awesome but I'm assuming Vulkan is far more comprehensive?
As a game developer I'm pretty excited about this. There is really no reason to use DX12 backend anymore in the future game development, because of the ease of development, performance and multiplatform features of the Vulkan.
I think the pain point of DX12 is it's incompatibility with Windows 7 (and 8). However, Windows 10 is getting a lot of traction and has surpassed Windows 7 in gamers market share (see http://store.steampowered.com/hwsurvey/directx/).
With that in mind, if you are working on a AAA game that will come out in a couple of years, your target platforms will most likely be PS4, Xbox One and Windows 10. With those three, Vulkan doesn't make sense; DX12 will be used on Windows and Xbox One, and PS4 has its own proprietary API. Why complicate things with another API if you can use (almost) the same implementation for Xbox One and Windows 10?
If Windows 7 proves itself to be still somewhat popular amongs gamers, then Vulkan might be used to port games to this platform, since it's similar to DX12 so it will be way easier than a DX11 port.
However, right now, if game developers wants to use the latest API, Vulkan is a good choice since you will still be able to target Windows 7. If a lot of big games are released with Vulkan within 2 years, then it might slow down Windows 10's adoption and the market share of Vulkan systems (Windows Vista and up) will stay greater than the DX12 one (Windows 10) for longer. But for how many years? At one point, Windows 10 (or whatever's after) will dominate and the backward compatibility of Vulkan will stop being a useful marketing point.
So I'm not sure why you say there's no reason to use DX12. There's many. There's also a lot of good reasons to choose Vulkan that I didn't talk about here. I just don't see how Vulkan can dominates the Windows market, much like OpenGL.
Because all three are APIs which try to provide a lot more control over the GPU to game developers. And I wouldn't know of any other similarities that DX12 and Metal share...
Yes for the XBox ONE, although there are some small differences with the desktop version, at least until the upcoming Aniversary update.
But the point he was making was that there is no need for DX12 because Vulkan works everywhere else.
Right now Vulkan is only supported on custom Android 6 forks for Samsung S7 and NVidia Shield, Android 7, GNU/Linux and Windows on a restricted set of graphic cards.
Hardly a market to target for game developers that want to reach as much eyes as possible.
Windows 10 users are already 45%, with around 41% having DX 12 GPUs + plus around 20 million Xbox One units.
As for market size of Vulkan, some S7 and NVidia shield as part of 10% Android 6, 0% on Android 7 until it reaches stable and of course those other 55% users that might have a Vulkan compatible card.
You didn't answer the question. DX12 has less market than Vulkan, and will always be limited to MS systems. It's not available on PS or iOS and such. So bringing them as a reason to use DX12 instead of Vulkan was pointless.
> I very much doubt Microsoft will bother to support Vulkan if AAA studios don't ask for it.
They will eventually, when they'll get fed up with MS lock-in stupidity. In order for it to happen, competing market should put more pressure on MS. MS drops lock-in only from fear of competition. And it will eventually happen - there is no need for reinventing the wheel.
People in the industry call that support and productivity thanks to proper tooling instead of leaving each one alone to scatter around for half baked FOSS libraries, but I don't expect activists without experience in the big boys league to understand it.
> People in the industry call that support and productivity
People call that MS tax, since it makes their development more costly. Whether it's developers who work on their own engines, or engine developers who provide their engines for others, this cost is passed to the end user in the form of more bugs, slower development and so on. No sane developer appreciates lock-in. But currently they have no choice.
What people? Indies and FOSS activists that probably still write M$ to this day and believe that Sony and Nintendo or even Sega in its former days are any different.
I really bet none of those ever walked the floors of GDC.
Anyone who thinks and cares about progress and doesn't drink Koolaid served by MS and Co. Surely not lock-in freaks, who frame their tax on the industry as something positive.
> I really bet none of those ever walked the floors of GDC.
You sound like GDC is owned by MS, or it's ought to be. Are you paid by them? Either way, it's a very poor way to measure opinions or their value. Find something better.
No, I am someone that in a past life was allowed to spend some time in the backstage how big boys do games and still keep some of those ties, even though I just do IT enterprise consulting nowadays.
No one in GDC hallways speak of lock-in as activists believe they do.
You claimed no one talks about it on GDC. So which one is it? No one, or some do? Just admit your statement was false.
And surely you don't expect MS and its cahoots to talk about lock-in. They are pushing it to mess up everyone else, so they aren't going to bring this crooked practice into the spotlight.
Well, considering game industry experience with OpenGL on Windows (which is in short - it doesn't work on production scale) as a game developer I, unfortunately, really doubt that it will gain any traction on Windows based platforms.
To be fair I've seen many game developers complain about the version of OpenGL that is included in Windows. Perhaps this had changed but I used to work with a few folks that did game developer on the side and it seemed to be a constant headache.
Though I'm sure there are ways around it, etc. I'm not very knowledgable on the subject but I'd certainly love to know more :)
I wish I could somehow flag or block people who make such false comments disguised as fact. Less than 30 seconds looking into Vulkan would have told anyone almost the opposite if what you came up with.
Someone correct me if I am wrong, but I believe once you reach a certain karma point(s) you receive the down vote arrow. Maybe reporting posts goes along with that?
Just to add to the issues with this statement, Vulkan doesn't necessarily target a "GPU" since a CPU can also render frames just fine. More accurately, Vulkan, like DX12 is a graphics/compute API, with the distinction between graphics and compute pretty blurred at this point.
Whoa holy smokes yeah I missed the mark on that one. So Vulkan is a replacement for openGL, essentially a new api to gpu's in general? Is that closer to it? In the future I'll phrase the statement as a question if I'm not 100% clear on it. Sorry for the noise.
Vulkan is a new API standard from the Kronos group meant to compliment opengl and opencl by offering lower level access and merging the graphics and compute APIs.
It was gifted to Kronos from AMD where it had been called mantle.
It's a new API, and a much more low level one. Meaning you need more code to do stuff, but you have more control over each step, which wasn't available to you in previous APIs.
For example, capturing a game screenshot. In OpenGL you have a method glReadPixels which will flush the GPU queue, wait for operations to finish, read the screen pixels, convert them and put them into an array. All in one method, all outside of programmer's control, done somewhere in the driver. Meanwhile in Vulkan, same task requires programmer to flush GPU, wait for operations to finish, allocate memory for an image, create an image in linear format, transition image to proper state (transfer destination), transition swapchain image to transfer source, blit the pixels from swapchain image (which could be linear, could be tiled) to linear image, transition swapchain image back, map memory of the linear image. A single line of code in OpenGL translates to about 50 lines of Vulkan code (lot of it is stuff you'll write once and reuse everywhere else), but you have full control over each of the steps.
