well i upgraded it from w8 so maybe that’s the problem 
I don’t see any advantage from it, besides that it looks pretty cool, maybe it’s cause i code too much and never use those w10 apps and social media.
And yes seems like DX12 has a thumb up for now, untill the day someone decides to work hard into making some good shader compilers for Vulkan, i just hope valve put some money on that, for the sake of competition, yes i a’m looking at you as well, Canonical and Red Hat.
calm down pal, i don’t give a -insert insult here- about Vulkan or DX12, i’m making a question, whoever does better is the one i’ll pick (they, in this case). Don’t send me to read the OP, you better read my post, and maybe apologize for misreading. Btw the 30% loss is about DX12, i doubt, and i’m not sure, that’s the same compared to DX11, let the expert and guru @INovaeFlavien answer that, if anything
It’s not really about the OS. Vulkan should be equal or superior to DX11 in all cases even with this shader compiler limitation. Even if the shaders aren’t optimized, Vulkan is intrinsically faster than DX11, therefore in the worst cases I’d expect framerate to be in the same ballpark than DX11. In the best cases ( a game that has simple, pre-optimized shaders or that isn’t fill-rate limited ) it would be significantly faster than DX11.
Chill 
Vulkan and DX12 are vastly superior to DX11 and OGL. Even with that 30% loss, you still probably had a 30% gain in the first place just because of the better api / less overhead. What it truely means is that unoptimized Vulkan is preventing your app for reaching its top potential, that’s all. For example:
OGL/DX11: 50 fps
Optimized Vulkan/DX12: 80 fps
Unoptimized Vulkan: 40-60 fps maybe ?
That’s an hypothetical scenario. The only real number we have right now is based on a single sample, the Talos Principle. Each game would be different, and I’m sure there will be games which won’t be affected that much by this problem. On the other end of the spectrum, I would expect us to be close to the worst case, since we have some uber-shaders that generate thousands of lines of shader code. Those aren’t even manually generated ( pre-optimized by us ) in the first place, they come from our own material compiler, so we rely heavily on the shader compiler to optimize it.
I was debating all of this with Keith the other day, and we reached the conclusion that we’ll probably try a simple comparison benchmark ( a full-screen quad with a super complex unoptimized shader ) before we take any final decision ( this should only take a day or two to implement ). That way we can figure out if the problem is as bad as we think or if we over-estimated it.
thanks @INovaeFlavien, i pointed to the older OS cause no DX12 and such, anyways, having the game on both DX11 and 12 would require more time when fixing a bug and such i guess. But i’m sure many would not mind about upgrading to w10 just to play the game, i would do that, indeed i’m on w10 just to be able to execute some programs and play some games that i can’t use on w8 anymore, and i don’t like those as much as i would like to play I:B.
Our plan is to keep a DX11 renderer as a fallback but it’s more work, because to switch to Vulkan/DX12 we need to revamp the entire renderer, which means also rewriting the DX11 renderer.
So in summary our plan is as follows:
In the coming months: write a shader benchmark Vulkan vs DX12
If shader performance is still an issue AND nobody’s developping an optimized shader compiler, use DX12 with DX11 as a fallback
If shader performance is not an issue OR somebody’s developped an optimized shader compiler, use Vulkan
Then this long and on the end pointless discussion should be settled, as both you and Flavien stated quite some messages ago: it’s a matter for the next 4-6 months anyway
Let anyone reviving this thread before its due time be treated as any necromancer is 
Ok well fair enough, Vulkan is still WAY too young to expect much atm. I mean we only have a couple games able to run it in basic fashion (Talos and something else I forgot).
Hopefully a GLSL to SPIR-V Optimizer will appear, I mean you can’t be the only ones using this shader technique? Anyway like I said early days and you can always revisit it at a later date when the project is finished.
Also keep a eye on the Linux/Open Source communities surrounding Vulkan, someone might just DROP a compiler that you guys can ‘use’ for free. Happens all the time in open-source.
You may have a new data set, but the original post disagrees with this assessment: http://www.anandtech.com/show/10047/quick-look-vulkan-performance-on-the-talos-principle
Vulkan barely beats OpenGL in FPS.
Look at this mob, now Vulkan doesn’t sound good and DX12 is a no go due to KS promise, you want to deny INS the pleasure of doing more engine work? 
[quote=“Red_Syns, post:211, topic:3174”]
You may have a new data set, but the original post disagrees with this assessment: http://www.anandtech.com/show/10047/quick-look-vulkan-performance-on-the-talos-principle
Vulkan barely beats OpenGL in FPS.[/quote]
Sorry ? How does that disagrees with what I posted ? It looks quite coherent to me. Besides, it was an hypothetical scenario.
DX11 has nearly double the FPS at 1440p, and 1.3-1.5x the amount at 1080p. I don’t see how that doesn’t disagree.
Well yeah, because OGL/Vulkan don’t have optimized shaders compared to DX11. DX12 would be even faster.
The point I was making is that you get a significant performance boost going from OGL/DX11 to Vulkan/DX12, but that’s assuming the shaders are at least as optimized as the old api. If that isn’t the case ( Vulkan ) then you lose back what you gained, and you end up with little to no performance improvement compared to the old apis. That’s coherent with Talos Principle’s results.
Right, but OGL is not on the table (that I’m aware of?), the discussion is DX11 vs Vulkan vs D3D12. Your post contended that Unoptimized Vulkan was approximately equal to DX11, when it is very much not, until the shader issue is fixed.
Look, until some actual tests are done on this game, we can speculate till the cows come home to roost. All that is known is that there are problems with Vulkan, but the exact effect on this particular game is anybody’s guess.
Who knows? Vulkan might reeeeeealy like IB… for some reason… magics…
A Vulkan that likes Space? What nonsense.
TEST…TEST…TEST…
Because I was speaking of them in parallel. Going from DX11 to Vulkan is indeed a different scenario where you’d be likely to lose a significant amount of performance, simply because DX11 shaders are optimized while Vulkan’s aren’t. So it’s more like OGL -> Vulkan and DX11 -> DX12, not really DX11 -> Vulkan or OGL -> DX12.
Anyways, my point still stands: the new apis have better cpu usage and performance overall, but if you’re fill-rate limited and all matters is shader performance, then you better be sure your shader compiler optimizes it. Otherwise, it doesn’t matter if the api can run with low overhead on multiple threads. That’s what we’re seeing with the Talos principle. I have no doubts that if the shaders ran optimized, Vulkan would end up higher than DX11 on these benchmarks.
After reading this thread I now think the best course of action would just be to finish the game with DX11.
I honestly also don’t care about a performance improvement, the game already runs great on my machine. I’d rather see more time spend on actual game play development. Because in the end thats what really matters and what will make or break the game / whole company.
Vulkan also seems like a pointless exercise. What would the real benefits be?
vs months of development and uncertainty.
Finish game. Release on Steam. Collect money.
Are we sure that the current performance will hold, though? I’m pretty sure the textures will get more intensive, and we don’t have nearly as many ships flying around getting blown up and shooting things as we will in the end product.
The performance will likely improve. For example: there is currently no asset streaming implemented, meaning everything gets loaded when the game starts (thats how I understood it) and there is currently also no level of detail implemented for non-procedurally created assets.