DirectX 12Futuremark 3DMark Time Spy Benchmarks Thread

[3DVagabond]

Because bottlenecks shift when you change resolution.
Lower resolutions stress geometry processors relatively more, leaving more opportunity for performance improvement from async compute.

Is there any source or reference for this? Is this simply assumption?

 

[AnandThenMan]

Mahigan has been correct in the past on other issues, very curious to see how 3DMark will be responding to all this.

We'll get vague speak nothing more. Futuremark wasn't going to make the market share leader look bad that's bad for their business.

 

[Thala]

Is there any source or reference for this? Is this simply assumption?

This is a trivial statement as the numbers of triangles pushed is constant when you increase resolution. There is slightly more work in triangle setup as the vertical span (in screen pixels) of triangles increase.

 

[3DVagabond]

We'll get vague speak nothing more. Futuremark wasn't going to make the market share leader look bad that's bad for their business.

It doesn't seem that nefarious. I think they have simply decided to support only features that both IHV's support. Since nothing above FL11_0 is fully supported by both companies, that's where they stop. Rather than making it unfair it really makes it useless.

 

[sontin]

Mahigan has been correct in the past on other issues, very curious to see how 3DMark will be responding to all this.

No he was not.

Why should Futuremark respond to this? Everybody can use GPUView to look for the reality. Just because some minds dont care about this doesnt mean that Futuremark must respond to fanfiction and lies.

Here is a picture from GPUView. What you are seeing is Async Shaders:

 

[3DVagabond]

This is a trivial statement as the numbers of triangles pushed is constant when you increase resolution. There is slightly more work in triangle setup as the vertical span (in screen pixels) of triangles increase.

It didn't make sense to me but I'm not technically inclined enough to be able to argue it. It appeared to be pure rationalizing to me which is why I asked for some reference to the position.

People just say stuff all of the time. I don't know why. If they don't know something just shut up and let someone who does answer the question. 😀

 

[3DVagabond]

No he was not.

Why should Futuremark respond to this? Everybody can use GPUView to look for the reality. Just because some minds dont care about this doesnt mean that Futuremark must respond to fanfiction and lies.

Here is a picture from GPUView. What you are seeing is Async Shaders:

They offered to answer questions. It's there business to support. Why are you so concerned that they might have to answer questions?

 

[PhonakV30]

(forget about GCN & Pascal , we talk about Maxwell's Score)
if Async on the Maxwell card is disable at the least they should disable Async for Maxwell, how is possible that both test (Async ON & OFF) are the same ?

=(Link)

Then why Maxwell isn't getting loss in Timespy with Async ON?

It could be due to...

• Running compute shaders specifically optimized for nVIDIA GPUs (meaning optimized short running shaders).

• 
  Making very little use of Asynchronous Compute (less than any game title making use of it so far).

• 
  Not running Graphics and Compute in parallel.

=(Link)

You have to separate two things here:
1) Async compute feature in the application
2) Async compute feature in the driver

If you deselect async in Time Spy, then it will submit all tasks to a single queue, therefore the driver won't be able to schedule the tasks in parallel, even if it has that ability.

However, even if Time Spy creates multiple queues, the driver could still put them into a single queue internally (effectively disabling it), if the driver developer thinks this is more efficient than using multiple queues. That is what nVidia chose for Maxwell v2, but not for Pascal.

So, it´s still single queued, the same as toggling the option off, so it´s running async off, doenst matter if it´s the app or the driver doing it, it should be considered an invalid score

Why? The driver/card still does the exact same work. It won't get to skip any bits it can't run asynchronously.

That is like saying that single core processor results should be considered invalid because it runs all the threads of the application on one core.

well, its the same thing as the old benchmark where people shut off Tess for better score yet its still valid. both hardware should run 100% the same way at all times no matter what Drivers wants to do. with that logic if one gpu wants to turn off Tess, this effect, turn off that, and so on because the Driver said so is it still valid?

its removing an action that it should be doing simple because it cant do it. thus all 900s card should become invaid test simple because it does not run the Code as it is sent for better scores.

personily that is my only issue i see here with your Benchmark. the gpu shouldn't be able to do what it wants or doesnt want to do for anything at all no matter what. plus many games does not let you choose if you want Async on/off only a few.

note...that is my only issue really because you want this Bench to reflect real world right? so reflect the real world which may Force Async on 900 cards. so having the ability to let 900 users like myself to see the difference between Async off/on is important.

If we are testing async performance (as well as other dx12 features) why should the score be valid if the driver put´s the commands on a single queue (invalidation the use of async compute)? Well, im thankfull for your answers but my opinion still stands if the hardware cannot support async and this feature is mandatory in the application the score cannot be valid.

We are using a vendors best case scenario in deteriment of other, and that is not fair.

Thank you for taking your time to comment, not being sarcastic, trully appreciated.

 

[YBS1]

That's pretty good. Let us know how the suicide runs go.

Better than expected, I'm not sure how suicidal it is though when the GPUs don't reach 45C and the CPU doesn't reach 70C. The CPU score could use a little work, I've not played with this memory kit enough to know how tight I can run it with the CPU up at this frequency. Still good enough for top 980TI config for the time being, guess I'm happy with that.

http://www.3dmark.com/spy/85279

 

[dogen1]

Is there any source or reference for this? Is this simply assumption?

Source for what? That higher resolutions don't increase the amount of geometry rendered?

 

[AnandThenMan]

It doesn't seem that nefarious. I think they have simply decided to support only features that both IHV's support. Since nothing above FL11_0 is fully supported by both companies, that's where they stop. Rather than making it unfair it really makes it useless.

Well the outcome just happens to be very fortunate for Nvidia. Futuremark had no problems tossing massive amounts of tessellation in but can't be bothered to do async properly? Something stinks here.

 

[PhonakV30]

No he was not.

Why should Futuremark respond to this? Everybody can use GPUView to look for the reality. Just because some minds dont care about this doesnt mean that Futuremark must respond to fanfiction and lies.

Here is a picture from GPUView. What you are seeing is Async Shaders:

He talks about Maxwell not pascal.

 

[3DVagabond]

Source for what? That higher resolutions don't increase the amount of geometry rendered?

Well actually higher res doesn't increase the amount of geometry. A 10K poly model is 10k polies regardless of resolution.

 

[3DVagabond]

Well the outcome just happens to be very fortunate for Nvidia. Futuremark had no problems tossing massive amounts of tessellation in but can't be bothered to do async properly? Something stinks here.

True. I suppose the reasoning would be that AMD did support tessellation it just wasn't as strong. I'm not saying I agree that it should be capped at FL11_0. I strongly believe that it shouldn't. If it would make the app only able to run on AMD though it wouldn't have any use. Maybe they should make it able to run either FL11_0 or FL12_0 and let people see the benefit of the higher feature level?

At this point though it's pretty worthless as a DX12 benchmark if it only runs FL11_0, IMO.

 

[AnandThenMan]

Mahigan has articulated this very well.

It does not matter if Async is not enabled in the driver. That is not the argument. The argument is how Time Spy sends work to the GPU. You see Time Spy has to "mark" every task parallel task (Compute and Graphics) using fences (synchronization point). These fences remain in place even if the driver does not support Asynchronous Compute. These fences show up as a performance loss due to the fact that the GPU resources handling a Graphics task will still "wait" on a long running compute task. This wait is equal to part of the GPU going Idle (Idle as in not doing anything) while it waits for another task to finish.

For Maxwell... this leads to a performance loss. So with 3DMark Time Spy... where is this performance loss on Maxwell?

I mean there are ways you can avert this performance loss...

1. You specifically optimize the code for nVIDIA hardware in that you ensured that there are no long running compute tasks.
2. You keep the level of Async Compute low (which results in less fences) which is perfectly suited for nVIDIA hardware.
3. You do not run Asynchronous Compute + Graphics but instead just Asynchronous Compute (concurrent executions filling up gaps in the pipeline).

Either way... you just optimized everything for nVIDIA hardware yet at the same time claim that creating separate paths for hardware would be tantamount to leading to an optimization war. So AMD hardware received no optimizations while the entire code is optimized for nVIDIA hardware.

That does not sound like an objective way of building a benchmark.

This is precisely why AMD/nVIDIA and Microsoft stated that optimized paths are required for every GPU architecture under DX12. It was an understanding between all three parties which also stated that if you do not have the development time to afford such optimizations then sticking to DX11 would be better.

I think that 3DMark should re-work this benchmark so that it can properly represent the best case scenario for both AMD and nVIDIA.

 

[Zstream]

True. I suppose the reasoning would be that AMD did support tessellation it just wasn't as strong. I'm not saying I agree that it should be capped at FL11_0. I strongly believe that it shouldn't. If it would make the app only able to run on AMD though it wouldn't have any use. Maybe they should make it able to run either FL11_0 or FL12_0 and let people see the benefit of the higher feature level?



At this point though it's pretty worthless as a DX12 benchmark if it only runs FL11_0, IMO.

Pretty much this. I haven't used 3dmark in a really long time for performance analysis in a while. That is, outside of over locking and getting a good idea of where I should sit in terms of other cards.

 

[dogen1]

Well actually higher res doesn't increase the amount of geometry. A 10K poly model is 10k polies regardless of resolution.

Yeah, that's what I was saying and you asked for a source on it lol.

 

[book_ed]

Well actually higher res doesn't increase the amount of geometry. A 10K poly model is 10k polies regardless of resolution.

Only if you keep the field of view and increase de dpi. You can go wider (or really wide through multi display) in which case you get more of those 10k objects to render.

Anyway, 1440p I'm getting 15% and something increase while in mult display I'm getting about 14% and something increase while using the context switching implemented (R290@1100/1425).

 

[Gorbugal]

4260 Time Spy (V1.0)

4321 Graphics Score.
Graphics test 1 29.03 FPS
Graphics test 2 24.14 FPS
CPU test 3950

Modest.

R9 290 1150/1600
4690K @4.4