It all boils down to what I have thought, they are not using the same code path for each vendor, and the code path that is the same is made for the lowest common denominator.
What we need is full source to be made available, then people can really see what is going on, but, this will never happen unless you pay to play.
The one spreading missinformation is you, so please inform yourself about DX12.
The Feature Levels are these ones:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt186615(v=vs.85).aspx
Async is part of the DX12 Multiengine Feature which needs to be there to get any DX12 compatibility:
https://msdn.microsoft.com/en-us/li...)()#asynchronous_compute_and_graphics_example
Without Multiengine support you don't have DX12 support independent of the feature level. There is a difference between API features of DX12 and hardware feature levels.
This I am not so sure about. Like I said before the engine is the core and so many games now use established engines, or new engines with great developers behind them. Even IDsoftware went so far in what they did with DOOM to the point that they use shader intrinsics. This will continue to benefit any game they choose to use that engine for. So the investment for a lot of these AAA games comes in the engine that is made 'once'. Snowdrop, frostbite, cryengine, nitrous etc. So I don't think it will be odd for engine developers to pick and choose features to integrate with separate code paths. I am sure your own developers could have done it as well if that was the plan. If you could then build multiple benchmarks on that engine, it would suggest multiple games can be built on the same engine with that investment already made. Compatibility is not affected, but the potential gains with newer hardware might be worth it.
Is this not what happens in the game/engine relationship?
http://www.futuremark.com/downloads/3DMark_Technical_Guide.pdf
It was not tailored for any specific architecture. It overlaps different rendering passes for asynchronous compute, in paraller when possible. Drivers determine how they process these - multiple paraller queues are filled by the engine.
The reason Maxwell doesn't take a hit is because NVIDIA has explictly disabled async compute in Maxwell drivers. So no matter how much we pile things to the queues, they cannot be set to run asynchronously because the driver says "no, I can't do that". Basically NV driver tells Time Spy to go "async off" for the run on that card. If NVIDIA enables Asynch Compute in the drivers, Time Spy will start using it. Performance gain or loss depends on the hardware & drivers.
Yes it is. But Engine cannot dictate what the hardware has available or not.
Async compute is about utilizing "idle" shader units. Slower the card, less idle ones you have. Less capable hardware may also be hard pressed to utilize all of them even if the engine asks nicely. Also there may be limitations as to what workloads in the engine *can* run in parallel. Yes, Time Spy is very graphics-heavy, since, well, its a graphics benchmark. But even there many of the rendering passes have compute tasks that can use this.
Ultimately some AMD cards gain quite a bit (ie. they have a lot of shader units idling while rendering and they are very good at using them for the available paraller loads). Some AMD cards gain less or not at all (either less capable at paralleriziing, less idle shader units or no idle shader units at all - for example a HD 7970 is hard pressed to have any to "spare")
Some NVIDIA cards cannot do this at all. The driver simply says "hold your horses, we'll do this nicely in order". Some NVIDIA cards can do some of it. They might use another way than AMD (more driver/software based), but the end result is the same - the card hardware is capable of doing more through some intelligent juggling of the work.
He probably refers to this:
http://www.futuremark.com/downloads/3DMark_Technical_Guide.pdf
I'm also completely happy to pass on any detailed tech questions directly to the lead developer of the DX12 engine. I can't guarantee he can answer everything, but I'll promise to ask. For complex stuff, please email to info@futuremark.com so I can forward it directly.
Source code? You need to join the Futuremark Benchmark Development Program to get access to the git repo
I have a question, does 3DMark Time Spy have a FL 12_0 code path ?
FM_Jarnis: Async compute is about utilizing "idle" shader units. Slower the card, less idle ones you have.
Ultimately some AMD cards gain quite a bit (ie. they have a lot of shader units idling while rendering and they are very good at using them for the available paraller loads). Some AMD cards gain less or not at all (either less capable at paralleriziing, less idle shader units or no idle shader units at all - for example a HD 7970 is hard pressed to have any to "spare")
This is probably a question of what a dedicated benchmark should represent.
Intel, AMD and NVIDIA are all part of Benchmark Development Program. They have source code read access and they can suggest changes and give feedback (with the feedback public within BDP, so any changes they suggest have to be accepted by the other vendors as well while Futuremark retains final say as to what goes into the benchmark).
@Det0x
NV has the biggest marketshare, it would be wise of a company that makes benchmarks to take their opinions as priority. If all the IHVs have to agree on a certain implementation for it to be included, then rest assure, it's targeting the lowest hanging fruit.
What I dislike about using Async Compute to fill in bubbles or use idled shaders, is it has little benefit for GPUs with less shaders or at 4K when shaders are being used (folks can test this with Time Spy, run at 4K, Pascal sees almost no gains). It's not really benefiting more GPUs at all resolutions like a Multi-Engine approach would.
Remember, every GPU has idling Rasterizers & DMAs when Shaders are busy & vice versa under DX11.
What I dislike about using Async Compute to fill in bubbles or use idled shaders, is it has little benefit for GPUs with less shaders or at 4K when shaders are being used (folks can test this with Time Spy, run at 4K, Pascal sees almost no gains). It's not really benefiting more GPUs at all resolutions like a Multi-Engine approach would.
Remember, every GPU has idling Rasterizers & DMAs when Shaders are busy & vice versa under DX11.
Async Compute is only about filling the gaps in the shaders. I hope you dont think that your "rasterizers" or "DMAs" are operating on compute shaders...
Senior engine programmer Jean Geffroy goes into depth on the profound advantages that async compute brings to the table.
"When looking at GPU performance, something that becomes quite obvious right away is that some rendering passes barely use compute units. Shadow map rendering, as an example, is typically bottlenecked by fixed pipeline processing (eg rasterisation) and memory bandwidth rather than raw compute performance. This means that when rendering your shadow maps, if nothing is running in parallel, you're effectively wasting a lot of GPU processing power.
Before the main illumination passes, asynchronous compute shaders are used to cull lights, evaluate illumination from prebaked environment reflections,
compute screen-space ambient occlusion, and calculate unshadowed surface illumination. These tasks are started right after G-buffer rendering has
finished and are executed alongside shadow rendering[...]
http://s3.amazonaws.com/download-aws.futuremark.com/3DMark_Technical_Guide.pdfParticles are simulated on the GPU using asynchronous compute queue. Simulation work is submitted to the asynchronous queue while G-buffer and
shadow map rendering commands are submitted to the main command queue.
Async Compute is only about filling the gaps in the shaders. I hope you dont think that your "rasterizers" or "DMAs" are operating on compute shaders...
You complained that Timespy doesnt use "rasterizers" and "DMAs" concurrently with "shaders". I proofed to you that this is wrong.
Your proof is fanfiction. My proof comes straight from the developer. You can refuse to believe them but i think that would look very foolish...
Async Compute is only about filling the gaps in the shaders. I hope you dont think that your "rasterizers" or "DMAs" are operating on compute shaders...
Async compute is about utilizing "idle" shader units. Slower the card, less idle ones you have.
Ultimately some AMD cards gain quite a bit (ie. they have a lot of shader units idling while rendering and they are very good at using them for the available paraller loads). Some AMD cards gain less or not at all (either less capable at paralleriziing, less idle shader units or no idle shader units at all - for example a HD 7970 is hard pressed to have any to "spare")
Some NVIDIA cards cannot do this at all. The driver simply says "hold your horses, we'll do this nicely in order". Some NVIDIA cards can do some of it. They might use another way than AMD (more driver/software based), but the end result is the same - the card hardware is capable of doing more through some intelligent juggling of the work.
Also, what the devs say on Steam and what they write in the guide conflict. On Steam, they claim they only use it to increase shader utilization, or use idle shaders. In the guide, if it's true, they are running Shaders in parallel while the Rasterizers are working on Shadows.
That's a Multi-Engine approach. The former, dealing with idle shaders only, is not.
Ultimately some AMD cards gain quite a bit (ie. they have a lot of shader units idling while rendering and they are very good at using them for the available paraller loads)
It's one and the same. Shadows are rendered with shaders, but underutilize the gpu because they are typically heavily rop bound. If you're running a compute shader in parallel and performance improves then you are increasing utilization.
"If you look at the portion of the GPU available to compute throughout the frame, it varies dramatically from instant to instant. For example, something like opaque shadow map rendering doesn't even use a pixel shader, its entirely done by vertex shaders and the rasterization hardware -- so graphics aren't using most of the 1.8 teraflops of ALU available in the CUs. Times like that during the game frame are an opportunity to say, 'Okay, all that compute you wanted to do, turn it up to 11 now.'"
Async Compute is only about filling the gaps in the shaders. I hope you dont think that your "rasterizers" or "DMAs" are operating on compute shaders...
English is not my native language, but:
He wrote the exact same thing...