FordGT90Conceptwww.guru3d.com/news-story/quick-test-futuremark-3dmark-v2-3-3663-vulkan-api-overhead-benchmarks.html

This is just wild speculations from Guru3D, there is no actual evidence.

To prove your claims of Nvidia optimizations wrong:

As with every 3DMark release, Time Spy was developed with input from industry leaders including AMD, Intel, Microsoft, NVIDIA, and the other members of our Benchmark Development Program (BDP).

source

The result is unexpected, ergo the foregone conclusion is something will happen in the future to fix it.

Just because Futuremark requests input doesn't mean Futuremark implements the suggestions.

FordGT90ConceptThe result is unexpected, ergo the foregone conclusion is something will happen in the future to fix it.

Unexpected how? So benchmarks are bad because they don't show the "expected" advantages for AMD? That's the same stupid excuse we heard when the Time Spy benchmark was released and all the fanboys dismissed it because AMD was not superior in it.

If all the benchmarks should be optimized for AMD hardware, then we are no longer benchmarking the same thing any more.

Vulkan is AMD's baby (built off of Mantle). Vulkan should get better frame rates than D3D12 because of less hand holding. GeForce is expected to get about equal or slightly better performance on Vulkan than D3D12. Even so, GTX 1060's result appears like an outlier much like Radeon; it could be explained by memory though (D3D12 may use > 6 GiB where Vulkan can stay < 6 GiB). Radeon seeing better performance in D3D12 than Vulkan is a completely unexpected result.

efikkanIf all the benchmarks should be optimized for AMD hardware, then we are no longer benchmarking the same thing any more.

Except that optimization is the norm. It must be because something as simple as a buffer being different sizes in the hardware can beget very different results in performance running the same software.

bugAh, kids these days... won't read anything longer than jingle.

It's not about what I consider better, it's about what the guy who posted claim considers better. And he literally said Vulkan "offers better fps, visuals and dev friendly".
But hey, let's ignore actual contents and post whatever we like, right?

NB I agree with all that you said and I'll take a cross platform API any day, but that was never the issue here.

QUOTE:
1) Vulkan™ supports close-to-metal control enabling faster performance and better image quality across Windows® 7, Windows® 8.1, Windows® 10, and Linux®. No other graphics API offers the same powerful combination of OS compatibility, rendering features, and hardware efficiency.

2) Developed by the Khronos Group, the same consortium that developed OpenGL®, Vulkan™ is a descendant of AMD’s Mantle, inheriting a powerful low-overhead architecture that gives software developers complete access to the performance, efficiency, and capabilities of Radeon™ GPUs and multi-core CPUs.

Compared to OpenGL, Vulkan™ substantially reduces “API overhead” – the background work a CPU does to interpret what a game asks of the hardware – to deliver meaningful features, performance, and image quality and expose GPU hardware features that wouldn’t ordinarily be accessible through OpenGL.
www.amd.com/en-us/innovations/software-technologies/technologies-gaming/vulkan

And on Wiki
en.wikipedia.org/wiki/Vulkan_(API)

efikkanUnexpected how? So benchmarks are bad because they don't show the "expected" advantages for AMD? That's the same stupid excuse we heard when the Time Spy benchmark was released and all the fanboys dismissed it because AMD was not superior in it.

If all the benchmarks should be optimized for AMD hardware, then we are no longer benchmarking the same thing any more.

If a Game Benchmark, does not properly recognize or utilize AMD's GCN for example, it will most likely give wrong results. Just like games, they need to be optimize to take advantage of the hardware. I believe Nvidia has a handle on this, but there way of handling it is more or less Bully tactics. IMO

These type of benchmarks (Synthetic I believe) are very important in keeping a "Standard" in place for measuring performance. It's not set in stone, because you will probably get different results in real world gaming, but at least it gives you an idea from one GPU to another GPU. Perhaps somebody else can explain it better.

FordGT90ConceptVulkan is AMD's baby (built off of Mantle). Vulkan should get better frame rates than D3D12 because of less hand holding. GeForce is expected to get about equal or slightly better performance on Vulkan than D3D12. Even so, GTX 1060's result appears like an outlier much like Radeon; it could be explained by memory though (D3D12 may use > 6 GiB where Vulkan can stay < 6 GiB). Radeon seeing better performance in D3D12 than Vulkan is a completely unexpected result.

Based on DOOM PC, for me anyway, I've gained a huge performance advantage when enabling Vulkan. I also noticed a bit better texture quality. Though I enabled it half way through the game because I didn't even know it was offered lol.

FordGT90ConceptVulkan is AMD's baby (built off of Mantle). Vulkan should get better frame rates than D3D12 because of less hand holding. GeForce is expected to get about equal or slightly better performance on Vulkan than D3D12. Even so, GTX 1060's result appears like an outlier much like Radeon; it could be explained by memory though (D3D12 may use > 6 GiB where Vulkan can stay < 6 GiB). Radeon seeing better performance in D3D12 than Vulkan is a completely unexpected result.

You should start by learning the facts before you make such ridiculous claims.
Vulkan is based on SPIR-V, which was developed for OpenCL, which has absolutely nothing to do with Mantle. Vulkan applied a similar API syntax from Mantle. But since the underlying API is completely different, AMD had to write their driver from scratch just like everyone else. AMD were in fact the last of the three vendors to release a driver.

All of these assumptions of yours about performance of AMD vs. Nvidia is nonsense, there is nothing inherently favoring AMD in the design of Vulkan.

And one thing is for certain, this is an API overhead benchmark, memory has nothing to do with it.(facepalm)

FordGT90ConceptExcept that optimization is the norm. It must be because something as simple as a buffer being different sizes in the hardware can beget very different results in performance running the same software.

The purpose of the benchmark is to measure the overhead of the respective APIs, optimization for each GPU is not even relevant.

Super XPIf a Game Benchmark, does not properly recognize or utilize AMD's GCN for example, it will most likely give wrong results. Just like games, they need to be optimize to take advantage of the hardware. I believe Nvidia has a handle on this, but there way of handling it is more or less Bully tactics. IMO

That's not how the graphics APIs work. The whole point is that the drivers for the various GPU architectures implement a common interface, so games don't have to be written over from scratch for every new architecture.

Super XPBased on DOOM PC, for me anyway, I've gained a huge performance advantage when enabling Vulkan. I also noticed a bit better texture quality. Though I enabled it half way through the game because I didn't even know it was offered lol.

That's OpenGL versus Vulkan though. ID Software has pushed OpenGL since forever.

efikkanVulkan is based on SPIR-V...

www.pcworld.com/article/2894036/mantle-is-a-vulkan-amds-dead-graphics-api-rises-from-the-ashes-as-opengls-successor.html
Vulkan is the API which is foundationally Mantle.

www.khronos.org/assets/uploads/developers/library/2015-gdc/Khronos-Vulkan-GDC_Mar15.pdf Page 4
SPIR-V is the shader language which is designed to run on Vulkan and OpenCL 2.1

efikkanThe purpose of the benchmark is to measure the overhead of the respective APIs, optimization for each GPU is not even relevant.

Will have to agree. AMD donated Mantle to Khronos. So ya, Vulkan is the API which is foundationally Mantle

Seriously, FordGT90Concept, get your act together.

If you even bothered to read the link I sent you:

In all Futuremark benchmarks we aim for neutrality by ensuring that all hardware is treated equally. Every device runs the same workload using the same code path. This is the only way to produce results that are fair and comparable.

In the past, we have discussed the option of vendor-specific code paths with our development partners, but they are invariably against it. In many cases, an aggressive optimization path would also require altering the work being done, which means the test would no longer provide a common reference point. And with separate paths for each architecture, not only would the outputs not be comparable, but the paths would be obsolete with every new architecture launch.

3DMark benchmarks use a path that is heavily optimized for all hardware. This path is developed by working with all vendors to ensure that our engine runs as efficiently as possible on all available hardware. Without vendor support and participation this would not be possible, but we are lucky in having active and dedicated development partners.

Claiming Vulkan is based on Mantle because some functions have similar syntax is just as ridiculous as claiming Chrome is based on Firefox for implementing similar features.

Vulkan is based on SPIR-V, which is the latest iteration of SPIR, which was designed for OpenCL, which has nothing to do with Mantle. The syntax of a few functions in an API doesn't matter how it will behave, but the underlying architecture compiling the code which will run on the GPUs does.

Super XPQUOTE:
1) Vulkan™ supports close-to-metal control enabling faster performance and better image quality across Windows® 7, Windows® 8.1, Windows® 10, and Linux®. No other graphics API offers the same powerful combination of OS compatibility, rendering features, and hardware efficiency.

2) Developed by the Khronos Group, the same consortium that developed OpenGL®, Vulkan™ is a descendant of AMD’s Mantle, inheriting a powerful low-overhead architecture that gives software developers complete access to the performance, efficiency, and capabilities of Radeon™ GPUs and multi-core CPUs.

Compared to OpenGL, Vulkan™ substantially reduces “API overhead” – the background work a CPU does to interpret what a game asks of the hardware – to deliver meaningful features, performance, and image quality and expose GPU hardware features that wouldn’t ordinarily be accessible through OpenGL.
www.amd.com/en-us/innovations/software-technologies/technologies-gaming/vulkan

And on Wiki
en.wikipedia.org/wiki/Vulkan_(API)

You do realize the above doesn't say Vulkan is "better" than DX12, don't you? It says it's "better" than OpenGL. And it's just marketing speech, not something that translates literally into the real world.
Yes, Vulkan is available on more platforms, but that's the only advantage we know. Everything else is still up for grabs.

bugYou do realize the above doesn't say Vulkan is "better" than DX12, don't you? It says it's "better" than OpenGL. And it's just marketing speech, not something that translates literally into the real world.
Yes, Vulkan is available on more platforms, but that's the only advantage we know. Everything else is still up for grabs.

Fair Enough.

With regards to Mantle & Vulkan.
Vulkan evolved from Mantle. We know that Mantle's code was donated towards developing Vulkan. We also know Mantle pushed Micro$oft to develop DX12.

Had AMD not created Mantle, DX12 and Vulkan today would be different. Such as missing the low level API features.

bugYou do realize the above doesn't say Vulkan is "better" than DX12, don't you? It says it's "better" than OpenGL. And it's just marketing speech, not something that translates literally into the real world.
Yes, Vulkan is available on more platforms, but that's the only advantage we know. Everything else is still up for grabs.

Well there is one major difference, Vulkan, like OpenGL, are C APIs, which gives the developer more freedom.

Super XPHad AMD not created Mantle, DX12 and Vulkan today would be different. Such as missing the low level API features.

Both AZDO and the initial work which lead to Direct3D 12 predates Mantle. Mantle was a side experiment from AMD, nothing more.

efikkanIf you even bothered to read the link I sent you:

And as I said, there's bias in the foundation of their approach. The bias not only comes through with Futuremark's D3D12 versus D3D11, it also comes through with Futuremark's Vulkan versus D3D12.

efikkanClaiming Vulkan is based on Mantle because some functions have similar syntax is just as ridiculous as claiming Chrome is based on Firefox for implementing similar features.

Not claiming, is. It's very well documented with over a dozen sources reporting on it back in March of 2015.

efikkanVulkan is based on SPIR-V, which is the latest iteration of SPIR, which was designed for OpenCL, which has nothing to do with Mantle. The syntax of a few functions in an API doesn't matter how it will behave, but the underlying architecture compiling the code which will run on the GPUs does.

efikkanBoth AZDO and the initial work which lead to Direct3D 12 predates Mantle. Mantle was a side experiment from AMD, nothing more.

I have to respectfully disagree. Based on Anantech and other various sites.

AMD's Mantle was highly Innovative. Accessing the GPU like never before. Genius. AMD deserves credit for the creation of Vulkan and DX12.

Quote:
AMD's Robert Hallock confirmedon a blog post that Mantle had, for the most part, been turned into the Khronos Group’s Vulkan API that would supersede OpenGL.
www.pcworld.com/article/2894036/mantle-is-a-vulkan-amds-dead-graphics-api-rises-from-the-ashes-as-opengls-successor.html

Mantle was co-developed with DICE.

Pretty likely that Microsoft was working on Direct3D 12 in 2013 because Microsoft didn't want anything to do with Mantle.

FordGT90ConceptAnd as I said, there's bias in the foundation of their approach. The bias not only comes through with Futuremark's D3D12 versus D3D11, it also comes through with Futuremark's Vulkan versus D3D12.

Stop with your nonsense. There is no evidence of bias in the benchmark, just your bias in refusing to accept the results.

Super XPI have to respectfully disagree. Based on Anantech and other various sites.

AMD's Mantle was highly Innovative. Accessing the GPU like never before. Genius. AMD deserves credit for the creation of Vulkan and DX12.

Quote:
AMD's Robert Hallock confirmed on a blog post that Mantle had, for the most part, been turned into the Khronos Group’s Vulkan API that would supersede OpenGL.
www.pcworld.com/article/2894036/mantle-is-a-vulkan-amds-dead-graphics-api-rises-from-the-ashes-as-opengls-successor.html

It's not really a matter of opinion, but facts. As Nvidia themselves states, "Our work with Microsoft on DirectX 12 began more than four years ago with discussions about reducing resource overhead.", which makes it 2010, way before Mantle. APIs are always planned before the GPUs are designed, and the Direct3D 12 GPUs were in early development in 2011.

Vulkan started as AZDO, then "glNext", then Mantle arrived and was used as input to finalize the API frontend. There is no denying Mantle was useful input, providing cleaner syntax, but the groundwork started way before Mantle. Just look at the AZDO features in the OpenGL registry which happened for years before, as those of us familiar with this technology already know ;)

Khronos threw away virtually everything they were working on when AMD dropped Mantle on their lap. Mantle provided Khronos a clear path forward. Khronos then went to work adding functionality that OpenGL has on top of Mantle to ease developer transition.

I found some info about DX12, Mantle etc., Based on what I found out, DX12 at the time was not going to be ready for prime time for at least 2 years, so AMD released Mantle in 2013. etc., AMD was also a part of all DX12 development, and was intimately familiar with the API details & requirements. etc.,
Anyhow, here you go, and please we are not here to argue and get frustrated. This is a discussion and a friendly debate.

DirectX 12 was announced by Microsoft at GDC on March 20, 2014, and was officially launched alongside Windows 10 on July 29, 2015.
* The release of Direct3D 12 comes alongside other initiatives for low-overhead graphics APIs including AMD's Mantle for AMD graphics cards,
en.wikipedia.org/wiki/DirectX#DirectX_12


QUOTE:
* While AMD's Raja Koduri was on-hand to say that DirectX 12 and Direct3D 12 was like "getting four generations of hardware ahead," the technology may have never seen the light of day without AMD's goading. After securing deals to create the PlayStation 4 and Xbox One's hardware, the company unveiled Mantle—a new set of console-like application programming interfaces designed to give game developers more direct access to PC hardware, and thus, boost graphics performance.
* Mere weeks later, here we are, and at first blush DirectX 12 appears awfully similar to Mantle. (That's what happens when you poke the bear!)
www.pcworld.com/article/2109596/directx-12-vs-mantle-comparing-pc-gamings-software-supercharged-future.html

* Microsoft hints that DirectX 12 will imitate Mantle, but AMD insists its API has a bright future
QUOTE:
We’ve spoken to several sources with additional information on the topic who have told us that Microsoft’s interest in developing a new API is a recent phenomenon, and that the new DirectX (likely DirectX 12) will substantially duplicate the capabilities of AMD’s Mantle. The two APIs won’t be identical — Microsoft is doing its own implementation — but the end result, for consumers, should be the same: lower CPU overhead and better scaling in modern titles.
www.extremetech.com/gaming/177407-microsoft-hints-that-directx-12-will-imitate-and-destroy-amds-mantle

Microsoft DirectX 12 is DirectX 11 with Mantle Integrated
* The delightfully controversial SemiAccurate.com has just revealed that DirectX12 is nothing more than DirectX11 with Mantle API shamelessly integrated.
wccftech.com/microsoft-directx-12-mantle-integrated-performance-boost-xbox-questionable/

Microsoft adopts Mantle but calls it DX12
* Just as SemiAccurate predicted months ago, Microsoft has adopted AMD’s Mantle but are now calling it DX12.
semiaccurate.com/2014/03/18/microsoft-adopts-mantle-calls-dx12/

Even AMD was promoting Direct X12, of course they were, because they know full well, they cannot compete with Microsoft in this manner, so AMD was once again forced to "INNOVATE" and STEER this PC Gaming industry in the right direction. That is with MANTLE.
www.amd.com/en-us/innovations/software-technologies/directx12

AMD Says the Future of Mantle is DX12
www.fudzilla.com/news/graphics/37160-amd-says-the-future-of-mantle-is-directx-12

New Reports Claim Microsoft's DirectX Rips Off Mantle, Won't Help Xbox One -- But Is It True?
Read more at hothardware.com/news/new-reports-claim-microsofts-directx-rips-off-mantle-wont-help-xbox-one--but-is-it-true-#LrT9QDGbQ8HrB9oc.99
hothardware.com/news/new-reports-claim-microsofts-directx-rips-off-mantle-wont-help-xbox-one--but-is-it-true-

Look at the dates on the last half of those: Mantle and D3D12 have little in common other than being closer-to-the-metal.

APIs take a long time to develop and they announced D3D12 in 2014 and announced they had no intention to support Mantle in 2013. I think efikkan's guess of 2010 is plausible but only Microsoft knows when D3D12 became more than idea. That said, Mantle went from theory to practice pretty fast.

Super XPFair Enough.

With regards to Mantle & Vulkan.
Vulkan evolved from Mantle. We know that Mantle's code was donated towards developing Vulkan. We also know Mantle pushed Micro$oft to develop DX12.

Had AMD not created Mantle, DX12 and Vulkan today would be different. Such as missing the low level API features.

Low level has been a thing on consoles for a while. I think there's a good chance it would have found its way to PCs anyway. Still, while low level has worked fine for consoles where you only need to deal with a handful of configurations, one year later it still remains to be seen if it's as useful on PCs.

efikkanWell there is one major difference, Vulkan, like OpenGL, are C APIs, which gives the developer more freedom.

I hope you're not opening up the C vs C++ can of worms :D
The language makes little difference, the development and testing tools is where it's at. Traditionally, DX held the upper hand, because Khronos handles neither of those, while Microsoft provided integration with Visual Studio. At the same time, DX also offered other goodies when it came to gaming like handling of input and sound (remember the time when people where confused about having to install the latest DX for Doom3, despite Doom3 being an OpenGL title?).

Rome wasn't built in one day, neither are multi-vendor APIs. APIs go through several stages, the initial feature planning of what lead to Direct3D 12 was done in 2010, like Nvidia refers to. This has to start before the design of the GPU architectures which are going to support it. AMD and Nvidia didn't end up with many similar GPU features by accident. This has been the procedure for every Direct3D version since the mid 90s. Big features are rarely added later, but sometimes they get removed. E.g. in Direct3D 10 tessellation was planned, but AMD and Nvidia failed to reach consensus in time, so it was postponed until Direct3D 11. AMD did however release it as an extension, and did provide working demos.

bugLow level has been a thing on consoles for a while. I think there's a good chance it would have found its way to PCs anyway. Still, while low level has worked fine for consoles where you only need to deal with a handful of configurations, one year later it still remains to be seen if it's as useful on PCs.

It has gradually happened in OpenGL for years, and it was planned for Direct3D 12 from the beginning. It's not a new invention.

But as always, with great powers comes great responsibilities; finer control of memory allocations etc. requires more effort from the developers, so sloppy coding can result in "disasters". Personally, I would want more control over the pipeline, and more features in the shaders, enabling me to build a different rendering pipeline more optimized for whatever I need.

bugI hope you're not opening up the C vs C++ can of worms :D
The language makes little difference, the development and testing tools it's where it's at.

I'm not referring to the language, but the fact that OpenGL and Vulkan is not object oriented, which makes much more sense since all these APIs are state machines. With OpenGL and Vulkan you are free to encapsulate it if you want, but you don't have to.

efikkanI'm not referring to the language, but the fact that OpenGL and Vulkan is not object oriented, which makes much more sense since all these APIs are state machines. With OpenGL and Vulkan you are free to encapsulate it if you want, but you don't have to.

My god, someone gets it! It's a freaking festivus miracle!

In fact, most workloads that can be reduced to functional transforms prove to be easier to run in parallel or pipelined as a series of functional transforms or even better, a combo of the two, a pipeline of functional transforms where individual steps can be further run in parallel. This is how you squeeze every drop of multi-core performance out of any workload. It's also is easier to test and figure out what the hell was going on when you try to debug it.