Oh, the irony.
Drivers:
Nvidia - Windows and Linux
Imagination - Linux
Intel - Linux
Qualcomm - Andriod
AMD - "AMD's has not passed the tests yet."
Looks like someone really screwed up here...Today the Khronos Group announced immediate public release of the open standard and cross-platform Vulkan 1.0 graphics API! To mark the occasion, we've posted Radeon Software Beta for Vulkan*. This driver enables a wide audience of game developers to work with Vulkan on Radeon graphics.
As a complement to OpenGL, descended from AMD's Mantle, and forged by the industry, Vulkan is a powerful low-overhead graphics API designed for developers who want or need deeper hardware control over GPU acceleration. Vulkan gives software developers control over the performance, efficiency, and capabilities of Radeon GPUs and multi-core CPUs.
...
http://support.amd.com/en-us/kb-articles/Pages/Radeon-Vulkan-Beta.aspx
Then:
Important Notes
This product is based on a published Khronos specification but has not yet passed the Khronos Conformance Test Process. A fully conformant implementation of the Vulkan API will be included in a forthcoming Radeon Software release.
This driver is intended as beta level support for use solely with Vulkan applications and as such some Radeon Software functionality has been removed. This is including and not limited to support for other Graphics APIs, Radeon Settings and other Radeon Software driver features.
The Talos Principle crashes for many NVidia users and it seems like AMD's driver performs better than Nvidia's.
Oh, the irony...
I wouldn't judge Vulkan or the drivers for a few months.
Passing tests doesn't give a full picture. Nvidia touted having WHQL DX12 drivers first, but when it came to how good the driver actually was....AMD's betas had less issues.
Date: Feb 18, 2016, 9:00am (PT)
Location: Online Webinar
Whats Vulkan all about? Learn more about this upcoming new graphics and compute API directly from Khronos, the people who have been creating it. In this 1-hour session, we will talk about the API, and also go into details about the Vulkan SDK from LunarG, and much more. Well of course end with a Q&A session, and a recording of the session will be available here.
Presenters
Neil Trevett: President of the Khronos Group
Karen Ghavam: Executive Director of LunarG
Standing by to answer questions
Tom Olson: Khronos Vulkan working group chair
Graham Sellers: Khronos Vulkan specification editor
Karl Schultz: SDK technical lead LunarG
Jon Ashburn: SDK technical lead LunarG
A video of the webinar will be available here after the event is over.
While true, the tests do give a baseline standard.
So, until we know if it was a major issue, or some trivial matter it is hard to say anything other than they failed a test(s).
It just looks bad, no matter how you splice it.
You would think AMD's drivers would have already passed the Khronos Conformance test (the Beta AMD drivers released today for Vulcan say, in the notes, say that AMD has not yet passed the test.) Especially since Mantle was given to the Khronos group by AMD.
BTW, the VP of the Khronos Group is a high level Exec with Nvidia.
Base line standard sure. IDK about looking bad. I'm seeing the Talos Principle benches showing a conformant driver losing to a non-conformant one.
Q: Then I can expect some great benchmark results?
A: Not so fast! Sorry. This is a beta phase, and there's still work to be done from our (Croteam) side and IHVs from driver side. But please be patient: in time, after optimizations are done, Vulkan will be faster, I'm sure.
Q: Really?
A: Let me put it this way: When The Talos Principle came out, it had a very similar frame rate in DirectX 9 vs DX 11. But then we optimized the game, and the drivers were optimized in the meantime, and now D3D11 is 20-30% faster than D3D9! I have a firm belief that this will also happen to Vulkan vs D3D11, over time However, for now you can actually expect lower frame-rate compared to D3D11. C'mon, it's brand new API, give it some time.
Q: Cut to the chase, please!
A: Ok, first, in GPU-bound scenarios (ultra settings, resolution higher than full HD), you'll see lower performance, 20 to 30% lower. This is work in progress, and we (both Croteam and IHVs) are analyzing and optimizing the performance. We'll get to the bottom of this!
Q: And CPU-bound scenarios?
A: Same or a bit faster. But for now, those scenarios really have to be super-CPU-bound. Like, rendering whole levels, without any help from visibility system, frustum, distance or occlusion culling.
Q: Oy! Talos freezes after some minutes in game.
A: Let me guess... you have Windows 10 and nVidia graphic card?
Q: Yes.
A: Well, it kinda does that from time to time. We're still investigatin the issue... Sorry again.
Why are you guys saying that amd doesn't have Vulcan drivers?
Not having passed drivers for the day 1 release of what is supposed to be based on their own API. That's a big blunder.
But on the other hand Vulcan seems no match for even DX11.
BETA patch with initial port of rendering path to a new API with BETA drivers from both IHVs... nothing unusual from performance side of viewNot having passed drivers for the day 1 release of what is supposed to be based on their own API. That's a big blunder.
But on the other hand Vulcan seems no match for even DX11.
But on the other hand Vulcan seems no match for even DX11.
But on the other hand Vulcan seems no match for even DX11.
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/Edwin,
engine design for Vulkan is basically consited of three major parts:\
1)
Port. Make it work as fast as possible just by wrapping current engine design around Vulkan. Avoid all pitfalls and bottlenecks. This is what we did by now and released as patch for Talos.
2)
Use Vulkan for multi-threaded rendering. Our engine is designed really well for multi-threaded rendering, but we have only our wrapper for it - calls to graphics API (like Vulkan) are not multi-threaded. Yet.
That being said, this is the next step what we'll do. And probably release that also as patch for Talos. I tried to do that with Direct3D 11 long time ago (support for its deffered contexts), but it was too much pain and too little or even no gain. That's just one of reasons why we decided to stick with our own approach for MT renderer for that long. :/
3)
Redesign engine for Vulkan. This is the biggest step and can be split in two:
3a)
Precache all rendering states (which mostly mean materials in game) up front. This will make rendering calls much simplier and faster. So, instead of deciding at rendering time what is needed for a material to be rendered via Vulkan, do this at loading time and then when material needs to be rendered just give it to Vulkan, via one or two simple function calls.
3b)
Precache all geometry, material, textures, everything that is needed for rendering an object up front. This basically creates so called command buffer ready for Vulkan, and nothing extra needs to be set or created at render time.
3rd part of port is, obviously, the most complex one, and it'll take time to change engine design for it, step-by-step.
Hope I explained this well.
DEN