View Full Version : Nvidia scandal with Async Compute support (DX12)


NikosD
3rd September 2015, 13:42
Nvidia refuses to reply officially but the truth is there and should be uncovered fully.

Nvidia DX12 cards, even latest Maxwell 2.0, do not support Async shaders in HW.

Fermi, Kepler and Maxwell 1.0 don't support Async shaders at all and Maxwell 2.0 supports that feature using software scheduling, which means practically is not supported.

DX12 games are not ready yet in quantities to see how much gain could give this feature to AMD GCN 1.x-only cards, but from the well-known game benchmark the gain is huge.

Maybe Pascal could change that, but as it is right now the AMD GCN card owners, should be more than happy.

http://wccftech.com/nvidia-amd-directx-12-graphic-card-list-features-explained/4/

baii
3rd September 2015, 19:35
real life result is what matters though.

NikosD
4th September 2015, 13:31
real life result is what matters though.

The game - benchmark is pure real life.

The actual game shares its game engine with the benchmark.
It's just one game till now.

Don't expect the situation to change a lot though with other games.

NikosD
6th September 2015, 07:00
At last!

The scandal of Nvidia tactics regarding Async Compute and the pressure to developers to cover it, has been uncovered broadly to a wider extent than the original Async Compute scandal.

"Given its growing market-share, NVIDIA could use similar tactics to keep game developers away from industry-standard API features that it doesn't support, and which rival AMD does. NVIDIA drivers tell Windows that its GPUs support DirectX 12 feature-level 12_1. We wonder how much of that support is faked at the driver-level, like async compute. The company is already drawing flack for using borderline anti-competitive practices with GameWorks, which effectively creates a walled garden of visual effects that only users of NVIDIA hardware can experience for the same $59 everyone spends on a particular game."

http://www.techpowerup.com/215663/lack-of-async-compute-on-maxwell-makes-amd-gcn-better-prepared-for-directx-12.html

Sulik
6th September 2015, 07:53
That "scandal" is a whole bunch of noise over not much IMO - unrelated to HEVC decoding in any case - you come across with a bit of an anti-NVidia agenda FWIW (You work for Intel or something ?).

P.J
6th September 2015, 09:52
It's soon to discuss about DX12. We should blame Microsoft first x)
And since I know, it does nothing with DXVA :)

NikosD
6th September 2015, 10:12
You clearly have misunderstood something.

DX12 is a brand new low level and real multi-threaded API like Mantle and OpenGL Vulcan or Apple's Metal.

It is more than clear that Nvidia wasn't expecting or didn't manage to stop this evolution on the PC graphics and their GPUs are still optimized for DX11, which is not low level or real multi-threaded.

So, for the first time in recent GPU history, AMD GCN cards (from late 2011 onwards) can really expose the power of their HW which can be leveraged more efficiently than ever by ALL low - level APIs like DX12 and Vulcan.

So, for the first time in recent history, AMD cards are more future - proof and a lot better value - for - money than Nvidia cards.

In just one day, July 29th of 2015, with the official release of Win10 and DX12, things turned over and AMD is on top again.

We are here to watch Nvidia struggling with Marketing (money), Blackmails (money), Media (money) to change the picture like Intel tried to with the release of AMD Athlon back on 1999.

That's why I like AMD.

A small company fighting with the giants.

nevcairiel
6th September 2015, 10:16
The techpowerup article is just a rehash of the Oxide Async Compute thing, I don't see how its anything new or "uncovered broadly to a wider extent than the original Async Compute scandal"
Funny enough everytime it gets re-hashed, it presents the situation slightly differently. Need to draw readers, I guess?

I don't even understand how people make everything a scandal these days.
So NVIDIA emulates one DX12 feature in software - thats not forbidden, and unless they explicitly stated the opposite, also not worth a scandal.

Performance numbers of actual games in the future will determine the merit of which card to buy, not theoretical feature limitations and so-called "scandals".
If this feature is so important, than performance will show it on DX12 titles (once we have more than one single benchmark), and that alone should be a driving factor.

NikosD
6th September 2015, 10:26
You have to read again the paragraph I quoted here.

What it's been uncovered, is a pressure of Nvidia to cover the "cheat" of the driver exposing Async Compute which is not implemented yet.

The reason of not implemented is because it is based on SW scheduling and other slow SW processes that AMD supports in HW.

Nvidia tried to attack by saying that activating Async Compute is a biased move with code specifically written for AMD (!)

What a lie (!).
It's exactly the opposite.

Nvidia demanded to remove Async Compute code when running on their HW because although it was exposed by the driver it wasn't implemented.

Now, read again the last paragraph and remember the 4GB RAM-gate of 970.

Nvidia is FULL OF LIES.

NikosD
6th September 2015, 10:39
The techpowerup article is just a rehash of the Oxide Async Compute thing, I don't see how its anything new or "uncovered broadly to a wider extent than the original Async Compute scandal"
Funny enough everytime it gets re-hashed, it presents the situation slightly differently. Need to draw readers, I guess?

I don't even understand how people make everything a scandal these days.
So NVIDIA emulates one DX12 feature in software - thats not forbidden, and unless they explicitly stated the opposite, also not worth a scandal.

Performance numbers of actual games in the future will determine the merit of which card to buy, not theoretical feature limitations and so-called "scandals".
If this feature is so important, than performance will show it on DX12 titles (once we have more than one single benchmark), and that alone should be a driving factor.

I don't want to change anything on my previous post because it was written before you complete your post and had already replied why it was A REAL SCANDAL before you ask !

I have to become an Oracle after all.

nevcairiel
6th September 2015, 10:45
Everything on the internet is a scandal these days.
Next year when DX12 becomes actually relevant, people will buy whatever GPU is the fastest, and if by chance thats going to be NVIDIA, noone is going to care anymore.

NikosD
6th September 2015, 10:54
No, not everything on the Internet is a scandal these days.

REAL SCANDALS can spread faster due to internet when they are uncovered.

What is going to happen next year, let next year to worry about.

We are talking about today that Nvidia did lie again about their HW capabilities which are lower than expected and missing from their drivers although exposed by them (!) and that AMD cards are better suited for low - level APIs like DX12 and Vulcan.

All GCN graphics cards owners should be more than happy for their buy regarding DX12 games, in clear contrast with the Nvidia cards owners regarding value-for-money and DX12 games.

Sulik
6th September 2015, 18:51
Real-life performance in the applications you're using is what matters - obviously HW manufacturers make different design tradeoffs, and it's way too early to speculate about which will work out best. Focusing on one specific feature may expose these differences, but is meaningless.
AMD & NVidia are in the same boat, the real competition is Intel, slowly eating away at their GPU pie (and from the looks of it, AMD may very well go bankrupt within a year or two - I'd worry about that more than truly-async vs pseudo-async compute :)).

NikosD
6th September 2015, 18:58
The problem for Nvidia is that Async Compute is not just a "feature"

Nvidia has to redesign the whole GPU architecture in order to support it.
It has to change fundamentally the way that their GPUs work.

There is a chance that not even Pascal, their next generation GPU will support that "feature" in the degree that AMD does.

That's a good thing because AMD sells cards to consoles, that's why changed to GCN architecture and low-level API support, but has less than 20% of discrete cards in PC market.

Time to rise that percentage ;)

NikosD
6th September 2015, 19:05
But in order to not go off - topic, Nvidia first has to change its attitude against its rival AMD, developers, reviewers and eventually customers and potential customers.

Nvidia must stop telling SO MUCH LIES and treats everyone like their own pets.

It must stop cheating in benchmarks, accusing the others for doing that and stop forcing developers to support their products only, like it is the only IHV in graphics cards.

DX12 proved that the other company - AMD - has faster and better products regarding value-for-money than the greedy Nvidia.

nevcairiel
6th September 2015, 19:40
One of the Oxide developers, Kollock, has posted a few more information. He now says that NVIDIA is not done with Async Compute support in their drivers yet, and they (Oxide) are working with NVIDIA to get the driver part of that done, before its properly enabled in the driver.
Until a driver actually enables that feature properly, everything else is just speculation. Today, it cannot use the Async Warp Schedulers on the Maxwell GPU - but if the driver support is finished, the picture may be quite different.

Software scheduling may be less efficient than full hardware, but its not "no support", and until we see how the end result looks, i'll keep an open mind, in any case.

Summary here:
http://www.guru3d.com/news-story/nvidia-will-fully-implement-async-compute-via-driver-support.html

NikosD
6th September 2015, 19:59
Yes, after the "outing" in a world scale, Nvidia has started to act like it understands the situation, more "normally", accepting the facts.

But in the beginning Nvidia accused the developers that they made specific optimizations for AMD and not Nvidia.

The truth is this:

The developer tried to enable a feature exposed by the driver of Nvidia - Async Compute - and as he describes the situation he saw Dante's hell or the signs of Apocalypse.

He told Nvidia what happened and they replied "don't use that feature" although was clearly exposed by the driver.

He did that for Nvidia but of course he couldn't/ shouldn't do the same thing for AMD because AMD supports it properly as a basic performance feature of DX12.

And suddenly after the low results of Nvidia and the high results of AMD, Nvidia accused the developer of biased code because he used a DX12 feature that Nvidia CAN'T use due to its architecture and AMD CAN use due to its own architecture.

Nvidia lied:

1) In their drivers and their product marketing and the specifications and the potential customers that they can do Async Compute right here, right now.

They probably thought that nobody would use it, right here right now so nobody would discover the fraud.

2) To the developer that it's OK to not use that feature but then it accused him for biased code, because he didn't use that nonexistent feature.

and

3) Is totally responsible if after the 4GB memory - gate and that fake Async Compute feature enabled in the drivers, people starts to believe that their products are different, with lower performance than advertised.

As I read in various forums and sites there is a wave of buyers of Nvidia cards asking for the money back, because of the lack of that feature which gives a HUGE performance boost to GCN AMD cards and they thought they would get it too.

jones1913
6th September 2015, 20:00
Until a driver actually enables that feature properly, everything else is just speculation.
That was the problem: The nvidia driver reported the async compute capability but when oxide enabled that feature then the performance was worse.


Apart from that Nvidia has a long history lying to their customers, but their sales shows: Customers are very forgetful or dont care.

2015: incorrect informations about directx 12 feature levels of maxwell
2015: GTX970 ... you know it :rolleyes:
2012: incorrect informations about directx 11.1 capability of kepler chips
2011: incorrect informations about tegra 3 performance
2010: fermi wood dummy
2008: lots of bricked laptops with G84 und G86 chips
2001: incorrect informations in a comparisation geforce 2/3 with kyro II

- sabotages the performance of competitors with gameworks software (eg. disable physics hardware support if secondary AMD card is detected)
- selling expensive g-sync modules to display manufacturers which mostly act as drm blackbox
- were the first who introduced excessive rebranding (8800GT/2007 -> 9600GSO/2008 -> GTS150/2009 -> GTS240/2009 -> GT330/2010)
- driver cheating in some 3d benchmarks

But I am not forgetful in this respect, and try to avoid buying products from such companies.

*Dont ask me for sources of these allegations, google show all this with a few clicks.

foxyshadis
7th September 2015, 08:40
But in order to not go off - topic,

*snort*

Apart from that Nvidia has a long history lying to their customers, but their sales shows: Customers are very forgetful or dont care.

Although they've pulled some shenanigans, like everyone else, I still think most of it is just their developers (hardware and software) being wildly over-optimistic about what they can do, and not testing nearly enough. In fact, "We don't test" should be the motto of all the big GPU makers, right after "We don't listen to you." But AAA games still sell, and performance and capabilities do improve, so I guess that's something.

pandy
9th September 2015, 09:52
Anyway i'm forced to buy NVidia as AMD ignoring completely video - NVENC can't be compared to AMD solution...

huhn
10th September 2015, 10:48
wasn't AMD VCE even better than nvenc?

and what is the need for this encoder in the first place?
i wouldn't be shocked if quicksync from broadwell or skylake would be even better than both.

stax76
10th September 2015, 11:19
Since GPU encoding is somehow popular among StaxRip users I can share some experience. AMD made some announcement to one of a recent or upcoming APU architecture that encoding was improved and that it will be available in Handbrake. The handbrake dev team was surprised not being contacted beforehand. StaxRip supports the CLI tools QSVEncC and NVEncC by Japanese programmer rigaya for Intel and NVIDIA H.264 and H.265 encoding, there don't seem to be a CLI tool for AMD, I believe both Intel and NVIDIA have a basic CLI tool in the SDK which rigaya used as starting point, it don't look like AMD has such a tool in the SDK. I made only few HEVC test encodes with my Skylake CPU and QSVEncC, my first impression is it don't look like a great improvement over previous hardware encoders.

NikosD
10th September 2015, 11:44
The two CLI programs coming from the same developer - rigaya - clearly show that the amount of investment and the difference between Nvidia and Intel is huge.

The Nvidia HW encoders have 1/10 of the capabilities of Intel HW encoders and of course they are slower too, like their HW decoders.

Intel's HW encoders are not only faster and with a lot more options available for encoding, e.g they support B frames and other quality options making them a lot better in quality for the same bitrate compared to Nvidia encoders which lack B frames support.

ashlar42
10th September 2015, 11:52
NikosD, nevacairiel got it right. No matter how you wish for something else to matter, the only relevant thing is performance in real applications (AKA games). That, price, noise, energy efficiency. And on the engineering point of view, AMD has been a disgrace to itself for far too long. That's in performance over power usage for the past... how many years? Entirely too many. And it's not a good thing for gamers/users, Nvidia surely could use more competition than what AMD is offering.

NikosD
10th September 2015, 11:56
NikosD, nevacairiel got it right. No matter how you wish for something else to matter, the only relevant thing is performance in real applications (AKA games)

You obviously didn't read the results of DX12 game - benchmark which AMD beats Nvidia for fun.

So, yes because performance in real games matter, that's why Nvidia is 2nd and AMD is first regarding DX12 gaming performance.

huhn
10th September 2015, 16:32
The two CLI programs coming from the same developer - rigaya - clearly show that the amount of investment and the difference between Nvidia and Intel is huge.

The Nvidia HW encoders have 1/10 of the capabilities of Intel HW encoders and of course they are slower too, like their HW decoders.

Intel's HW encoders are not only faster and with a lot more options available for encoding, e.g they support B frames and other quality options making them a lot better in quality for the same bitrate compared to Nvidia encoders which lack B frames support.

i wonder what this option does in the NVENC encoder.

-numB <integer> : Specifies the number of B frames

NikosD
10th September 2015, 16:51
i wonder what this option does in the NVENC encoder.

-numB <integer> : Specifies the number of B frames
I have really lost counting the number of times telling you to not dare to comment me.

But you are a brave man and you dare to expose one more time your huge size of ignorance and misunderstanding.

So, because you saw a setting you thought it works and you decided it was time to prove me wrong (once again)

And once again you are wrong because you just don't learn from so many lessons I have given you for free.

But you should have known from Nvidia that it is doing cheats and tricks and exposes features that it doesn't support.

Don't you read above the lie regarding Async Compute support ?

Why don't you learn from Nvidia if you don't want to learn from me ?

Read here with a translation why Nvidia is lying again about B frames support.

http://rigaya34589.blog135.fc2.com/blog-entry-570.html

Sulik
10th September 2015, 16:56
Read here with a translation why Nvidia is lying again about B frames support.
http://rigaya34589.blog135.fc2.com/blog-entry-570.html

The above link referring to B-frames with HEVC. Intel doesn't even have any HEVC encoding support.
Seems like another case of wishful thinking on your part...

huhn
10th September 2015, 16:57
have you read it your self. NVENC isn't made for HEVC only.

NikosD
10th September 2015, 16:59
The above link referring to B-frames with HEVC. Intel doesn't even have any HEVC encoding support.
Seems like another case of wishful thinking on your part...
Oh man...More huhns around.

Have you heard of Skylake and a program called QSVEncC ?

They both have one common.

They support HEVC on Intel's HW

jones1913
10th September 2015, 17:03
Although they've pulled some shenanigans, like everyone else, I still think most of it is just their developers (hardware and software) being wildly over-optimistic about what they can do, and not testing nearly enough.
I dont think so, I blame the management. Remember who held up the fermi dummy? The CEO himself.

Anyway i'm forced to buy NVidia as AMD ignoring completely video - NVENC can't be compared to AMD solution...
Ignoring completely? No. But afaik the software/driver support on AMD side is not as good as at Nvidia or Intel, and therefore less external developers are interested in coding for AMD hardware.

there don't seem to be a CLI tool for AMD, I believe both Intel and NVIDIA have a basic CLI tool in the SDK which rigaya used as starting point, it don't look like AMD has such a tool in the SDK.
Sample CLI applications exist in the AMD Media SDK. Maybe it would be not much work for a talented c++ dev to build a usable cli tool from that.
If I could program c++, then I would try it. But I cant. :(

huhn
10th September 2015, 17:12
Sample CLI applications exist in the AMD Media SDK. Maybe it would be not much work for a talented c++ dev to build a usable cli tool from that.
If I could program c++, then I would try it. But I cant. :(

there is already an program that uses AMD VCE.

https://obsproject.com/forum/threads/obs-branch-with-amd-vce-support.13996/

i don't think an CLI program would be as hard as this.

@NikosD

still waiting for your source that says NVENC can't use b frames.

NikosD
10th September 2015, 17:20
I replied to Stax76 about his dissatisfaction of HEVC encoding on Intel.

I told him that with Nvidia the things are even worse, because it supports a lot less features and QSVEncC has a ton more options for encoding and Intel's HW is faster and with better quality than Nvidia e.g Nvidia doesn't support B frames.

The rest are English and translated Japanese.

jones1913
10th September 2015, 17:39
there is already an program that uses AMD VCE.

https://obsproject.com/forum/threads/obs-branch-with-amd-vce-support.13996/

i don't think an CLI program would be as hard as this.

Yeah I know :), same developer made a VCE VFW codec (OpenEncodeVFW (https://github.com/jackun/openencodevfw) and successor AMFVFW (https://github.com/jackun/TestAMFVFW)).
But a cli tool with avisynth support would be more useful for most people here.

huhn
10th September 2015, 17:43
and now i would like you to read your own post again...

http://forum.doom9.org/showpost.php?p=1738083&postcount=27

so NVENC with HEVC didn't make use of B frames and every thing i saw about it was terrible. but where do they lie?

should they remove the b frame this option on an encoder that does both AVC and HEVC and use the same commands as input?

the first thing that must be provided is the HEVC hardware encoder clearly better than there AVC encoder on the same produce. according to stax76 that's most likely not the case with intel so who cares if it is better than the NVENC HEVC encoder if AVC is the better choice anyway that can't beat x264.

huhn
10th September 2015, 17:44
Yeah I know :), same developer made a VCE VFW codec (OpenEncodeVFW (https://github.com/jackun/openencodevfw) and successor AMFVFW (https://github.com/jackun/TestAMFVFW)).
But a cli tool with avisynth support would be more useful for most people here.

shouldn't the VFW codec work for vdub and so with avisynth.

jones1913
10th September 2015, 18:08
shouldn't the VFW codec work for vdub and so with avisynth.
Yes it works of course. But a cli tool would be more convenient to use and can be integreated in GUIs.
With Virtualdub you can only save as avi (who wants that?) or use its unhandy external encoder feature.

ashlar42
10th September 2015, 18:49
You obviously didn't read the results of DX12 game - benchmark which AMD beats Nvidia for fun.

So, yes because performance in real games matter, that's why Nvidia is 2nd and AMD is first regarding DX12 gaming performance.
I guess we will see when real DX12 games start shipping in numbers.

If AMD finally would manage to provide real competition to Nvidia, it would only be good for consumers.

NikosD
10th September 2015, 18:53
Exactly.

NikosD
12th September 2015, 06:50
The Nvidia scandalous "support" of Async Compute is been investigated in further details by Beyond3D and Oveclock.net with various latency tests.

A summary of their results is presented by ExtremeTech and it very very interesting.

It seems that Nvidia can "support" it in a way that is more than 10 times (!) slower than AMD.

The hilarious fact that made me laugh is that Nvidia using Maxwell 2 was so slow during latency testing, that the OS (Windows) killed the Nvidia driver (!) because it thought it got stuck (!!), during the tests.

Oh Nvidia...What a funny, amusing company.

Read more here:
http://www.extremetech.com/extreme/213519-asynchronous-shading-amd-nvidia-and-dx12-what-we-know-so-far

nevcairiel
12th September 2015, 09:05
Why everyone is wasting so much time on testing a feature which has been confirmed broken/incomplete in the current drivers is beyond me. Hope they bother to re-do it properly once the driver arrives which is supposed to implement it fully.
Without all these tests it was known by now that Async Compute just isn't supported, even if the driver (erroneously?) claims otherwise.

NikosD
12th September 2015, 09:09
Hope they bother to re-do it properly once the driver arrives which is supposed to implement it fully.


Hahaha...You are so hilarious too..Thank you for the fun!

"which is supposed to implement it fully"

Hahaha hah....So funny, so funny!

Asmodian
14th September 2015, 17:46
Hahaha...You are so hilarious too..Thank you for the fun!

"which is supposed to implement it fully"

Hahaha hah....So funny, so funny!

What are you on about?

It is pretty obvious that Nvidia has Async compute broken in their drivers and we have no idea what performance will be once it isn't. "Implement fully" means make the drivers work, not implement a hardware scheduler.

Also the benchmark that started this all shows the Fury X matching the 980 Ti at 4K in DX12 so if Nvidia gets any performance benefits from enabling Async compute they should actually be faster.

DX12 is young and developers (both driver and game) are learning how to use it most effectively. We will have to wait for any real performance comparisons.

Don't forget the Nvidia only features. :p

huhn
14th September 2015, 19:40
What are you on about?

It is pretty obvious that Nvidia has Async compute broken in their drivers and we have no idea what performance will be once it isn't. "Implement fully" means make the drivers work, not implement a hardware scheduler.

Also the benchmark that started this all shows the Fury X matching the 980 Ti at 4K in DX12 so if Nvidia gets any performance benefits from enabling Async compute they should actually be faster.

DX12 is young and developers (both driver and game) are learning how to use it most effectively. We will have to wait for any real performance comparisons.

Don't forget the Nvidia only features. :p

a card with feature level of 12_1 doesn't mean it has more features then a feature level 12_0 it just means it has some or a feature from feature level 12_1 all in all AMD is supposed to have more dx 12 features than nvidia. but which and what feature really matters later is an another story.

Asmodian
15th September 2015, 05:23
a card with feature level of 12_1 doesn't mean it has more features then a feature level 12_0 it just means it has some or a feature from feature level 12_1 all in all AMD is supposed to have more dx 12 features than nvidia. but which and what feature really matters later is an another story.

True, I was simply saying we don't know yet and there are some features available in hardware on Nvidia that are not available on AMD, the same way some features are available in hardware with AMD and not with Nvidia.

As you say, we don't know which hardware features are the most important yet. I never mentioned 12_1 or 12_0. ;)

To be 12_1 you need to have all the features specified in 12_1, which includes all the features in 12_0. You can have extras, of course. The odd thing is that Async compute is not in any directX feature level.

pandy
15th September 2015, 12:40
wasn't AMD VCE even better than nvenc?


Not aware of this - seem that AMD not even as important to provide clear information how to use and integrate HW functionality - opposite to NVidia where even mediocre HW provide good SW support.


and what is the need for this encoder in the first place?
i wouldn't be shocked if quicksync from broadwell or skylake would be even better than both.

I need to encode h.265 4k 50 fps in real time - quality is not important.
AFAIK Intel QSV doesn't provide such level of performance (Intel says that perhaps newest Xeon will be capable to provide 4k h.265 30fps realtime).

Can't use anything else than h.265 as HW decoder will support 4k only as h.265...

The two CLI programs coming from the same developer - rigaya - clearly show that the amount of investment and the difference between Nvidia and Intel is huge.

The Nvidia HW encoders have 1/10 of the capabilities of Intel HW encoders and of course they are slower too, like their HW decoders.

Intel's HW encoders are not only faster and with a lot more options available for encoding, e.g they support B frames and other quality options making them a lot better in quality for the same bitrate compared to Nvidia encoders which lack B frames support.

Maybe but... NVEnc is supported currently better at ffmpeg (Intel QSV Enc was added last few weeks and there is no documentation to it except REI of source code).

Problem is that AFAIK Intel is slower than NVEnc... B frames are nice but... stream need to be encoded in realtime...

huhn
15th September 2015, 19:45
True, I was simply saying we don't know yet and there are some features available in hardware on Nvidia that are not available on AMD, the same way some features are available in hardware with AMD and not with Nvidia.

As you say, we don't know which hardware features are the most important yet. I never mentioned 12_1 or 12_0. ;)

To be 12_1 you need to have all the features specified in 12_1, which includes all the features in 12_0. You can have extras, of course. The odd thing is that Async compute is not in any directX feature level.

have a look at this: http://www.bitsandchips.it/52-english-news/5661-clarifications-about-tier-and-feature-levels-of-the-directx-12

In the end, as regards the support of every single capability, it is currently not possible, nor appropriate, to draw up a complete and well-defined table showing the support of on sale hardware.
Unless you name is AMD, INTEL or NVIDIA, you cannot present such report with the drivers currently available on the public channels, nor with non-NDA documentation, therefore everything else is only to be considered as pure rants.

NikosD
15th September 2015, 20:15
Maybe but... NVEnc is supported currently better at ffmpeg (Intel QSV Enc was added last few weeks and there is no documentation to it except REI of source code).

Problem is that AFAIK Intel is slower than NVEnc... B frames are nice but... stream need to be encoded in realtime...

Your whole post is fundamentally wrong.

QSV encoding had elementary support by FFMPEG more than a year ago using a fork for H.264 only, with a few basic rate control modes compatible with SandyBridge.

Latest official FFMPEG 2.8 version has a lot better support with more formats and options.

But this has nothing to do with QSV and its real capabilities.

QSV is leveraged fully by MediaSDK and software like QSVEncC is by far more advantaged by any FFMPEG version will ever be.

FFMPEG is useful as a complimentary tool of demux/mux not encoding.

MediaSDK can do both decoding/encoding perfectly.

Regarding speed, QSV is a lot faster than NVenc encoding H.264, I'm not sure about H.265.

For H.265 decoding, as you can see in my signature in HEVC decoding thread, Skylake QSV HEVC 8bit decoding is faster than Nvidia HEVC decoding.

I think the same is true for HEVC encoding.

NikosD
15th September 2015, 20:24
The posts regarding QSV, NVENC, VCE should not go on because they have nothing to do with Nvidia's scandal regarding Async compute.

Anyone interested in HW encoding should open a new thread.

Thanks.

Asmodian
15th September 2015, 22:29
have a look at this: http://www.bitsandchips.it/52-english-news/5661-clarifications-about-tier-and-feature-levels-of-the-directx-12

Right, I didn't say anything that contradicts that. We do know some of the features that are supported and some that are not but we don't know the complete list or how well they perform.

There are features that AMD does not support and there are features that Nvidia does not support.

To be feature level 12_1 you have to have all the features specified in feature level 12_1. That doesn't mean you have all the possible features because there are DX12 features not included in any feature level currently defined, e.g. async compute and tier 3 tiled resources.

Oddly, according to Microsoft (https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876%28v=vs.85%29.aspx), DX11.3 supports feature level 12_1.

I think it will be awhile before we really understand how the current hardware will perform with DX12. :(

nevcairiel
15th September 2015, 22:42
Oddly, according to Microsoft (https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876%28v=vs.85%29.aspx), DX11.3 supports feature level 12_1.


DX11.3 will get the new hardware features of DX12, but not the new API, and therefor not the CPU overhead reduction - but be available for older versions of Windows as well, while DX12 is not.

Well at least that was the plan. I haven't really heard if that ever came to be like that.

pandy
16th September 2015, 12:36
Your whole post is fundamentally wrong.


Well... this is your opinion, i've wrote about NVenc only to show that even if some aspects of 3D are not implemented there is sometimes no alternative solution to NVidia.
NVidia has long tradition to provide partially non working solutions and seem it is still better than other vendors.
Don't get me wrong - i am not NVidia fanboy.

P.J
24th September 2015, 18:20
Tie: http://anandtech.com/show/9659/fable-legends-directx-12-benchmark-analysis

NikosD
25th September 2015, 06:57
After reading the Anandtech's article regarding DX12 performance of Fable, from now on I will call that site "a disgusting piece of sh!t/ site" or ADPOS regarding the DX12 Nvidia scandal because of the two reasons that I copy here:

Reason 1

We tackled two synthetic tests earlier this year, Star Swarm and 3DMark, but due to timing and other industry events, we are waiting for a better time to test the Ashes of the Singularity benchmark as the game nears completion.


Reason 2

In fact, AMD sent us a note that there is a new driver available specifically for this benchmark which should improve the scores on the Fury X, although it arrived too late for this pre-release look at Fable Legends (Ryan did the testing but is covering Samsung’s 950 Pro launch in Korea at this time)


They are definitely in Nvidia's payroll.

NikosD
25th February 2016, 12:39
OK...Anandtech strikes again, this time with Ashes of the Singularity Revisited: A Beta Look at DirectX 12 & Asynchronous Shading here http://anandtech.com/print/10067/ashes-of-the-singularity-revisited-beta

Nvidia still looks ugly with that DX12 engine.

P.J
8th May 2016, 22:55
https://m.reddit.com/r/nvidia/comments/3j5e9b/analysis_async_compute_is_it_true_nvidia_cant_do/

NikosD
9th May 2016, 16:55
That's a funny article, actually an opinion, by a funny guy.

P.J
9th May 2016, 17:46
http://wccftech.com/nvidia-gtx-1080-asynchronous-compute/
http://www.overclock3d.net/articles/gpu_displays/gtx_1080_ashes_of_the_singularity_benchmarks/1

No idea tho' =/

P.J
16th May 2016, 20:16
http://www.eteknix.com/pascal-gtx-1080-async-compute-explored/

=/

NikosD
17th May 2016, 20:47
Pascal doesn't support hardware async shaders, it offers only an improvement on async computing over Maxwell.

It seems that Nvidia will still concentrate on how to make developers to not use async shaders, rather than implement it until next generation card appears.

littleD
22nd May 2016, 22:40
Another voice in the dx12/async shaders and all time gpu vendors battle https://scalibq.wordpress.com/2016/05/17/nvidias-geforce-gtx-1080-and-the-enigma-that-is-directx-12/
This is comment from developer, knowledgable guy. He usually stands on intel and nvidia side (which means he usually criticises amd) but posts are informative. Do not enter if you dont want to see fanboism in comments.

kuchikirukia
25th May 2016, 04:07
The only scandals in graphics cards are the state of AMD's drivers and the power consumption of their cards.

chummy
30th May 2016, 21:36
Async Compute has too much noise from some AMD fanboys but only give 10% gains in performance in GPU bound scenario. In CPU bound side Async Compute do nothing(0) gains.

Dx12 without Async compute increase up to around 100% gains against Dx11 in CPU bound scene. At least with AMD GPU drivers, because you know how bad AMD perform in DX11.

AMD is so bad in DX11 than Nvidia card which do 50% of performance in DX12, is capable do same performance in DX11 CPU bound games.

P.J
14th July 2016, 22:28
http://www.anandtech.com/show/10486/futuremark-releases-3dmark-time-spy-directx12-benchmark

http://images.anandtech.com/graphs/graph10486/82854.png

NikosD
15th July 2016, 00:26
http://uploads.tapatalk-cdn.com/20160714/6e7036e5d778f414b75313f6c2d976cd.jpg

http://uploads.tapatalk-cdn.com/20160714/01dc5a482dfe56c5221c15f99a434c25.jpg

nevcairiel
15th July 2016, 00:30
Graphs entirely out of context, so lets add some context

DOOM Vulkan release notes:
https://community.bethesda.net/thread/54585?start=0&tstart=0

Currently asynchronous compute is only supported on AMD GPUs and requires DOOM Vulkan supported drivers to run. We are working with NVIDIA to enable asynchronous compute in Vulkan on NVIDIA GPUs. We hope to have an update soon.

The Time Spy Benchmark on the other hand supports async on both AMD and NVIDIA, which makes it the first to actually benchmark async compute on Pascal hardware, as far as I know.

NikosD
15th July 2016, 00:38
Graphs entirely out of context, so lets add some context



You meant graphs entirely in context, because they are all over Internet.

So, you misspelled in with out of.


DOOM Vulkan release notes:
https://community.bethesda.net/thread/54585?start=0&tstart=0



Hahaha

That is the same phrase we heard for the first time with "Aces" game when we first saw the huge difference between AMD and Nvidia on Async compute.

We are still waiting for the Nvidia patch...

huhn
15th July 2016, 18:28
never trust a diagram you haven't faked your self:
http://media.gamersnexus.net/images/media/2016/game-bench/doom/vulkan/vulkan-doom-1080p.png

NikosD
16th July 2016, 01:31
I can't believe that German sites like computerbase.de would use photoshop just to support AMD.

Look at the graph.

The performance gain of Vulkan's Async compute is huge especially on Fury cards and all AMD cards in general.

Nvidia gains from nothing to almost nothing, that's a fact.

http://uploads.tapatalk-cdn.com/20160716/cadf9259c13146b5acd91425baa6e119.jpg

Atak_Snajpera
16th July 2016, 10:36
fury x has 1.33 more tflops than 1070 so i'm not surprised that it wins here in low level api. In opencl we should notice similar difference.

NikosD
20th July 2016, 08:10
RX 480 is 25% faster than 1060 in Vulkan DOOM in 1440p resolution (faster than 980 too) and 32% faster than 1060 in 1080p resolution.

@nevcairiel
Notice the comment that 4GB 980 card can't play DOOM in 1080p using "nightmare" settings due to its 4GB only memory.
The game needs 5GB or more.

http://www.hardocp.com/article/2016/07/19/nvidia_geforce_gtx_1060_founders_edition_review/4#.V48he_l97cd

huhn
20th July 2016, 08:42
and the fury , fury x and nano too which are flag ship GPU's unlike the 980.

NikosD
20th July 2016, 09:26
The discussion with Nevcairiel was not about specific models.

It was more general about games requiring close or even more than 4GB memory, so cards like 1060 3GB are doomed from the beginning.

By the way, that new 1060 6GB card is doomed from the beginning too.

It's future proof 0% regarding DX12/Vulkan and for that reason it's not worth its money.

huhn
20th July 2016, 09:31
yeah you found out that doom 3 runs way better on AMD than nvidia. so what? nothing new.

now look at this nvidia is stopping amd into the ground in this game.

http://www.guru3d.com/articles-pages/geforce-gtx-1060-review,13.html

what did we learn here.
Rise Of The Tomb Raider DX 12 runs way better on nvidia than AMD. and again so what.

NikosD
20th July 2016, 10:09
Sorry to say that, but judging from your posts I have told you thousands times that you don't seem to understand the concept on various aspects and that's why you don't seem to learn anything.

Just a few posts earlier, you had even denied that AMD cards are leveraging a lot better the Vulkan API in DOOM and that the graphs are fake!

I don't remember exactly how many times I have told you that even the conversation with you is becoming difficult, unless you do like to troll and so i must not take you seriously...

huhn
20th July 2016, 11:07
yeah because we have one vulkan game.

everything is clear. it says everything!

Just a few posts earlier, you had even denied that AMD cards are leveraging a lot better the Vulkan API in DOOM and that the graphs are fake!

you should read it again...

bidomo
5th September 2016, 00:39
At the end of the day, is up to the end user's preference, I like both AMD and Nvidia, and I know I will get whatever I like the most or I feel I have a better benefit from.

AMD introduced VCE way before nvidia included the NVENC functionality in their cards.

AMD introduced Hardware Async compute WAAAAAAAAAAY before nvidia.

nvidia has had much more support in GPU video encoding than AMD for very long

Games run usually better in nvidia because they co-own DirectX with Micro$oft, I don't really know why DX12 is low level oriented, maybe nvidia didn't have anything to do with that, and M$ wanted a bit more power for the Xbone GNC architecture, I don't know.

What I know for sure is, nobody is getting paid for standing in the side of one company, so this is pointless, facts vs fanboys never gets anywhere.

NikosD
5th September 2016, 09:29
DX is a Microsoft technology that graphics card's giants like Nvidia and AMD try to make it fit better on their own HW.

Due to various reasons (only money) Nvidia in the past had managed to influence Microsoft more than AMD.

But regarding DX12 we could say that the only thing that Nvidia managed to force on MS is to put Fermi in the list of DX12 capable cards.

And Nvidia never released a driver to enable for Fermi! Fermi is just a step before going legacy and Nvidia is still struggling to release a DX12 driver for it, although it pushed MS a lot for that.

DX12 like Vulkan are based A LOT in AMD's own API called Mantle.

Vulkan even more than DX12, that's why Nvidia never told that Fermi will support Vulkan, because their influence in Khronos group which builds OpenGL and Vulkan is not like the influence on Microsoft.

DX12 and Vulkan are still AMD things and Nvidia needs another architecture after Pascal to come closer to AMD, maybe Volta will see.

Vega will destroy Pascal for sure.

And what Nvidia is doing right now in order to keep its fanboys and customers happy until a decent DX12/Vulkan architecture ?

Nvidia does what it know best, paying money for biased benchmarks/ games.

Read about the "Time Spy", so called "DX12" benchmark

http://www.overclock-and-game.com/news/pc-gaming/50-analyzing-futuremark-time-spy-fiasco

Khanattila
5th September 2016, 11:01
At the end of the day, is up to the end user's preference, I like both AMD and Nvidia, and I know I will get whatever I like the most or I feel I have a better benefit from.

AMD introduced VCE way before nvidia included the NVENC functionality in their cards.

AMD introduced Hardware Async compute WAAAAAAAAAAY before nvidia.

nvidia has had much more support in GPU video encoding than AMD for very long

Games run usually better in nvidia because they co-own DirectX with Micro$oft, I don't really know why DX12 is low level oriented, maybe nvidia didn't have anything to do with that, and M$ wanted a bit more power for the Xbone GNC architecture, I don't know.

What I know for sure is, nobody is getting paid for standing in the side of one company, so this is pointless, facts vs fanboys never gets anywhere.
Try to implement VCE and then let me know.

NikosD
9th September 2016, 11:52
Another AAA game goes to DX12 - Deus Ex: Mankind Divided - another HUGE WIN of Polaris and AMD hardware.

RX 480 exceeds the speed of Nvidia GTX 980 and shows similar performance with 1070 (!) at 1440p.

Take a look:
http://wccftech.com/nvidia-amd-deus-mankind-divided-dx12-benchmarks-performs-poorly-geforce/

huhn
9th September 2016, 13:30
you should read the patch it self.

Known DirectX 12 issue:
– There is a known bug that causes some very high end cards to regress relative to DirectX 11. This bug is being addressed by the development team.

Read more: http://wccftech.com/nvidia-amd-deus-mankind-divided-dx12-benchmarks-performs-poorly-geforce/#ixzz4JlFjECkC

the 1070 gets slowed a lot and the 1060 doesn't care in this test.

if you take a closer look even the RX 480 got not that much of a performance boost.

this is just a preview patch anyway.

NikosD
9th September 2016, 14:31
Always excuses when Nvidia is behind in performance

Atak_Snajpera
9th September 2016, 16:51
you should read the patch it self.


the 1070 gets slowed a lot and the 1060 doesn't care in this test.

if you take a closer look even the RX 480 got not that much of a performance boost.

this is just a preview patch anyway.

What is interesting that RX470 is again as fast as 1060. The same happens in Doom (Vulkan). Not bad for card with 4GiB of VRAM and costing 179$ vs 249$ (1060 6GiB).

huhn
10th September 2016, 13:49
in the games benchmark not in the game it self.

the dx 12 version is a simple disaster:
https://www.computerbase.de/2016-09/deus-ex-mankind-divided-dx12-benchmark/2/

CruNcher
11th September 2016, 14:14
What is interesting that RX470 is again as fast as 1060. The same happens in Doom (Vulkan). Not bad for card with 4GiB of VRAM and costing 179$ vs 249$ (1060 6GiB).


Yeah in 3d they slowly coming back and Polaris + Vega + Zen will be great Value with the Right Applications especially but Video wise which back in the Rage days ATI was the King with MPEG DCI Hardware Accelleration under Windows MPC that position has been lost since Nvidia came up with Purevideo and their fixed function VPX in Windows NT days :(

VCE/UVD aren't as far as Nvidias Asic they are already 8k capable while AMD is roughly 4K capable with lot of drawbacks since Tegra X1 and VPX7 Nvidia has widen the gap once more.

Though both are still far behind Intel that took the Hyper Speed Train to Perfection when starting Intel HD and their GMA GPU overhaul and Mobile Attack on ARM as well ;)

And still 4 First Generation Intel Cores alone can even compete with 1000s of Cuda Cores 13 sm and their first H.265 Hybrid Decoder in terms of Performance pretty well ;)


Though for most use cases UVD/VCE are OK it's not that it's overall bad but not as advanced yet but for the most consumer purposes absolutely ok, Hybrid VP9 is also not really a big issue even missing VP9 wouldn't be at all for a longer time span we wont see that big of adaption anyways it was a nice test but with AV1 they are all sitting in the Box directly at the Core implementing and improving from the Start for their future Product Launches.

Though especially on the Encoder side i doubt that either AMD nor Nvidia have made progress like Intel did because quality over everything isn't their target @ all there but the Speed and Latency variable of Game Streaming we all know that since the first H.264 Encoder :D

AMD now supports lookahead wow that was basically the only improvement you could read about in their Marketing papers for the Polaris Launch ;)


If someone says to me what would be your Desktop system decision for now i would say hands down Intel + AMD GPU ;)

Intel for all the Video Parts and AMDs GPU for the 3D Async execution path :)

A complete AMD System in the Future will be very exciting ;)

aufkrawall
16th September 2016, 18:10
in the games benchmark not in the game it self.

the dx 12 version is a simple disaster:
https://www.computerbase.de/2016-09/deus-ex-mankind-divided-dx12-benchmark/2/
The same was the case with the latest Total War game.
In the in-game benchmark, DX12 showed gains with AMD, but in real game, it was slower as well.
Imho really obvious how AMD tries to lead people astray, they are hardly any better morally than Nvidia.

NikosD
16th September 2016, 22:04
In pure close to metal API like Vulkan (DOOM3) and the upcoming Cryengine next month, AMD simply demolishes Nvidia.

Rx 470 can match 1060 6GB card.

But DX12 can be used in a way that can hide the real and pure lack of performance of Nvidia.

It is not a well and pure close to metal API like Vulkan.

Probably Microsoft is waiting for Nvidia to add suitable HW resources in next generation - Volta - or even beyond that to rewrite DX12 in a proper close to metal way like Vulkan.

huhn
16th September 2016, 23:36
But DX12 can be used in a way that can hide the real and pure lack of performance of Nvidia.


can you stop been paranoid?

NikosD
17th September 2016, 04:25
can you stop been paranoid?
Can you stop being so ignorant ?

http://www.overclock-and-game.com/news/pc-gaming/50-analyzing-futuremark-time-spy-fiasco

huhn
17th September 2016, 08:41
nothing to see in the link. just an "Analyze" of an worthless synthetic benchmark.

aufkrawall
17th September 2016, 15:13
In pure close to metal API like Vulkan (DOOM3) and the upcoming Cryengine next month, AMD simply demolishes Nvidia.

Those APIs offer a lot more control over the GPU than DX11/OGL for the developer, but they are not "pure close to metal".

I replaced my R9 390 with a GTX 1070. In Doom's multiplayer mode (it's not Doom 3 btw., it's a reboot) the 1070 often is ~50% faster. I don't see the problem for Nvidia...


Rx 470 can match 1060 6GB card.

There is not a big difference between 470 and 480, so what?


But DX12 can be used in a way that can hide the real and pure lack of performance of Nvidia.

Poorly optimized DX12 ports run also worse on AMD, see Deus Ex.
And Talos Principle btw. also uses Vulkan and runs worse than DX11 on both AMD & Nvidia.

You have some utter misunderstandings.

NikosD
17th September 2016, 17:16
Those APIs offer a lot more control over the GPU than DX11/OGL for the developer, but they are not "pure close to metal".


You don't seem to understand the concept and know what are you talking about.

Both DX12 and Vulkan are basically different implementation and general-purpose port of AMD's proprietary Mantle close to metal API.

Both DX12 and Vulkan are close to metal APIs that moved the weight of optimizations and writing good code from the drivers to the developer of the game.

What I'm saying is that Vulkan is closer to Mantle and closer to the metal than DX12 and a good game developer of DX12/Vulkan can take advantage of the HW resources of AMD's cards which were built for Mantle.

So DX11 has nothing to do with DX12 and OpenGL with Vulkan.

aufkrawall
17th September 2016, 18:55
Both DX12 and Vulkan are basically different implementation and general-purpose port of AMD's proprietary Mantle close to metal API.

Where do I find the term "close to metal" by Khronos or Microsoft?


What I'm saying is that Vulkan is closer to Mantle and closer to the metal than DX12 and a good game developer of DX12/Vulkan can take advantage of the HW resources of AMD's cards which were built for Mantle.

Just because a lot of API calls have similar names, it doesn't mean that Mantle and Vulkan share most of the DNA.


So DX11 has nothing to do with DX12 and OpenGL with Vulkan.
I don't think you read my post correctly.

CruNcher
19th September 2016, 23:19
It's not close to metal it's explicit you can't allow close to metal access on the PC for some simple reasons on the side of security.

The Console Ecosystem works differently first you have shitloads of NDA Second you have very advanced Hypervisor that got hardened more and more after attack over attack, and are used these days even for timeable hardware resource access (Xbox One Indie Dev Mode).

On the PC side the same has been tried to establish with UEFI but it's not sure if it's gonna succeed and Microsoft isn't sure either even on Windows 10 the xs for 3rd party applications on Windows has been getting narrowed down from version to version because mostly of content protection reasons a big part now plays the driver that has to ensure certain protections and protected paths.

Low Level xs without correctly functioning Hypervisor and protected Zones (Trusted Zones,PMPs) would be a big problem of keeping the knowledge secret.

And yes it's about Content Protection not so much about AVG Users Content Protection that is a second goal commercial objective but most off all it's about System Control a System inside a System that the User has nio xs no control at all over (silently sleeping) and can any time used against him if wished..

NikosD
20th September 2016, 18:00
Close to metal = low level API

NikosD
16th October 2016, 09:06
Fastest performance ever for DX12 and AMD playing a super AAA game - Battlefield 1

http://wccftech.com/battlefield-1-directx-12-benchmarks-amd-nvidia/

huhn
18th October 2016, 00:01
here the first "better" still not 100% proper test to BF 1.
it is not really possible to do a proper test with his game.

https://www.youtube.com/watch?v=ZxsIOV2AjMc

and the same image as "always".
AMD fails at DX11 and nvidia lose some performance with DX12.

a good driver is still better than DX12...

CruNcher
19th October 2016, 13:52
Fast Motion Streaming Scenarios are the Hardest for the System and Nvidia is excellent at them even in DX11 :)

https://www.youtube.com/watch?v=N_ISj656Zkw

Nvidia gains a + 10 FPS improvement on the same lower shader load scenario here at High Motion.

That's enough overhead to get 60 FPS stable.

huhn
19th October 2016, 14:05
one of the major problem of AMD is the problem the GPU are not fully utilized.

nvidia doesn't have this problem the DX 11 driver is utilizing the GPU really good and the CPU overhead is a lot lower too. so they fixed the problem without Async Compute. so i don't understand why Async Compute is important or generally needed.
the biggest problem of AMD is there driver.

CruNcher
19th October 2016, 14:23
That's not the whole story the DCE efficiency plays into this as well ;)

Nvidia did not fixed the Multi-threading efficiency of Windows they worked around it on the Driver level and that is generally a bad idea as it has drawbacks then todo it right.

AMD was working behind closed doors on a better solution as a whole, while Nvidia mainly uses this workaround as a Weapon and Product feature and to save time for bigger improvements.


Though time is running out ;)

The release of Pascal (Paxwell) was the most hysterical,panical and fear driven release i ever saw from Nvidia since some time.

It made me to invest some more into AMD, because of it.

aufkrawall
26th October 2016, 15:39
Really funny to see how you first wholeheartedly defended Nvidia for their 970 fraud over at 3DCenter for almost years, and now suddenly change all your opinions by 180°.
Srsly?

CruNcher
28th October 2016, 21:21
I didn't defend their fraud at all but the economic decision for it product wise it gave users a cheap solution compared to the upper lineup, i absolutely did not agree with keeping it secret not one second.
And i still stand behind the Balance of the GTX 970 as i stand behind the Balance of the GTX 1060 (updated 970 with 2.5 GB more) though the Balance of the RX 480 is overall much better (not because of the 8GB) and i compare it more in direction to the 1070 which is partly amazing ;)

NikosD
2nd November 2016, 17:45
It seems that Nvidia hasn't implemented yet in driver another very basic feature of DX12 which is multi-GPU

For RX 480 the scaling works just fine.

Read here:
https://www.pcper.com/news/Graphics-Cards/DX12-Multi-GPU-scaling-and-running-Deus-Ex-Mankind-Divided

huhn
3rd November 2016, 00:42
it is known to work even with a GPU mix of AMD and NVIDIA.
http://www.anandtech.com/show/10067/ashes-of-the-singularity-revisited-beta/4

NikosD
3rd November 2016, 04:50
No.

Don't mix different things.

AoS is just a benchmark.

Now we are talking about a real world AAA game title that it wasn't at all known that MULTI-GPU of even a Pascal card 1060 doesn't work.

AMD excels in this feature:
http://radeon.com/en-us/deus-ex-directx-12-mgpu/

CruNcher
3rd November 2016, 06:33
Ah very nice Vega Sinle GPU 1070 contender Prediciton also

https://www.pcper.com/files/imagecache/article_max_width/news/2016-11-01/mankind1080-avg.png

Vega will be most likely 2x as fast as current RX 480 ;)

lets predict a little less overhead and you would be exactly at 100 FPS in this test with Vega ;)

Though this Engine is really the perfect result using its Deferred+ Render Core


if you do +40 FPS addition to the GTX 1060 + 2*20 FPS you should be at GTX 1080 result ;)

and that is exactly MultiGPU RX 480 result ;)

huhn
3rd November 2016, 08:39
AoS is a game you can play it...

Deus Ex is more known to be broken in DX 12 than anything else.

nevcairiel
3rd November 2016, 09:10
Its one single game, which is clearly sponsored by AMD. Considering multi-gpu modes in DX12 are largely controlled by the game, I wouldn't trust a single result to conclusively point to anything.
Its really one of the big problems with DX12 - its all on the game developers. And most DX12 games so far have had serious implementation issues one way or another - which is no big surprise, developers also have to learn, but alas its where we are.

In any case multi-gpu has always been nothing but a small niche, so I couldn't care less (because once you hit a game that doesn't support any of it, half of your performance is gone - rather go fast single card).
It may even be that it only doesn't work on a 1060, because its also sold as a card without SLI capabilities - but of course the website didn't test anything else.

Additionally there is 3 different multi-gpu modes that developers can use in DX12. At least one of those is known to work on NVIDIA since thats what AoS uses, but presumably DXMD uses another mode.

PS:
Found another one testing the same thing on different hardware, where it works just fine (1070/1080)
http://www.pcgamesn.com/deus-ex-mankind-divided/deus-ex-mankind-divided-dx12-performance

So its either just the 1060, or the other site screwed up somewhere, who knows.

NikosD
3rd November 2016, 09:34
But that's even more embarrassing and irritating for Nvidia's 1060 card owners.

SLI has nothing to do with multi-GPU of DX12, Vulkan, OpenCL.

You can sell a card with SLI disabled/ not supported but why on earth you decide to cut it from MULTI-GPU functionality in general ?

The 300€ of 1060 card are not enough to have multi-GPU on recent and future DX12/Vulkan games ?

Nvidia...same tricks as always.

huhn
3rd November 2016, 13:12
i give you simple reasons why multi GPU support on the 1060 is not that important.

~1.5 years ago i brought a GTX 960 for around 230. today i replaced it with a RX 480 which cost again ~230. i didn't even think for sec to go SLI because buying a new card is obviously the better choice.

the next problem are proper SLI/crossfire boards x8/x8. you have to pay an extra for such a board that is money you can better spend on the GPU in the first place.

and it is still not known if the 1060 doesn't support multi GPU it is just a theory.

NikosD
3rd November 2016, 13:44
Multi-GPU is not SLI.

Also, the world is not spinning around your preferences.

mGPU is there for 1070/1080 cards.

Multi-GPU should be a functionality of 1060 cards, it's a high middle class card around ~300€

huhn
3rd November 2016, 14:39
sli/crossfire boards are needed for the 8x/8x PCIe.
do you really want to run a multi GPU config with a 4x PCIe slot?
it doesn't matter what type of multi GPU you are running you still need to feed it data.

and i can easily get a 1060 3Gb for ~210 and a 6 gb for ~260 euro.

Atak_Snajpera
5th November 2016, 00:22
why would you buy 1060 3GB for 210 euro when you can have xfx 470 rs 4GB for less than 200?

In games like titanfall 2 and in latest cod 470 =1060.

CruNcher
6th November 2016, 07:29
But that's even more embarrassing and irritating for Nvidia's 1060 card owners.

SLI has nothing to do with multi-GPU of DX12, Vulkan, OpenCL.

You can sell a card with SLI disabled/ not supported but why on earth you decide to cut it from MULTI-GPU functionality in general ?

The 300€ of 1060 card are not enough to have multi-GPU on recent and future DX12/Vulkan games ?

Nvidia...same tricks as always.

It looks like it could be another clever Nvidia Software/Hardware lock i hope not :D

But as you said it would be typical Nvidia to enforce Artificial restrictions to not hurt their Product Range and for them SLI = Multi-GPU just with another Name and their Copyright on it ;)


Most probably that's also what they gonna answer to it ("But we said the 1060 has no SLI support and we said in our presentation its a equal function to Multi-GPU, so logically we meant with that both isn't supported,touche" ;) )

But you shouldn't argue about it it would be absolutely their right to decide this for self protecting and investor protection.


why would you buy 1060 3GB for 210 euro when you can have xfx 470 rs 4GB for less than 200?

In games like titanfall 2 and in latest cod 470 =1060.


Which is perfectly logic hardware wise it equals it :)

The RX 480 is raw power higher then the 1060 and the 1060 equals almost exactly the 970 + 2.5 GB and some updated properties Nvidia pushed again most of the improvements into the Power Efficiency like they do since Maxwell and of course we see that they could update VPX over the whole range as well up to 8k additionally with the same update that Tegra X1 and GM206 got way beforehand in the last cycle ;)

And the 1070 reaches +20 fps with the same power draw :)

Btw im only calculating from UHD ;) not 1080p on 1080p the win is higher of course

And there is a reason why i use UHD it yields more stable render results between reviewers, there are way less render fluctuations to account for, it's way more reliable and it becomes the ultimate goal on the PS4 Pro to reach at best without checkerboard rendering ;)

Unfortunately the Trend at reviewers goes into the Direction to rather not test UHD on underpowered Hardware a big failure.

Atak_Snajpera
8th November 2016, 17:12
RX470 is really great GPU for 200 euro
https://i.imgsafe.org/1f94e786c4.png https://i.imgsafe.org/1fa45c1f79.png

huhn
8th November 2016, 17:18
than buy one...

Atak_Snajpera
8th November 2016, 17:21
than buy one...

You meant "then" or "than" ?

CruNcher
20th November 2016, 14:37
It is but the headroom for 4K is pretty darn small with that 4GB you gonna running into problems somewhere, even with good streaming and pretty good texture compression

RX 480 is more future proof and Vega will be blasting, it will be really interesting to see if UVD gonna get a update as well or if the throughput just will get better with the enhanced DCE :)

Infinite Warfare though lacks some excellent Workflow work Sledgehammer Games did on Advanced Warfare previously to Infinity Ward :(

i really have the feeling playing infinite Warfare nobody really cared about Spatial Render Quality Results so much in Advanced Warfare it's the direct opposite


If Sleedgehammer is going to combine both next with some of treyarchs results that will be rocking i miss that ultra clean render output Results

http://i1.sendpic.org/t/n7/n7s0O4LFp75MhqpsxEj0MahrxRg.jpg (http://sendpic.org/view/1/i/gpwHvNk9IkbmPNat5XK6vc9C432.png)

even if many other stuff was excellently improved :)

huhn
20th November 2016, 15:27
UHD doesn't matter for a card like the RX 470/480 or 1060 they are simply to slow for modern games at UHD.

i can't get stable 30 FPS at UHD in dark souls 3 with my RX 480 the card is simply way to slow for that.

CruNcher
20th November 2016, 16:06
yeah there every frame counts 22-25 though should be possible like in the witcher 3 but From Softwares Engine is known to be not very performant at all ;)


Motionblur=Medium
Shadows= Medium
Effects= Medium

and 30 fps should be though doable or even better turn Motionblur completely off

youtube results speak other words also 33.3 ms 30 fps is doable on the 470 even with that Crap Engine in 4K :)

https://www.youtube.com/watch?v=IOLRj7v8Or0

CruNcher
29th November 2016, 19:23
I tried to understand why im so fascinated by this rather old output results by Sleedgehammer Games IWE Engine Branch of the characters and all the smooth surfaces especially for the Render Performance in 4K

http://www.graphics.stanford.edu/~niessner/brainerd2016efficient.html

. Our approach achieves performance up to three times that of state-of-the-art methods for typical tessellation factors.
We have integrated our approach into a production game engine (Figure 19), and hope that by demonstrating a streamlined approach
for rendering full-featured subdivision surface models, we can spur further interest in, and adoption of, subdivision surfaces in game rendering.
With further improvements in hardware, subdivision surfaces may soon be as easy to render as triangle meshes.