Vulkan VS DX12, a user perspective VS coders needs
category: gfx [glöplog]
Hi Pouet coders!
I was wondering; what is the general feeling of the demo coder community regarding the new APIs that have been recently released: Vulkan and DX12? DX12 have been available for a few months now and the Vulkan full API just been released a few days ago:
Vulkan release
Vulkan Nvidia
Vulkan AMD
Between Vulkan and DX12, from a user perspective, the choice is easy and obvious: Vulkan! Why? For me, the major reason is simply availability. I happen to have the following hardware:
A Winndows 7 PC
A Windows 8 laptop
A linux PC
An Android phone
Nvidia Shield
The only API able to run across all those platforms AND Windows 10, is Vulkan. So I have a personal interest to see Vulkan succeed. I also do not plan to upgrade to Windows 10 for various personal and technical reasons, one of which is I HATE the business practice of artificial market segmentation as DX12 could have technically been retrofitted to Windows 7/8, but M$ deliberately choose not to as a method to coerce people to upgrade to Windows 10.
As soon as Intel, AMD and Nvidia Vulkan drivers are normalized (not fully compliant yet on AMD side at the moment and only 1 beta release on Nividia side), my user wish would be to see more and more Vulkan release from demo coders and to let DX12 die the death it deserve.
Now, on the technical side of things, is there any significant advantages/disadvantages to code using the Vulkan or DX12 API? As I don't personally code, I do not have a single clue what the implications are! To make things easier, and this thread more interesting, you can now vote on this!:
1- Vulkan all the way!
2- DX12 all the way!
3- Either/or/both, depends on the circumstances!
4- Too soon to tell!
5- By their nature, demos do not need/benefit much from what those new API have to offer, and/or, for various other technical reasons, I'll most probably stick to DX11 and OpenGL 4.5 for a few more years.
Ramon
I was wondering; what is the general feeling of the demo coder community regarding the new APIs that have been recently released: Vulkan and DX12? DX12 have been available for a few months now and the Vulkan full API just been released a few days ago:
Vulkan release
Vulkan Nvidia
Vulkan AMD
Between Vulkan and DX12, from a user perspective, the choice is easy and obvious: Vulkan! Why? For me, the major reason is simply availability. I happen to have the following hardware:
A Winndows 7 PC
A Windows 8 laptop
A linux PC
An Android phone
Nvidia Shield
The only API able to run across all those platforms AND Windows 10, is Vulkan. So I have a personal interest to see Vulkan succeed. I also do not plan to upgrade to Windows 10 for various personal and technical reasons, one of which is I HATE the business practice of artificial market segmentation as DX12 could have technically been retrofitted to Windows 7/8, but M$ deliberately choose not to as a method to coerce people to upgrade to Windows 10.
As soon as Intel, AMD and Nvidia Vulkan drivers are normalized (not fully compliant yet on AMD side at the moment and only 1 beta release on Nividia side), my user wish would be to see more and more Vulkan release from demo coders and to let DX12 die the death it deserve.
Now, on the technical side of things, is there any significant advantages/disadvantages to code using the Vulkan or DX12 API? As I don't personally code, I do not have a single clue what the implications are! To make things easier, and this thread more interesting, you can now vote on this!:
1- Vulkan all the way!
2- DX12 all the way!
3- Either/or/both, depends on the circumstances!
4- Too soon to tell!
5- By their nature, demos do not need/benefit much from what those new API have to offer, and/or, for various other technical reasons, I'll most probably stick to DX11 and OpenGL 4.5 for a few more years.
Ramon
I hope Vulkan succeeds. I hope it doesn't end up just being a deep, low-level layer for larger libraries - which is somewhat inevitable. I hope we don't end up with creeping incompatibilities between platforms and manufacturers that are fixed in the higher-level libraries.
5.
Except I don't see myself using anything like Vulkan or DX12 even in the future, at any point, except when/if some nicer abstractions are created around them that mask away the underlying complexity. Also I guess this is more of a poll because I don't see what exactly I'd be voting for here.
Except I don't see myself using anything like Vulkan or DX12 even in the future, at any point, except when/if some nicer abstractions are created around them that mask away the underlying complexity. Also I guess this is more of a poll because I don't see what exactly I'd be voting for here.
5. with a little bit of 4.
For demoscene stuff I don't think many demos are CPU bound on the graphics side. In fact a lot of recent and very good looking demos are still using DX9/GL3.3 level features. Many great demos would only have maybe a few draw calls per frame, a lot of the work is all done in the shaders.
Honestly I am kind of waiting for the hype to die down and for things to move out of beta so I can evaluate some real world use cases and read internet discussions about the new API's that have relevant and correct information.
To answer your technical question the main benefit of the new API's is the potential to reduce CPU overhead and the ability to multithread the graphics pipeline. The new API's do not make the GPU run any faster, they just offer the ability to write very low level and specific use case code to reduce the overhead of CPU to GPU transfer. The disadvantage is that it is low level and arguably more difficult to code, at least to make an improvement over what we already have. A lot of the safety and generic use of the current API's can be avoided which is where the speed comes from but there is also a good chance of fucking things up.
For demoscene stuff I don't think many demos are CPU bound on the graphics side. In fact a lot of recent and very good looking demos are still using DX9/GL3.3 level features. Many great demos would only have maybe a few draw calls per frame, a lot of the work is all done in the shaders.
Honestly I am kind of waiting for the hype to die down and for things to move out of beta so I can evaluate some real world use cases and read internet discussions about the new API's that have relevant and correct information.
To answer your technical question the main benefit of the new API's is the potential to reduce CPU overhead and the ability to multithread the graphics pipeline. The new API's do not make the GPU run any faster, they just offer the ability to write very low level and specific use case code to reduce the overhead of CPU to GPU transfer. The disadvantage is that it is low level and arguably more difficult to code, at least to make an improvement over what we already have. A lot of the safety and generic use of the current API's can be avoided which is where the speed comes from but there is also a good chance of fucking things up.
I had this hypothesis that if you have more granular, fundamental control over the hardware, that would, generally speaking, create new opportunities to explore said hardware more... intimately! And perhaps open the door to novel and improved ways to code those graphics cards!
I always thought of the demo scene as a laboratory for experimenting, the place to push hardware beyond the prescribed limits. To do stuff never seen before on a specific hardware. Take the C64 for example, with new, once thought to be impossible graphics and sound mode discovered/created 10, 20 and even 30 years after the product was launched! Could Vulkan help do that for current GPU?
I know the main attraction of the new API is to reduce draw calls to the CPU, so you are less CPU dependent. But there are also many other improvements, like the possibility to use more than 1 CPU core (multithreading support). I'm just not familiar enough with all the new features to really make an educated comment on the subject beyond what I have already stated but it will be interesting to see in the future if some creative coders could find a way to stun us all with some new voodoo programming magic only possible with Vulkan!
I always thought of the demo scene as a laboratory for experimenting, the place to push hardware beyond the prescribed limits. To do stuff never seen before on a specific hardware. Take the C64 for example, with new, once thought to be impossible graphics and sound mode discovered/created 10, 20 and even 30 years after the product was launched! Could Vulkan help do that for current GPU?
I know the main attraction of the new API is to reduce draw calls to the CPU, so you are less CPU dependent. But there are also many other improvements, like the possibility to use more than 1 CPU core (multithreading support). I'm just not familiar enough with all the new features to really make an educated comment on the subject beyond what I have already stated but it will be interesting to see in the future if some creative coders could find a way to stun us all with some new voodoo programming magic only possible with Vulkan!
5 initially, then 1 (forgot to vote before)
I'm going with what @ramon said. All you have to do is look at Shadertoy to see what people squeeze out of the current shader pipeline - do you think the GPU designers would have imagined someone coding an implicit version of Doom E1M1 in a fragment shader? Or that people would be using the GPU to generate music?
I'm going with what @ramon said. All you have to do is look at Shadertoy to see what people squeeze out of the current shader pipeline - do you think the GPU designers would have imagined someone coding an implicit version of Doom E1M1 in a fragment shader? Or that people would be using the GPU to generate music?
Personally I'm more interested in the APIs people will write on top of vulkan than vulkan itself. If I felt like I had too much time on my hands, I'd probably write an opengl-like API on top of vulkan (to make that "opengl done right" version).. =)
5 and a bit of 4.
The new APIs offer the opportunity to do a better job than the dx11/gl drivers cpu code at issuing draw calls, managing resources etc. Large triple a game teams may be able to achieve that and need to because of large call counts. Demo coders probably don't want to invest that effort and wont get any benefit from it either as they're nowhere near being cpu bound (in most cases).
The new APIs offer the opportunity to do a better job than the dx11/gl drivers cpu code at issuing draw calls, managing resources etc. Large triple a game teams may be able to achieve that and need to because of large call counts. Demo coders probably don't want to invest that effort and wont get any benefit from it either as they're nowhere near being cpu bound (in most cases).
I'd vote for 2.
Support for Windows 7 or 8 is pretty irrelevant when Microsoft gives free upgrades to Windows 10.
Historically OpenGL driver support has been quite poor and inconsistent, which is the main reason why DirectX became the preferred standard on Windows.
The main problem here was that OpenGL is implemented entirely in the drivers, meaning that there are many small differences/incompatibilities between vendors, which makes supporting a wide range of hardware a lot more difficult (and beyond the reach of the average demoscener, who won't have access to a wide range of configurations for QA to begin with, and would not be interested in spending the time even if he did).
As far as I can tell, Vulkan is no different in this respect. It did not adopt the ideas put forth by the Gallium3D project, and as such, there is still no shared runtime implementing the basic API between vendors.
So I think we will still be seeing the same basic issues that we had with OpenGL:
1) Software will often fail on different configurations than the ones they were tested on, because of incompatibilities in the shader compiler and API implementation
2) Drivers have a far more direct effect on compatibility than they do with DX, meaning that after a few driver updates, demos may suddenly exhibit bugs or stop working altogether, on configurations where they once worked fine.
Vulkan is a nice proposition in theory, much like OpenGL, but OpenGL never quite worked in practice, and I don't see these problems addressed in Vulkan, so I think I'll stick with DX for the time being.
Support for Windows 7 or 8 is pretty irrelevant when Microsoft gives free upgrades to Windows 10.
Historically OpenGL driver support has been quite poor and inconsistent, which is the main reason why DirectX became the preferred standard on Windows.
The main problem here was that OpenGL is implemented entirely in the drivers, meaning that there are many small differences/incompatibilities between vendors, which makes supporting a wide range of hardware a lot more difficult (and beyond the reach of the average demoscener, who won't have access to a wide range of configurations for QA to begin with, and would not be interested in spending the time even if he did).
As far as I can tell, Vulkan is no different in this respect. It did not adopt the ideas put forth by the Gallium3D project, and as such, there is still no shared runtime implementing the basic API between vendors.
So I think we will still be seeing the same basic issues that we had with OpenGL:
1) Software will often fail on different configurations than the ones they were tested on, because of incompatibilities in the shader compiler and API implementation
2) Drivers have a far more direct effect on compatibility than they do with DX, meaning that after a few driver updates, demos may suddenly exhibit bugs or stop working altogether, on configurations where they once worked fine.
Vulkan is a nice proposition in theory, much like OpenGL, but OpenGL never quite worked in practice, and I don't see these problems addressed in Vulkan, so I think I'll stick with DX for the time being.
as a public thing it's bad. the closer you get to the metal the more of the differences you have. or not? it's got the same gl issues. incompatibilities between vendors. they all fux with their own design and code. cuda or amd got none or this or dx opti right now. i'm sure you can vulkan each vendor's performance. it's mainly coding/recoding a driver/their drivers. in dx the defaults are set. one piece of code set to run on both. ofc performance of this differs on that underlying driver implementation. vendor specific again. how good are their driver coders with scenerios. it's just who codes closest to the metal get's it done performant for what you do with it. vulkan is a production helper for specificly coded applications on a specific task and target hardware but not for all. that's it i think.
For small intros, definitely 5. The extra code needed by the much more verbose Vulkan API completely rules out its usefulness here.
For demos, probably 5 as well. As Smash said, demos very rarely need to perform lots of draw calls (though some may do it anyway).
For demos, probably 5 as well. As Smash said, demos very rarely need to perform lots of draw calls (though some may do it anyway).
Quote:
DX12 could have technically been retrofitted to Windows 7/8, but M$ deliberately choose not to as a method to coerce people to upgrade to Windows 10.
A lot of people want this to be true so they can have another reason to criticise Microsoft, but in this particular case it's because of improvements to the driver model in Windows 10 that can't be retrofitted to earlier versions without causing a support and compatibility nightmare. They COULD probably use software emulation or something to make the API run at all, but nobody wants that. This is the same reason you can't install Direct3D 9 in Windows NT 4.
Quote:
The main problem here was that OpenGL is implemented entirely in the drivers [...] As far as I can tell, Vulkan is no different in this respect.
Vulkan has driver conformance tests though. Too early to say how it works out of course.
@Scali
Very interesting comment. I was under the impression that outside the Microsoft ecosystem, practically everything runs under opengl. What I mean by that is opengl seems to have a large technological footprint, a high adoption rate.
Since the first D3D (DX3) and opengl (1.0) demos, what I remember is this:
1- If you want compatibility, use Nvidia hardware. From a user perspective, I do not remember issues with opengl or an easier time with D3D/DirectX. I do remember most .inf file mentioned to use Nvidia.
2- If I had to quantify, I would say that roughly ~40% of all PC demos are opengl. My evaluation might be inaccurate though... could be 50-50 or even 30-70, my point is opengl usage in demos seems to be statistically at least relatively significant, despite all the aforementioned limitations. That would beg the question: Why 90%+ of all PC demos are not DirectX?
3- To run any demo older than DX8 (DX3 to DX7), I must, 90% of the time, use a ddraw.dll wrapper (dgVoodoo is by far the best) to make the demo work on modern hardware/OS. Of all the demos I've tested, only a handful of old opengl demos would not work, all the other (like 98.5%) worked straight out of the box, no wrapper required. My point is, it look like that on the long run, opengl seems to be much more compatible than DirexctX. Or am I missing something?
You are raising a very interesting question when you say "As far as I can tell, Vulkan is no different in this respect." I would very much like to get empirical data on this. I know that Vulkan adopted/absorbed most of the best functionalities of AMD's Mantle API, but I do not know if the multiple opengl drawbacks you have mentioned effectively transitioned to Vulkan. I would think that the Khronos group took this unique opportunity of a major shift and fundamental changes in a new generation API to maybe address at least some of the opengl shortcoming you have pointed out.
Finally, I think the entire computing ecosystem got a lot more complex and diversified since the last major API upgrade to DirectX 11 and Opengl 4 in 2009. I suspect that being able to cheaply disseminate your code across a large numbers of platforms, like Vulkan would allow, is a very appealing prospect for modern publishers looking to control their production cost and increase their flexibility, including on the Windows platform.
Microsoft, for all intent and purpose, have thrown the towel on Windows 10 mobile with catastrophic/abysmal sales figures of their Lumia phone. There is is no equivalent to Windows CE anymore, so no set-top box, smart TV or anything like that either (unless MS have a super low profile Windows 10 version I'm not aware of). The Surface RT was a disaster too, so no ARM code anymore. DX12 only appeal at this point, as far as I can tell, is severely limited to Windows 10 and the Xbox 1. Windows 10 adoption rate is weak to say the least (at least nowhere near significant enough yet for publishers to commit 100% toward DX12) and the Xbox 1 is loosing the console war against the PS4, which incidentally, is rumored to also support Vulkan in the future to make cross-platform port easier!
Not a very bright future for DX12 in my humble opinion. Even less if Vulkan is anywhere near as good as it can theoretically be. I think MS have been caught with their pants down with the unexpected emergence of Mantle and didn't suspect a full API comparable to DX12 to be released so soon. Considering the market share reach of DX12 is now very limited, the only joker card Microsoft could play at this point is to allow DX12 on all platforms and I don't think I'll live long enough to see that happen. But who knows? Much crazier things have happened...
Very interesting comment. I was under the impression that outside the Microsoft ecosystem, practically everything runs under opengl. What I mean by that is opengl seems to have a large technological footprint, a high adoption rate.
Since the first D3D (DX3) and opengl (1.0) demos, what I remember is this:
1- If you want compatibility, use Nvidia hardware. From a user perspective, I do not remember issues with opengl or an easier time with D3D/DirectX. I do remember most .inf file mentioned to use Nvidia.
2- If I had to quantify, I would say that roughly ~40% of all PC demos are opengl. My evaluation might be inaccurate though... could be 50-50 or even 30-70, my point is opengl usage in demos seems to be statistically at least relatively significant, despite all the aforementioned limitations. That would beg the question: Why 90%+ of all PC demos are not DirectX?
3- To run any demo older than DX8 (DX3 to DX7), I must, 90% of the time, use a ddraw.dll wrapper (dgVoodoo is by far the best) to make the demo work on modern hardware/OS. Of all the demos I've tested, only a handful of old opengl demos would not work, all the other (like 98.5%) worked straight out of the box, no wrapper required. My point is, it look like that on the long run, opengl seems to be much more compatible than DirexctX. Or am I missing something?
You are raising a very interesting question when you say "As far as I can tell, Vulkan is no different in this respect." I would very much like to get empirical data on this. I know that Vulkan adopted/absorbed most of the best functionalities of AMD's Mantle API, but I do not know if the multiple opengl drawbacks you have mentioned effectively transitioned to Vulkan. I would think that the Khronos group took this unique opportunity of a major shift and fundamental changes in a new generation API to maybe address at least some of the opengl shortcoming you have pointed out.
Finally, I think the entire computing ecosystem got a lot more complex and diversified since the last major API upgrade to DirectX 11 and Opengl 4 in 2009. I suspect that being able to cheaply disseminate your code across a large numbers of platforms, like Vulkan would allow, is a very appealing prospect for modern publishers looking to control their production cost and increase their flexibility, including on the Windows platform.
Microsoft, for all intent and purpose, have thrown the towel on Windows 10 mobile with catastrophic/abysmal sales figures of their Lumia phone. There is is no equivalent to Windows CE anymore, so no set-top box, smart TV or anything like that either (unless MS have a super low profile Windows 10 version I'm not aware of). The Surface RT was a disaster too, so no ARM code anymore. DX12 only appeal at this point, as far as I can tell, is severely limited to Windows 10 and the Xbox 1. Windows 10 adoption rate is weak to say the least (at least nowhere near significant enough yet for publishers to commit 100% toward DX12) and the Xbox 1 is loosing the console war against the PS4, which incidentally, is rumored to also support Vulkan in the future to make cross-platform port easier!
Not a very bright future for DX12 in my humble opinion. Even less if Vulkan is anywhere near as good as it can theoretically be. I think MS have been caught with their pants down with the unexpected emergence of Mantle and didn't suspect a full API comparable to DX12 to be released so soon. Considering the market share reach of DX12 is now very limited, the only joker card Microsoft could play at this point is to allow DX12 on all platforms and I don't think I'll live long enough to see that happen. But who knows? Much crazier things have happened...
@absence
"because of improvements to the driver model in Windows 10 that can't be retrofitted to earlier versions"
I would like to read more literature that explain in details why WDDM 2.0 could not be easily made to work on Windows 7. Anandtech seems to imply that the main function of WDDM 2.0 is simply to allow for DX12 to do its thing. Not much more beyond that.
I remember reading a lot of stuff about how it was truly impossible to retrofit DX10 on Windows XP as the entire OS core of Vista was drastically different. Windows 7 is overall much closer to Windows 10 than XP was to Vista... I still think it was a calculated move from MS, also known as artificial market segmentation. That's my position, until I read specifics as of why it is impractical/impossible to backport WDDM 2.0 to Windows 7.
You have to admit that the fact Vulkan is able to do its magic across all those platforms, including Windows 7, where Microsoft itself failed to do the same on its own platform by playing its cards in such a way that people now claim "DX12 restricted to Windows 10 was inevitable" must at least raise some legitimate questions in your mind.
"because of improvements to the driver model in Windows 10 that can't be retrofitted to earlier versions"
I would like to read more literature that explain in details why WDDM 2.0 could not be easily made to work on Windows 7. Anandtech seems to imply that the main function of WDDM 2.0 is simply to allow for DX12 to do its thing. Not much more beyond that.
I remember reading a lot of stuff about how it was truly impossible to retrofit DX10 on Windows XP as the entire OS core of Vista was drastically different. Windows 7 is overall much closer to Windows 10 than XP was to Vista... I still think it was a calculated move from MS, also known as artificial market segmentation. That's my position, until I read specifics as of why it is impractical/impossible to backport WDDM 2.0 to Windows 7.
You have to admit that the fact Vulkan is able to do its magic across all those platforms, including Windows 7, where Microsoft itself failed to do the same on its own platform by playing its cards in such a way that people now claim "DX12 restricted to Windows 10 was inevitable" must at least raise some legitimate questions in your mind.
I kind of disagree that Vulkan is any closer to the metal though
I still kind of remember VGA CRTC registers (to set up mode-x and such) or VESA bios (to do bank switching) or even early deccelerators, where you had everything vendor-specific and practically everyone was a sort of a driver developer. But Vulkan, pffff... are you kidding me? It's full-blown high-level abstract API that average joe can understand and use. And if the support will be more wide-spread, I see why not use it in demos or even intros: maybe not 1k, as I think Blueberry had in mind I suppose, but for 4k/8k shouldn't be such a big deal IMHO
All I can see for now is you have to call vkAllocateMemory on your own, plus call vkBeginCommandBuffer before the usual stuff. Maybe you can even compress more by preparing commands on a GPU and using indirect draw calls all the way. To back-up my argument: as we have witnessed lately doing synth entirely on GPU works great for 4k's.
Disclaimer: I didn't say I have tried it or measured anything, but I am a bit more optimistic here.
I still kind of remember VGA CRTC registers (to set up mode-x and such) or VESA bios (to do bank switching) or even early deccelerators, where you had everything vendor-specific and practically everyone was a sort of a driver developer. But Vulkan, pffff... are you kidding me? It's full-blown high-level abstract API that average joe can understand and use. And if the support will be more wide-spread, I see why not use it in demos or even intros: maybe not 1k, as I think Blueberry had in mind I suppose, but for 4k/8k shouldn't be such a big deal IMHO
All I can see for now is you have to call vkAllocateMemory on your own, plus call vkBeginCommandBuffer before the usual stuff. Maybe you can even compress more by preparing commands on a GPU and using indirect draw calls all the way. To back-up my argument: as we have witnessed lately doing synth entirely on GPU works great for 4k's.
Disclaimer: I didn't say I have tried it or measured anything, but I am a bit more optimistic here.
Errata:
To be fair, I didn't think much about SPIR-V shaders and how big they are. Maybe they will turn out to be bigger than minified GLSL. And of course including GLSL translator in your 4k is a bad idea. Anyone has tried? Any thoughts?
To be fair, I didn't think much about SPIR-V shaders and how big they are. Maybe they will turn out to be bigger than minified GLSL. And of course including GLSL translator in your 4k is a bad idea. Anyone has tried? Any thoughts?
5. win7 & dx11 serve me good.
2. should i ever be forced to upgrade, it'll probably be dx12 or even a newer version.
2. should i ever be forced to upgrade, it'll probably be dx12 or even a newer version.
Quote:
A lot of people want this to be true so they can have another reason to criticise Microsoft, but in this particular case it's because of improvements to the driver model in Windows 10 that can't be retrofitted to earlier versions without causing a support and compatibility nightmare. They COULD probably use software emulation or something to make the API run at all, but nobody wants that. This is the same reason you can't install Direct3D 9 in Windows NT 4.
Once you upgrade to Windows 10, you should be getting this at last though. That is, Windows 10 is supposed to be the 'last Windows ever', and future versions will be rolled out as updates to Windows 10, rather than a completely new and separate OS release.
Quote:
Very interesting comment. I was under the impression that outside the Microsoft ecosystem, practically everything runs under opengl. What I mean by that is opengl seems to have a large technological footprint, a high adoption rate.
Problem is, OpenGL is not OpenGL, if you know what I mean.
Different vendors and different platforms support different versions of the base API, together with different vendor/OS-specific extensions.
For example, the latest OpenGL version is 4.5, but you can't get that on OS X, nor can you get it on various chips on Windows (notably Intel ones).
And then there's the thing that OpenGL ES is often lumped together with OpenGL when people want to show 'adoption rates', but it really isn't the same thing (as opposed to DirectX 11 on Windows Mobile, where both the API and the shader language are exactly the same as on desktop Windows. The only difference is the interface to the window, since Windows Mobile uses a different GUI. But that is easily solved with an #ifdef or two).
Quote:
Of all the demos I've tested, only a handful of old opengl demos would not work, all the other (like 98.5%) worked straight out of the box, no wrapper required. My point is, it look like that on the long run, opengl seems to be much more compatible than DirexctX. Or am I missing something?
My experience is exactly the other way around.
Quote:
Finally, I think the entire computing ecosystem got a lot more complex and diversified since the last major API upgrade to DirectX 11 and Opengl 4 in 2009. I suspect that being able to cheaply disseminate your code across a large numbers of platforms, like Vulkan would allow, is a very appealing prospect for modern publishers looking to control their production cost and increase their flexibility, including on the Windows platform.
But that isn't quite true yet, is it?
I mean, Vulkan requires a very modern GPU, so I doubt that all but the latest high-end smartphones will support it. Most smartphones will be stuck with a DX9-ish GPU, and are limited to Metal, OpenGL ES or DX11.
Quote:
Microsoft, for all intent and purpose, have thrown the towel on Windows 10 mobile with catastrophic/abysmal sales figures of their Lumia phone.
I don't think they have. I still receive Windows 10 updates on my Lumia phone regularly. And it seems that more and more people are starting to discover just how good Windows 10 Mobile is (especially for business).
Quote:
There is is no equivalent to Windows CE anymore, so no set-top box, smart TV or anything like that either (unless MS have a super low profile Windows 10 version I'm not aware of).
They also target IoT stuff, and recently released a version of Raspberry Pi? https://dev.windows.com/en-us/iot.
Quote:
I would like to read more literature that explain in details why WDDM 2.0 could not be easily made to work on Windows 7.
The explanation is simple:
Making it work means making some changes to the kernel at the driver interface level.
It's not about how easy they can make this work, because obviously they can.
The problem is, with these changes they can no longer guarantee that all drivers and all software will still work exactly the same as the earlier version of Windows 7.
They cannot guarantee this with Windows 10 either, but since it is a different product, they are not bound by law to remain 100% compatible with Windows 7. Besides, unlike Windows 7, Windows 10 is still actively supported, so they have a budget for developing and rolling out patches for issues.
So it's purely a business decision, not a technical one.
And as stated, they seem to have changed their business to instead keep updating Windows 10 indefinitely from now on, instead of rolling out a new OS (it's always one or the other).
Mostly 5 for demos. I could see someone writing something that uses vulkan to push a lot more stuff around, but that isn't the way the scene has been moving in recent years. On mobile it's different though, you don't get a ton of CPU power and vulkan can unlock a few useful options.
Outside of demoscene, a mix of 5 and 1. Cross platform and mobile are getting more important. OpenGL makes sense for most devs, Vulkan for those with lots of resources or a need to push the tech. DX12 is there for anyone writing for desktop windows.
I think windows phone doesn't even count in anybody's calculations when figuring out what platforms to support - it really is pretty much dead now, sales have collapsed in the last 12 months and few developers even bother porting to it.
Outside of demoscene, a mix of 5 and 1. Cross platform and mobile are getting more important. OpenGL makes sense for most devs, Vulkan for those with lots of resources or a need to push the tech. DX12 is there for anyone writing for desktop windows.
I think windows phone doesn't even count in anybody's calculations when figuring out what platforms to support - it really is pretty much dead now, sales have collapsed in the last 12 months and few developers even bother porting to it.
Who really cares about adoption rates and cross-platform-ness of these APIs when it comes to demo coding?
I'm not wasting my precious spare time to make sure my demo runs on linux/OSx, that's just a pain in the ass to do.
It's never just a case of compiling it on the other platform and it just works, even if you are using only cross-platform libraries.
Probably the best reason for using Vulkan/DX12 for democoding is just the thrill/fun of diving into a bleeding edge low-level API.
You're probably not going to make something with it that couldn't have been done with DX11/OpenGl.
Your demo is probably not going be smaller because of Vulkan/DX12. Less is done for you by the driver/API so that means more needs to be done on the application side.
If I'd had to choose between Vulkan/DX12 right now, I'd go with DX12 because Microsoft has become pretty good at writing APIs and their documentation/samples/tools are usually top notch (though not perfect).
I'm not wasting my precious spare time to make sure my demo runs on linux/OSx, that's just a pain in the ass to do.
It's never just a case of compiling it on the other platform and it just works, even if you are using only cross-platform libraries.
Probably the best reason for using Vulkan/DX12 for democoding is just the thrill/fun of diving into a bleeding edge low-level API.
You're probably not going to make something with it that couldn't have been done with DX11/OpenGl.
Your demo is probably not going be smaller because of Vulkan/DX12. Less is done for you by the driver/API so that means more needs to be done on the application side.
If I'd had to choose between Vulkan/DX12 right now, I'd go with DX12 because Microsoft has become pretty good at writing APIs and their documentation/samples/tools are usually top notch (though not perfect).
Sinar: "outside the demoscene". Inside we do what the hell we want :) Outside does affect us though - e.g. if vulkan isn't widely adopted I'd expect driver quality to be bad.
psonice: My post wasn't meant as a direct reply to yours, but yes outside the demoscene these things do matter. Since Vulkan's much closer to the hardware than OpenGl, hopefully that translates into better driver support because the driver needs to do less work. Less driver code should mean less bugs (and hopefully better compliance).
Quote:
I see why not use it in demos or even intros: maybe not 1k, as I think Blueberry had in mind I suppose, but for 4k/8k shouldn't be such a big deal IMHO
You must be kidding! Just look at this simple example for rendering one triangle. How should that beat an openGL fragment program with glRects or a DX compute shader with device->Dispatch?
I'd consider Vulkan and DX12 just for toying around with the pipeline state objects, which is a charming architecture. Other than that, 5.
