Yes, We’re Writing About a Forum Post
What is asynchronous compute, and how is it interpreted?
Update – July 19th @ 7:15pm EDT: Well that was fast. Futuremark published their statement today. I haven't read it through yet, but there's no reason to wait to link it until I do.
Update 2 – July 20th @ 6:50pm EDT: We interviewed Jani Joki, Futuremark's Director of Engineering, on our YouTube page. The interview is embed just below this update.
Original post below
The comments of a previous post notified us of an Overclock.net thread, whose author claims that 3DMark's implementation of asynchronous compute is designed to show NVIDIA in the best possible light. At the end of the linked post, they note that asynchronous compute is a general blanket, and that we should better understand what is actually going on.
So, before we address the controversy, let's actually explain what asynchronous compute is. The main problem is that it actually is a broad term. Asynchronous compute could describe any optimization that allows tasks to execute when it is most convenient, rather than just blindly doing them in a row.
I will use JavaScript as a metaphor. In this language, you can assign tasks to be executed asynchronously by passing functions as parameters. This allows events to execute code when it is convenient. JavaScript, however, is still only single threaded (without Web Workers and newer technologies). It cannot run callbacks from multiple events simultaneously, even if you have an available core on your CPU. What it does, however, is allow the browser to manage its time better. Many events can be delayed until the browser renders the page, it performs other high-priority tasks, or until the asynchronous code has everything it needs, like assets that are loaded from the internet.
This is asynchronous computing.
However, if JavaScript was designed differently, it would have been possible to run callbacks on any available thread, not just the main thread when available. Again, JavaScript is not designed in this way, but this is where I pull the analogy back into AMD's Asynchronous Compute Engines. In an ideal situation, a graphics driver will be able to see all the functionality that a task will require, and shove them down an at-work GPU, provided the specific resources that this task requires are not fully utilized by the existing work.
Read on to see how this is being implemented, and what the controversy is.
A simple example of this is performing memory transfers from the Direct Memory Access (DMA) queues while a shader or compute kernel is running. This is a trivial example, because I believe every Vulkan- or DirectX 12-supporting GPU can do it, even the mobile ones. NVIDIA, for instance, added this feature with CUDA 1.1 and the Tesla-based GeForce 9000 cards. It's discussed alongside other forms of asynchronous compute in DX12 and Vulkan programming talks, though.
What AMD has been pushing, however, is the ability to cram compute and graphics workloads together. When a task uses the graphics ASICs of a GPU, along with maybe a little bit of the shader capacity, the graphics driver could increase overall performance by cramming a compute task into the rest of the shader cores. This has the potential to be very useful. When I talked with a console engineer at Epic Games last year, he gave me a rough, before bed at midnight on a weekday estimate that ~10-25% of the Xbox One's GPU is idling. This doesn't mean that asynchronous compute will give a 10-25% increase in performance on that console, just that there's, again, ballpark, that much performance left on the table.
I've been asking around to see how this figure will scale, be it with clock rate, shader count, or whatever else. No-one I've asked seems to know. It might be an increasing benefit going forward… or not. Today? All we have to go on are a few benchmarks and test cases.
The 3DMark Time Spy Issue
The accusation made on the forum post is that 3DMark's usage of asynchronous compute more closely fits NVIDIA's architecture than it does AMD's. Under DOOM and Ashes of the Singularity, the AMD Fury X performs better than the GTX 1070. Under 3DMark Time Spy, however, it performs worse than the GTX 1070. They also claim that Maxwell does not take a performance hit where it should, if it was running code designed for AMD's use cases.
First, it is interesting that AMD's Fury X doesn't perform as well as the GTX 1070 in Time Spy. There could be many reasons for it. Futuremark could have not optimized for AMD as well as they should have, AMD could be in the process of updating their drivers, or NVIDIA could be in the process of updating their drivers for the other two games. We don't know. That said, if 3DMark could be more optimized for AMD, then they should obviously do it. I would be interested to see whether AMD brought up the issue with 3DMark pre-launch, and what their take is on the performance issue.
As for Maxwell not receiving a performance hit? I find that completely reasonable. A game developer will tend to avoid a performance-reducing feature on certain GPUs. It is not 3DMark's responsibility to intentionally enable a code path that would produce identical results, just with a performance impact. To be clear, the post didn't suggest that they should, but I want to underscore how benchmarks are made. All vendors submit their requests during the designated period, then the benchmark is worked on until it is finalized.
At the moment, 3DMark seems to oppose the other two examples that we have of asynchronous compute, leading to AMD having lower performance than expected, relative to NVIDIA. I would be curious to see what both graphics vendors, especially AMD as mentioned above, have to say about this issue.
As for which interpretation is better? Who knows. It seems like AMD's ability to increase the load on a GPU will be useful going forward, especially as GPUs get more complex because it doesn't seem like the logic required for asynchronous compute would scale too much in complexity with it.
For today's GPUs? We'll need to keep watching and see how software evolves. Bulldozer was a clever architecture, too. Software didn't evolve in the way that AMD expected, making the redundancies they eliminated not as redundant as they expected. Unlike Bulldozer, asynchronous compute is being adopted, both on the PC and on the consoles. Again, we'll need to see statements from AMD, NVIDIA, and Futuremark before we can predict how current hardware will perform in future software, though.
Update @ 7:15pm: As state at the top of the post, Futuremark released a statement right around the time I was publishing.
About Async, one picture and
About Async, one picture and one quote says it all…
https://i.imgur.com/s51q4IX.jpg
Futuremark quote: “The implementation is the same regardless of the underlying hardware.”
DirectX12 requires that the developer does the job of choosing and coding which kind of implementation is to be used ( as can be clearly seen on the above picture ). And Futuremark can’t dispute this, its part of DX12’s core functions ( google it ).
Since there is only 1 implementation ( see quote above ) and Nvidia only supports context switching/preempt. And also by their own admission Pascal do support the implementation they have in TimeSpy.
We can conclude, per their own admissions, that TimeSpy is thus coded for the only method which can run on both Pascal and AMD’s hardware without hardware specific paths. That method being preempt, with the 2 other faster methods having no code written for it and thus not being used on AMD hardware.
Quod erat demonstrandum.
Now that we got their bit of sophistry deciphered, you are free to conclude whatever you want.
They were going for how
They were going for how typical game devs would code their games. It's a reasonable assumption that most games will implement those functions that apply to all GPU vendors. If AMD had huge market share then there might be an argument otherwise, but that's not the case.
Not true anymore. Games for
Not true anymore. Games for XBO are now coded with DX12 for GCN. Only NVidia needs own code path for porting on PC. There is no sense in disabling ready GCN code path.
Even a 20% of the PC gaming market, means few milions people. Futuremark must be filthy rich:)
That’s the problem, more devs
That’s the problem, more devs are starting to use engines that tap into the way amd handles concurrent graphics/compute work.
the idtech guys got those ancient console gcn chips to run doom on a console at 60fps most of the time. They did that by not ignoring the untapped power of gcn. Now it may be true that game devs will be as sloppy and or rushed from the bean counters as the AC unity devs or batman arkham devs, but the more devs that do what idtech did, the better games will run on all hardware. That means optimizing for gcn. If they fail to do this, you will more pretty and garbage performance games like AC unity.
You have seen a better path, and now the time spy guys choose not to follow it. Pathetic.
Same reason 3dmark doesn’t
Same reason 3dmark doesn’t include physx as standard in their benchmark either. Because Nvidia has hardware and AMD is stuck with software version. Because AMD has special async shaders that give them more performance you feel they should be utilized but not anything that helps Nvidia. Hypocrites.
They always go with the least common denominator. It’s a concession that has to be made to test both cards. A benchmark have to have balance otherwise it isn’t very useful to test what it tests.
In this case GRAPHIC capability of a card under directx 12 with async compute support as defined by Microsoft and not AMD’s implementation of it, async compute with graphics.
I seriously don’t know what is hard to grasp about it.
You clearly have no idea of
You clearly have no idea of what you’re talking about. GCN’s implementation is TEXTBOOK what Microsoft asked for DX12. Nvidia on the other hand only partially supports what was asked, 1 out of the 3 methods prescribed.
As for PhysX that’s a false analogy. PhysX is proprietary and can’t be implemented in hardware by AMD. Wherehas the 3 Async methods as prescribed by Microsoft in DX12 are open and anyone can make hardware for it.
Whether you like it or not, Futuremark’s explanation that it has chosen to cater to the lowest common denominator because Nvidia didn’t support the other 2 methods and the 2 vendors have made adamant that no vendor specific paths be implemented is bullshit.
They had another option, simply implement unbiasedly the full 3 methods as per microsoft’s DX12’s specifications and let the vendors support what they could, giving preempt boost only to Nvidia’s hardware and full Async for AMD’s hardware that can support it on the same neutral code path.
And this would’ve been the most neutral decision, we don’t care, we go with the DX12 specifications, you sort it out on your hardware and support it or not, your problem.
So why didn’t they go with this most unbiased option instead of the one biased in Nvidia’s favor by denying the massive boost to AMD’s hardware? There is only 1 logical answer to this, only 1 truth, but you can’t handle the truth, so you babble logical fallacy after logical fallacy.
You want to talk biased.
You want to talk biased. Timespy is highly AMD hardware biased.
The compute shader invocations went up from 1.5 million to 70 million almost 4667% (46.7x) increase. And 8.1 million to 70 million almost 864% (8.6x) increase.
The tesselation on the other hand went up from 500k to 800k for a 60% (.6x) increase. And 240k to 2.4 million for a 1000% (10x) increase.
Whose graphic hardware is heavy on compute? Well before Pascal anyways.
Maybe we should accuse them of biasing toward AMD. A little piddling 6.1% average worth of async help for Pascal on Nvidia’s side isn’t going to do much against such gimping.
Oh hold on AMD still ended up with more improvement of 12% average for Fury cards and 8.5% for Polaris Rx 480. WTF are AMD fanboys on. You still get double benefit with older Fury cards and you’re still not happy. LMAO
Is this a fallacy then?
This is a lowest common
This is a lowest common denomination approach to asynchronous compute by 3dmark. Completely understandable as they include it as a dx12 feature, not a intentionally in depth test.
Obviously amd will not get the most benifit on something that is not built to test the full capacity of their “metal” deep hardware optimization.
Nvidia would get a better result as well if this was built to use the software side of asynchronous compute more like dx11.
The treating of all asynchronous compute equally is the only way to test fairly. This is after all not a test of the BEST possible result for an optimized platform, but the Most Likely best result over all platforms when generally optimized without the use of software.
That’s the big takeaway here.
That's the big takeaway here. Sure there will be some titles where devs put more work into one side or the other, but the Futuremark guys were going for what they viewed as the 'typical' effort put in by the average developer. Kinda makes sense, because they have to actually put that work in themselves in order to create the test in the first place, so their effort is going to mirror that of a typical game dev.
I agree. It’s the only way to
I agree. It’s the only way to make sure that the benchmark is largely unfair to both sides.
Besides as Oxide and AMD fanboys point out for Nvidia, AMD had and did offer their input while said program was being developed. Doesn’t feel too good from the other side does it. Because most of the new directx 12 games coming out thus far are Gaming Evolved and favoring AMD of course, they feel everything should go their way.
If balanced isn’t good enough and Nvidia has at least 70% of the discrete market, should the benchmark not be skewed toward Nvidia. That means it should utilize gobs of tesselation and geometry instead of shader. AMD fanboys would be begging for the old “biased” benchmark back. LOL
Every single cross platform
Every single cross platform game that runs on consoles will have to be optimized for gcn, every single one if they care at all about increased performance. This will be the same for the updated versions of consoles next year. It is in every single cross platform devs interest to build and modify their engines to better take advantage of amd gpus. Even if amd only had 10% of the discreet gpu market this would still be the case. So stop trotting out that 70-76% marketshare number like it’s supposed to mean the bulk of devs should not even bother.
Why do I get the feeling that
Why do I get the feeling that if Futuremark had chosen to implement Async compute in a way that really benefited AMD’s architecture and was not at all useful to Nvidia’s architecture, you’d be right there on the front lines crying and screaming about biased benchmarks?
Another reader recently
Another reader recently pointed out that you are an Nvidia apologist. Your comments here certainly support that allegation. I would think you are supposed to stay neutral given your position and inherent conflict of interest, but you cannot seem to help yourself.
Yes, let’s wait to make a
Yes, let’s wait to make a benchmark that actually tests DX12 until Nvidia has sorted out its DX12 issues.
Lets wait a couple of years before showing to the public that Polaris is the most efficient one until it is not longer competing.
So in two years we will have a Benchmark that show that Polaris was better than Pascal. But at that time no one will care.
The benchmark is tailor made for Pascal. One cannot escape this fact.
Whether you like it or not,
Whether you like it or not, Futuremark’s explanation that it has chosen to cater to the lowest common denominator because Nvidia didn’t support the other 2 methods and the 2 vendors have made adamant that no vendor specific paths be implemented is bullshit.
They had another option, simply implement unbiasedly the full 3 methods as per microsoft’s DX12’s specifications and let the vendors support what they could, giving preempt boost only to Nvidia’s hardware and full Async for AMD’s hardware that can support it on the same neutral code path.
And this would’ve been the most neutral decision, we don’t care, we go with the DX12 specifications, you sort it out on your hardware and support it or not, your problem.
So why didn’t they go with this most unbiased option instead of the one biased in Nvidia’s favor by denying the massive boost to AMD’s hardware? There is only 1 logical answer to this, only 1 truth, but you can’t handle the truth.
That’s “SLI” but it’s really
That’s “SLI” but it’s really explicit milti-adaptor that is in the API for games developers to use. Just wow a processor under the control of the OS/API, finally, what a joke the microprocessor OSs/APIs have been all these decades to not have been doing this from the start. Just try and gimp that, Nvidia!
“GTX 1060 “SLI” Benchmark – Outperforms GTX 1080 with Explicit Multi-GPU”
http://www.gamersnexus.net/guides/2519-gtx-1060-sli-benchmark-in-ashes-multi-gpu
every thread on this topic is
every thread on this topic is a cesspool of armchair engineers spewing uninformed speculations and spreading misinformation
110% agree!
110% agree!
How so? Are you a developer
How so? Are you a developer from Futuremark? Then you are just as qualified to give your opinion as the next guy. Care to enlighten us with the correct information o wise one.
“Care to enlighten us with
“Care to enlighten us with the correct information o wise one”
Coming from YOU, that’s fucking hilarious.
Thanks, still waiting on that
Thanks, still waiting on that answer. You seem like you must know it. Right thought as much BS.
Well, princess, since you’re
Well, princess, since you’re teeing it up for me, I might as well humiliate you again. You must be some sort of masochist, as you constantly get proved wrong and slapped down again and again, and yet you keep coming back for more.
So let me start by saying that your question – the one you’re still waiting on an answer for – doesn’t even have an answer because it’s the wrong question. Nothing that the Anonymous OP wrote made a direct claim of any sort that could be proved by a Futuremark developer or anyone with inside knowledge of FM’s processes.
The Anonymous OP’s claim was, and I quote, “every thread on this topic is a cesspool of armchair engineers spewing uninformed speculations and spreading misinformation”
Are YOU a Futuremark developer? Do you have inside information? No? Yeah, I didn’t think so. Do you know what that makes you? An armchair engineer spewing uninformed speculation and spreading misinformation.
OP had it right on the money.
Now, since you want to play this “still waiting for an answer” game, I’m still waiting on you to prove that Freesync doesn’t do anything over 90 Hz. (And remember, you are claiming that FREESYNC doesn’t do anything over 90 Hz – you are not claiming that ONE FREESYNC MONITOR has a Freesync range that ends at 90Hz.)
C’mon, now. Live up to your own standards that you expect everyone else to live up to.
The same could be said for
The same could be said for every forum on most internet websites. What is lacking is the proper amount of online information to properly examine the issue. The GPU makers themselves are not very forthcoming in providing the proper amount of technical details about their GPU core’s execution resources in one easy to access location. Apparently there is more information available for a CPU core’s actual core execution resources from most of the CPU makers, but for GPUs and their cores the same information is hard to come by without a lot of intensive searching.
Hopefully this year’s Hot Chips Symposium will offer up a little more information on AMD’s Zen, and Polaris micro-architectures, the same for Nvidia’s Pascal, and new Tegra offerings. So what do you expect when the GPU makers are not in the habit of providing some good quality, non dumbed down, technical information on their GPUs. The games/gaming engine developers get a lot more information and access to technical manuals but that requires the signing of a NDA, so even the games/gaming engine developers have to be careful.
The games/gaming engine developers are commenting on both AMD’s and Nvidia’s newest GPU micro-architectures but there is a limit to what they can publicly say. It’s going to take a while before the academic institutions start to produce the graduate and doctoral papers that will provide a more in-depth look at the newest Nvidia and AMD GPU offerings, and the Vega/Greenland and Volta GPU micro-architectures will get a better going over by the server/HPC focused websites in 2017 when AMD’s supposed to reenter the server market with both Zen/Vega or Zen/Greenland and Zen CPU/APU server/HPC options, while Nvidia will have its Volta GPU accelerators in the market also.
Pair that lack of readily available very technical details from the GPU makers with the terrible miss-use of and defining of the proper computing sciences terminology, that is often times obfuscated behind marketing names(TM), things become very confusing. Additionally the lack of proper online computing dictionaries of the industry wide accepted computing sciences terms does not help in increasing any understanding of the terminology such as Asynchronous Compute, and other highly technical software and hardware usages of the term.
With a whole generation of script kiddies out there working at a software abstraction level(Script) that is the farthest level of abstraction from the real metal native mode assembly language what can anyone expect when it is the ones with the least exposure to computing science that are the ones writing for and running most of the websites devoted to GPUs/CPU on the consumer side of things. Add to that the marketing/MBA run technology companies that where once started by engineers and became successful, only to be taken public and taken over by the marketing/MBA types well that’s what really runs things into the ground for the PC industry that in now in a decline, with even the tablet/phone devices markets reaching a stagnant maturity.
Expect there be mostly wild speculation about any hardware CPU/GPU/FPGA and others going forward with the entire industry under the control of mostly the marketing/MBA types, look at Tim Cook of Apple an Industrial engineering(BS)/Bean counter and an MBA.
Good Luck getting anything but wild speculation unless you are prepared to go to a very expensive pay-walled publication. And the Benchmarks can all be gamed to spin things one way or the other.
Ok so in other words the
Ok so in other words the standard for the benchmark is set to utilize Pascal fully, but after that it stops. No additional DX12 performance on AMD cards even though they are obviously better in this regard.
Same old song for AMD. They always get screwed in benchmarks, even if it is ever so slightly.
It never stops.
The standard for the
The standard for the benchmark i set to run generic code, not code written specifically for certain cards.
nVidia just happen to be better at that than AMD.
If AMD handled generic code better as well, they’d see smaller improvements from running AMD optimized code.
Whether you like it or not,
Whether you like it or not, Futuremark’s explanation that it has chosen to cater to the lowest common denominator because Nvidia didn’t support the other 2 methods and the 2 vendors have made adamant that no vendor specific paths be implemented is bullshit.
They had another option, simply implement unbiasedly the full 3 methods as per microsoft’s DX12’s specifications and let the vendors support what they could, giving preempt boost only to Nvidia’s hardware and full Async for AMD’s hardware that can support it on the same neutral code path.
And this would’ve been the most neutral decision, we don’t care, we go with the DX12 specifications, you sort it out on your hardware and support it or not, your problem.
So why didn’t they go with this most unbiased option instead of the one biased in Nvidia’s favor by denying the massive boost to AMD’s hardware? There is only 1 logical answer to this, only 1 truth, but you can’t handle the truth
From watching the video its
From watching the video its seems to me I want a company to replace futuremark/3dmark and make new benchmarks that shows us the best games can look if you fully utilized all the capability of the drivers(dx12) and the hardware. Im not interested in benchmarks that only show me features that game developers will find useful based on market share of the gpu makers and only on features that game developers will find worth their wild to implement. Benchmarks like 3dmark should push the envelope of visual detail and new driver and hardware features, not be a glimpse into how predicted games will perform. If I want to know how the card will perform in games, I will run in-game benchmarks. Benchmarks like 3dmark need to show me which card is truly better when all software and hardware features and optimizations are used to their fullest potential.
This is why I don’t trust
This is why I don’t trust benchmarks now a day.
I used to think, those benchmarks stressed my hardware to the limited of it capabilities to see what’s best or not, so I can use it for my judgment per purchased decision. It shouldn’t matter which hardware I’m testing.
Benchmarks now a day should called as BENCHFAVORS!
Any of you believe in the
Any of you believe in the report that nvidia is “cheating” to get better benchmarks by fudging texture upload ?
https://www.youtube.com/watch?v=FVb25eomcrI
It seem nvidia cards dont use the full res texture (did ID or nvidia do this ??) and instead stream mipmaps over time
In contrast AMD cards seem to always deliver full res textures.
I think its not cheating if its a game/driver option. But if its done as a hack to get better frame time, we are comparing apple and oranges when doing performance benchmarks.
Yes and that’s how Nvidia
Yes and that’s how Nvidia gets the FPS and gets the fools to buy into the whole line. But all games use mipmaps to a degree. Maybe there needs to be a benchmark that can measure frame by frame pixel quality and not only frame delivery variance and rate.
So maybe save all of the frames and run some analytical frame quality algorithms to see just which GPU is producing the best quality. There is plenty of software that can measure pixels at the sub-pixel level for certain levels of quality, even if the image has been blurred.
There will be more games moving some of the non graphics gaming compute workloads on the GPU to accelerate more than just graphics, so when those benchmarks arrive things will become clearer. Right now the VR games are in the early stage of optimization but as time passes there will be the necessary benchmarking software to measure not only graphics frame efficiencies but also compute workloads efficiencies on the GPU, to better rate the GPU for overall ability to take compute pressure of if the CPU’s cores. The VR gaming need for low latency will dictate that more non graphics gaming compute ability be necessary on the GPU’s cores going forward for 4k and VR gaming.
Did PCPer have any article
Did PCPer have any article about Pascal latency issues? Like they jumped on the Polaris motherboard power draw?
I don’t see the problem. AMD
I don’t see the problem. AMD gets more ~2x perf improvement from turning on Async and clearly there is no effect on older NV tech…LOL. It would almost seem as though the poster has it backwards, and it more aligns to AMD’s async ways. I mean shouldn’t the benchmark be showing NV 12% async gain and AMD 5.8% for this to be true? It’s comic that people think all dx12 games work faster on AMD (umm, tomb raider anyone?), and Vulkan will too…LOL.
http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/73040-nvidia-gtx-1060-6gb-review-16.html
1060 smashes 480 in dx12. Page 18 shows the same in 1440P (and is barely playable anyway here). Not all games will favor AMD in DX12 people. You can’t judge an entire api or TWO api’s in this case on <5 games, especially with AMD abandoning DX11 and only concentrating on dx12 since before win10 even hit due to lack of funding and consoles stealing R&D (people time with 30% less workforce in last few years, and MONEY with losses for ages).
Doom isn't even currently running the latest library with Pascal cards (forces 1.0.8 instead of either 1.0.11.1 or even later version amd is using 1.0.17.0). I doubt Id is being jerks here, it's just a mishap or whatever they aimed at first, or what they were using to develop with here first. If NV has read hardocp review (or the german site showing how bad their new cards are running), I'm sure they're working on it. In fact Bethesda's Vulkan faq admits they have an issue and are working on async for pascal for doom. It's comic people immediately jump to "those bastards are cheating". Also don't forget that in some cases, games just run faster on one tech or the other. IE project cars, WOW, Anno2025, AC Syndicate NV dominant. The reverse also happens, say COD black ops3 AMD (looking at 1060 vs. 480, and I could find a few more AMD or NV >15% wins probably – just an example from one site).
So basically the complainer is saying they should design for AMD use cases who owns 20% share, instead of NV who owns 80%? Ideally they don’t PURPOSEFULLY design for either side, but what you’re asking for would ONLY happen if AMD writes a check to make that happen on purpose. Wake me when Async matters anyway at 5-12% gains (I can OC to get that with a setting that affects ALL games). Meaning let me know when 99% (ok 50%?) of the games are made for dx12/vulkan instead of DX11. 🙁 Don’t forget this benchmark being discussed isn’t even a GAME. LOL. Simple solution: Stop benchmarking crap stuff that isn’t real to begin with! 🙂 Can I play Time Spy? ROFL. NOPE.
IMHO the games used for benchmarking should reflect SALES. IE, if the game is selling under 100k, nobody cares anyway. WOW on the other hand selling millions repeatedly with every new expansion should always be included. When 7-10mil subscriptions are playing a game it’s clearly worth benchmarking correct? If a game has such poor sales you could easily claim it’s not worth the time to benchmark it. I mean who cares if nobody bought it? I also don’t agree with turning off features that users of a product would NOT turn off. IE, hairworks. Who goes home with an NV card and turns it off in witcher 3? LOL. Maybe you turn it down to 4x-8x instead of 64 so it isn’t so lopsided for testing, but turning it off is senseless when it is what the devs wanted to show and a feature add-in you get from vid cards (AMD cards and <=980 don't take a large hit until >8x tessellation so why not test ON?). Would you turn it off in COD Ghosts, or Farcry 4 when playing if your card is fine with a certain level of it on? NO.
http://physxinfo.com/wiki/File:HairWorks1.jpg
COD fur looks excellent. I would possibly buy to get this if it keeps showing up in more stuff. IT works for AMD anyway, you just turn down the tessellation a bit same as you would for older NV cards.
http://core0.staticworld.net/images/article/2015/05/witcher-3-nvidia-hairworks-example-100586285-orig.png
Which wolf would you rather see in your game?
http://itwriter.ru/wp-content/uploads/2014/11/image017.jpg
dynamic fur.
https://developer.nvidia.com/content/nvidia-hairworks-farcry-4
Hairworks changes far cry 4 quite a bit with so many animals running around. I want to see 160-315K strands of hair flopping around on animals. 1-2 days per animal shows a lot of devs will start using this type of tool.
http://www.hardocp.com/article/2015/01/12/far_cry_4_graphics_features_performance_review/5
7% difference on 980 turning on fur. When it’s 130fps, I’ll take that hit. Note the radeon 290x took the same hit. So this “hairworks is evil” crap is BS. Only if you turn levels up so high (witcher 3 x64 tessellation for example) that hairworks is really just showing off new gpus without much gain in the look in the game.
“What we are experiencing with fur seems to be very consistent across Maxwell, Kepler, and Hawaii GPUs.”, said HARDOCP.
Ok then…TURN IT ON. Demonizing it is dumb. I’d say the same for any feature from either side until it gets ridiculous like witcher 3 at 64x levels.
Second paragraph: “1060
Second paragraph: “1060 smashes 480 in DX12”
In the article you cited, at 1080p, 480 beats 1060 in 3 out of the 4 DX12 games tested. At 1440p, 480 beats 1060 in 3 out of the 4 DX12 games tested. The only game the 1060 wins in both instances is RotTR, which has historically always run better on Nvidia.
Somehow, to you, that means, “1060 smashes 480 in DX12”?
Really?
Third paragraph – you are either unaware that in OpenGL, Nvidia cards use 4.5 while AMD cards are forced back to 4.3, or you’re perfectly aware and chose to omit that fact from your argument.
Fourth paragraph – by your logic, Futuremark should have severely limited the amount of tessellation used in FireStrike. After all, if they’re going to limit the use of asynchronous compute methods because Nvidia can’t handle them, then they should have limited the use of tessellation libraries because AMD couldn’t handle them.
After that, the rest of your post is a word soup mishmash of hypocritical arguments that bounce between, “If your card can’t handle them, turn them off,” and, “Reviewers shouldn’t turn those off! Who cares if it skews the comparisons, it skews them in my team’s favor!”
p.s. Just in case your first instinct is to throw up a “fanboy” straw man, I betcha can’t guess what graphics card (or cards) I use.
You’re back. Probably a pair
You’re back. Probably a pair of “phantom” 980’s. The tesselation in 3d mark Firestrike was much lower than compute shading.
In test 1 it was 500k tesselation versus 1.5 million compute (3x) more.
Test 2 must be it wrong. 240k to 8.1 million. Oops almost 34x as much.
https://pcper.com/image/view/71523?return=node%2F65777
Aww, look, the sad little
Aww, look, the sad little Nvidia fanboy can’t stand the idea of being slapped around by another Nvidia user, and so has to make-believe that I’m lying about my graphics cards. Classic sign of someone who knows perfectly well that he’s full of shit but is completely unable to admit it to himself or anyone else.
Also a classic ad hominem fallacy. But you’re all about arguments made up of fallacies.
By the way, nothing in your response addresses the one statement in my comment that you chose to respond to (while ignoring all of the rest because you knew perfectly well that you would lose.)
Totally agree with what
Totally agree with what you’re saying. Physx should be used in benches as well. Can you find one? Not today. Physx is seen as worthless by AMD fanboys but both their consoles have it supported as. So even the software version was seen as worthwhile.
http://nvidianews.nvidia.com/news/nvidia-announces-physx-support-for-microsoft-xbox-one-game-console
http://gadgets.ndtv.com/games/news/sonys-playstation-4-to-get-nvidias-physx-and-apex-support-340963?site=classic
My question is this, if both consoles support it why is physx not included as well. Microsoft supports Physx so by extension it’s a supported feature of dx12. AMD cards can utilize it but take a hit much like Nvidia’s trying to run AMD’s version of async. Except you don’t get anything useful out of trying to run something you’re not able to.
It’s a crime that it’s not included in a benchmark because gosh darn it games support and want it. Not every game wants or needs async which is supposedly a bitch to properly code for along with dx12 too.
Maybe futuremark should make a separate benchmark for each card. That way it is a fair version for everyone. You can rate your card against other Radeons and Nvidia would be only against other Nvidia cards. This is only meaningful way to compare cards. It’s hard to make a truly unbiased test when the two things being compared are too different architecturally.