I meant GPUs don't need to support Async Compute to be labeled DX12 compatible. Example, Fermi, Kepler, Maxwell etc.
It's an optional feature.
My understanding is that the lower level nature of Direct3D 12/Vulkan exposes a GPU's asynchronous compute capabilities for programmers to use, thus making D3D12/Vulkan support a prerequisite for asynchronous compute, but technically asynchronous compute is still not an official feature of those APIs.
On the subject of asynchronous compute and Time Spy, for kicks I switched my brother's Radeon 260X into my PC so I could test it (Time Spy refuses to run on his PC for whatever reason). I had seen results from that Overclock3D thread with a 7870 showing no gain from asynchronous compute, and Mahigan explained that's probably because at that level and below all of the GPU's compute power is probably being used already. When a GPU can't provide the resources for async compute, it can even cause internal lag and slow down rendering, as seen with Maxwell chips trying to use a-compute at crazy detail levels in AOTS vs running with a-compute turned off. My tests showed that to pretty much be the case with a 260X -- there was no benefit from turning a-compute on, and in fact the scores with a-compute on were slightly lower than the scores with it off.
Point is, asynchronous compute, at least its implementation in Time Spy, does not help low-end AMD GPUs like the 260X.
The misunderstanding stops at the above reply as for that anecdote as long as the app can push the rasterizer hard enough and the shading work can be done independently you will pretty much see a gain with async compute ...
I get that but my point was that async compute IS tied to a feature level and the same goes for resource binding along with ExecuteIndirect funtionality ...
I meant GPUs don't need to support Async Compute to be labeled DX12 compatible. Example, Fermi, Kepler, Maxwell etc.
It's an optional feature.
I think the FL_11 approach is fine -- provided they are planning on a real FL_12 test too. I would expect this is just the first couple of tests. I bet there will be a VR focused one, as well as a FL_12 one coming in the future too.
That is indeed the long term plan. Tho first we'll release VRMark which is designed for "lowest common denominator in VR", so, DX11 - but that is a separate product, not part of 3DMark.
Some background on Time Spy;
- Initially Time Spy was targeted for launch late 2015 / early 2016. Back then the availability of graphics cards that could actually support FL12 was.. umm... "limited". Unfortunately both maturity of DX12 drivers and some really complex issues in implementing a brand new DX12 engine delayed it considerably. Patching a benchmark workload after the fact is really really really bad, so we rather take the time to do it right.
- Average consumers take it REALLY badly if a new benchmark says "you can't run it on your brand new (well, 3 year old) system because of X". This also directed to supporting FL11. On CPU test we took a "bold step" of requiring SSSE3 and.. uuh.. I've apologized today already to four customers that no, their Phenom II or Opteron can't run the test.
- A FL12 benchmark with fallbacks to FL11 would not really be feasible - it would basically be two separate benchmarks. FL12 adds some interesting features and fully exploiting those would take a dedicated approach.
So I'd say Time Spy is a legit tool that will reflect how games could perform when a pure DX12 engine targets the most widely used hardware base (ie, DX12 FL11). Yes, some newest cards could use code paths for FL12 and I'm sure some games will offer those, but the pool of compatible hardware is still very small. This is, after all, our first full blown DX12 benchmark, so have to start from the obvious first step.
- Pretty much all games target DX12 FL11 and even there most current game engines are doing DX12 in a way that is "oh we just ported our DX11 code". Time Spy is at least taking one step further with an engine developed from the ground up 'the DX12 way' (which is one of the reasons why it took a while - oh the tales our engine team could tell of DX12 features where spec says one thing and driver implementations do... other things. A phrase "What? Nobody is doing it like this" is something that was told to us by driver developers more than once...).
Buzzkiller, have you been able to read through the documentation for time spy? I'm curious what you think of their implementation of async compute and if it really allows for concurrent rendering and compute functionality or not.
No, that's not true. Async and ExecuteIndirect are not bound to feature levels. Only resource binding is feature level bound. Async compute can be used in any feature level of DX12 and is a basic feature. All DX12 games at the moment use feature level 11_0, so following your argumentation, there would be no game with async. But that's not the case.
Core 2 supports SSSE3... according to https://en.wikipedia.org/wiki/SSSE3@FM_Jarnis, I just realized you may have just explained why my brother's PC won't run Time Spy. His PC uses an old Core 2 Quad Q6600. Does that not use SSSE3 and thus is not supported by Time Spy?
@FM_Jarnis, I just realized you may have just explained why my brother's PC won't run Time Spy. His PC uses an old Core 2 Quad Q6600. Does that not use SSSE3 and thus is not supported by Time Spy?
Edit: Ha, I actually posted my problem to Futuremark's support forum earlier today, and I'm just now seeing that you already responded to my post there. I'll follow your suggestion and let you know over at the support forum if it works.
Core 2 supports SSSE3... according to https://en.wikipedia.org/wiki/SSSE3
@FM_Jarnis
Thanks for giving your input, it adds to the transparency in how features are used, but looking at your response, it's almost like Time Spy targets the lowest hanging fruit. In which case, more capable hardware are not fully taken advantage of, yet.
Whatever you mean by "documentation" I can not get internal info as I am not on the team behind 3Dmark nor can I give any thoughts on their implementation of async compute since there's not enough available public information or access to the source code ...
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
So, am I understanding you correctly that if a feature isn't supported by all or a lot or all brands... you guys won't support it? For example AMD has ACE's and nVidia doesn't. So, you won't have anything in the benchmark that requires their usage?
Yes they are! Anyone saying otherwise is spreading misinformation ...
Async compute can NOT be used on just any feature levels since it requires a different RUNTIME EXCLUSIVE to that feature level and above ...
Just because games only require FL 11_0 doesn't mean that you can't build them around MULTIPLE feature levels ...
That is indeed the long term plan. Tho first we'll release VRMark which is designed for "lowest common denominator in VR", so, DX11 - but that is a separate product, not part of 3DMark.
Some background on Time Spy;
- Initially Time Spy was targeted for launch late 2015 / early 2016. Back then the market share of graphics cards that could actually support FL12 was.. umm... "limited". Unfortunately both maturity of DX12 drivers and some really complex issues in implementing a brand new DX12 engine delayed it considerably. Patching a benchmark workload after the fact is really really really bad, so we rather take the time to do it right.
- Average consumers take it REALLY badly if a new benchmark says "you can't run it on your brand new (well, 3 year old) system because of X". This also directed to supporting FL11. On CPU test we took a "bold step" of requiring SSSE3 and.. uuh.. I've apologized today already to four customers that no, their Phenom II or Opteron can't run the test.
- A FL12 benchmark with fallbacks to FL11 would not really be feasible - it would basically be two separate benchmarks. FL12 adds some interesting features and fully exploiting those would take a dedicated approach.
So I'd say Time Spy is a legit tool that will reflect how games could perform when a pure DX12 engine targets the most widely used hardware base (ie, DX12 FL11). Yes, some newest cards could use code paths for FL12 and I'm sure some games will offer those, but the pool of compatible hardware is still very small. This is, after all, our first full blown DX12 benchmark, so have to start from the obvious first step.
- Pretty much all games target DX12 FL11 and even there most current game engines are doing DX12 in a way that is "oh we just ported our DX11 code". Time Spy is at least taking one step further with an engine developed from the ground up 'the DX12 way' (which is one of the reasons why it took a while - oh the tales our engine team could tell of DX12 features where spec says one thing and driver implementations do... other things. A phrase "What? Nobody is doing it like this" is something that was told to us by driver developers more than once...).
"oh the tales our engine team could tell of DX12 features where spec says one thing and driver implementations do... other things. A phrase "What? Nobody is doing it like this" is something that was told to us by driver developers more than once.."
I take this to mean that you worked closely with the driver teams of Nv/AMD/Intel?
Of course this involves guesswork, but we've been doing this for almost 20 years and in general 3DMark has been fairly good predictor as to what games do 2-3 years into the future."So I'd say Time Spy is a legit tool that will reflect how games could perform when a pure DX12 engine targets the most widely used hardware base "
What does this mean, and how can you determine what the future games will be targeting ?
@FM_Jarnis, I just realized you may have just explained why my brother's PC won't run Time Spy. His PC uses an old Core 2 Quad Q6600. Does that not use SSSE3 and thus is not supported by Time Spy?
Edit: Ha, I actually posted my problem to Futuremark's support forum earlier today, and I'm just now seeing that you already responded to my post there. I'll follow your suggestion when I get the chance and let you know over at the support forum if it works.
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).
That anecdote mostly refers to the situation that, at least a few months ago, vast majority of other developers were doing DX12 ports of DX11 engines (ie. adding a DX12 path to a DX11 engine & art pipeline), instead of total DX12 rewrites and our engine being "DX12 only", a lot of interesting things were discovered. Many bugs were squashed all over the place (no names, sorry).
Of course this involves guesswork, but we've been doing this for almost 20 years and in general 3DMark has been fairly good predictor as to what games do 2-3 years into the future.
In this case, our educated guess is that nobody will be making games anytime soon that would require FL12 hardware and there will be very few, if any games that spend the time & money to write a separate FL12 codepath when DX12 FL11 works just fine and is compatible with a far larger set of hardware.
You can freely disagree - this is just an opinion.
Point is, asynchronous compute, at least its implementation in Time Spy, does not help low-end AMD GPUs like the 260X.
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).
That anecdote mostly refers to the situation that, at least a few months ago, vast majority of other developers were doing DX12 ports of DX11 engines (ie. adding a DX12 path to a DX11 engine & art pipeline), instead of total DX12 rewrites and our engine being "DX12 only", a lot of interesting things were discovered. Many bugs were squashed all over the place (no names, sorry).
Of course this involves guesswork, but we've been doing this for almost 20 years and in general 3DMark has been fairly good predictor as to what games do 2-3 years into the future.
In this case, our educated guess is that nobody will be making games anytime soon that would require FL12 hardware and there will be very few, if any games that spend the time & money to write a separate FL12 codepath when DX12 FL11 works just fine and is compatible with a far larger set of hardware.
You can freely disagree - this is just an opinion.