Nvidia scandal with Async Compute support (DX12)

[NikosD]

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]

real life result is what matters though.

[NikosD]

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]

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]

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]

It's soon to discuss about DX12. We should blame Microsoft first x)
And since I know, it does nothing with DXVA :)

[NikosD]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Anyway i'm forced to buy NVidia as AMD ignoring completely video - NVENC can't be compared to AMD solution...

[huhn]

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]

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]

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]

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]

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]

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]

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]

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]

have you read it your self. NVENC isn't made for HEVC only.

[NikosD]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Exactly.

[NikosD]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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. :(