Err... Kepler simplified the hardware scheduler, not removed it... in the hardware, it needs to have a scheduler to keep track on which SM is idle, which SM can be retasked.. and so on. It is not reasonable if this tasks need to go back to CPU due to latency.

From their Kepler whitepaper:


As far as the Gigathread is concerned, it has 32 hardware managed queues that can support graphics/compute tasks. It seems it can be repurposed using driver.
GTX970: http://vulkan.gpuinfo.org/displayreport.ph...7#queuefamilies
R9 200 series: http://vulkan.gpuinfo.org/displayreport.ph...4#queuefamilies

If you noticed,
GTX970: 16 queues that can support GRAPHIC/COMPUTE/TRANSFER, 1 queue that can support TRANSFER
R9 200 series: 1 queue that can support GRAPHIC/COMPUTE/TRANSFER, 7 queue that can support COMPUTE/TRANSFER, 2 queue that can support TRANSFER

Few reasons:-
1) NVIDIA Vulkan driver has not exposed compute-only queues. Probably won't make much of a difference.
2) Not just Maxwell 2 showing small gains. Pascal too showing small gains. But a gain is a gain. As you can see in the graph you posted, GTX980Ti showing higher gains than GTX1070. This video shows it too: https://www.youtube.com/watch?v=ZCHmV3c7H1Q
3) NVIDIA GPUs already has almost peak utilization averagely.
4) Some scene showing large gains too on NV hardware. Large gains also in some CPU limited scene.
5) This game has AMD shader intrinsic function (specific to AMD). It is not supported by NVIDIA shader extension in current Vulkan driver.
6) AMD FuryX has 23% more compute performance than GTX1070. At peak, it will perform 23% faster. So, it is performing as it should.
7) As mentioned before, AMD OpenGL driver has high overhead issue. Once this issue is not there, it will perform as it should. If NVIDIA cripple their OpenGL driver, you'd see significant gains too going to Vulkan (do people prefer this?). There's obviously something wrong if GTX970 can perform similar to FuryX in OpenGL mode...If Fury X can outperform GTX1080 in Vulkan, then that means NVIDIA is not performing as good as AMD in Vulkan. But it is not the case here, GTX1080 is still leading.

What is meant by simpler scheduler is this:
In a hardware/dynamic scheduler, there will be a hardware to re-order instructions at runtime for performance reason. In other words, there's a hardware in the scheduler to optimize the algorithm.

In a compiler/static scheduler, this re-ordering/optimization of instruction is done during code compilation. (As it is possible to predict the instruction anyway.. e.g. an add operation will always go through the same instruction) It is using compiler to create the best optimized order of instruction. Hence, why it is labelled as software scheduler.

You can read more on static vs dynamic scheduler for more info.

But the hardware to perform task allocation is still there. Don't worry Even a warp scheduler in each SM is also considered as a scheduler. It still need some hardware to decode the instruction and send it to SM to crunch.

The Gigathread is a well kept secret on NVIDIA side. No one knows (except NVIDIA) how it is internally. They don't clearly label it as 32 graphic processors engine or so in any presentation. It is one of the reason why it can crunch DX11 games so efficiently too.

http://www.pcper.com/reviews/Graphics-Card...ute-Performance

http://www.guru3d.com/articles-pages/futur...k-review,1.html

With GTX1080

FuryX performance is...lacking...it should be able to zip through GTX1070 with its shader perf..

This post has been edited by Demonic Wrath: Jul 15 2016, 08:14 AM

Hype or rumors (is there even a hype or rumor on this lol?).. doesn't matter.. it's a fact that Furies have higher shader performance.. just saying..

I was also comparing it against its own 28nm brethen R9 390X. It is weird that Fury having much higher shader perf (1.27x higher) doesn't have much higher perf compared to R9 390X.. mainstream cards are performing as expected though.. if I'm not wrong, it should be tessellation bottleneck..

There's also this.. well, AMD cannot push their shader intrinsic stuff into this benchmark as it is AMD specific codes.


This post has been edited by Demonic Wrath: Jul 15 2016, 10:23 AM

I'm not sure what you're getting at here . Higher core counts and higher clocks will benefit in heavily threaded app if the difference in arch is not much.

In heavily threaded app, your i7-4930K will beat i7-6700K Skylake. Skylake is faster because it has higher IPC and clock speed in games (prefer faster core compared to more cores). In Firestrike Phsyics score, 4930K will score higher than 6700K. I'm pretty sure video encoding will be faster on your 4930K too. The keyword here is heavily threaded app. Please don't be disappointed

First, going from Ivy Bridge to Skylake, Intel has increased the clock speed and IPC performance. R9 390X and Fury has the same IPC performance. R9 390X and Fury also has similar clock speed. So the difference is core count and raw shader performance (TFlops). Now it is only 5% higher on the Time Spy benchmark. Clearly something is being bottlenecked for Fury series. You wouldn't expect GTX1060 to beat GTX980Ti just because it is new architecture right?

Secondly, graphics are heavily threaded app. So higher cores and higher clocks will beat lower cores and lower clocks with same architecture. R9 390X and Fury has the same GCN architecture. Heck, AMD has increased Fury efficiency in tessellation too. So Fury should have a bigger difference in performance compared to 390X.

Cheers.

This post has been edited by Demonic Wrath: Jul 15 2016, 11:24 AM

Haha, its ok.

My next upgrade will need to be at least 4x GTX970 perf. So, just wait. Now GTX1080 is only 2x GTX970 perf. Even GTX1080Ti with 3584 cores is only 1.4x GTX1080, so only 2.8x GTX970.

Now need to upgrade monitor first.

Just right I think it's almost 4x jump? Last time I jumped from GTX460 to GTX970 lol.

Monitor last longer ma.. GPU too fast update..

Waiting for 27" QHD or 3440x1440(?) G-sync HDR 144Mhz IPS. Sure expensive lol.

This post has been edited by Demonic Wrath: Jul 15 2016, 04:08 PM

I might be wrong but it's not HDR monitor right? But I'd agree it's a very good monitor for gaming.

You need to go to the Custom Run to disable.

RX480 doesn't have poor mid-range performance... if someday AMD manage to fix their DX11 and OpenGL driver, it will perform like GTX980 consistently. It is also limited by the reference cooler and power delivery. Aftermarket RX480 should be good, but the price might not be.

NV drivers already have compute-only queue that supports DX12 for Pascal GPUs (can be seen using GPUview, there's an additional COMPUTE_1 queue). Their Vulkan driver haven't expose it (can be confirmed in the VulkanCapsViewer on queue families).

"Asynchronous Shaders" and "Asynchronous Compute" is the same thing lol. Async Shaders are just an alternative term AMD use for Async Compute. Async Computing term is used even in their "Async Shader" whitepaper. The reason why it is termed as "Async Shader" is because the compute shader can be run async with the graphic pipeline.

There is no such thing as "dedicated async shaders".

Shaders in computer is defined as "computer program that is used to do shading". So having "dedicated async shaders" literally means "dedicated computer program that is used to do shading"..

Unless that term is for dedicated ACEs.

ACEs on AMD are dynamic schedulers that reorder and issue compute workload to the CUs. ACEs don't do the calculation. The calculations are still done on the Compute Units..

ACEs however, can schedule compute task independent of Graphic Processor.

ACEs are used for scheduling compute task, not to perform compute.

Having more ACE ≠ faster compute performance
Scheduling task ≠ Performing computing

The reason why in DX11 AMD is slow is very likely because the AMD driver only talks to the Graphic Processor. So the Graphic Processor couldn't schedule the task fast enough to feed the massive amount of compute units. Imagine having 1 company manager issuing task to 100 employees.

With DX12, the AMD driver is mapped correctly to the GCP + ACEs. Then you'll have more managers issuing task to 100 employees.

--
Maxwell is partitioned in SM, too not GPC. Each SM can do different kernels, independent of other SMs.

Yes, and NVIDIA already presented on Async Compute on Maxwell and Pascal. Static Partitioning and Dynamic Partitioning solution for Asynchronous Computing.

As for the "slow" context switch. A context switch takes about 20 microseconds. The issue on Maxwell is not about the context switch time for Async Compute. The issue is when the workload is imbalanced i.e. compute workloads taking a longer time to complete. Those workloads need to be completed first before a context switch can happen. This is potentially hazardous for Maxwell and make it perform slower. This is also why I think NVIDIA won't ever enable async queues on Maxwell.

Thirdly, my post is about the so-called "dedicated async shader" on AMD card. The way those redditors point out is like AMD having this "dedicated async shader" unit that allows compute to be offloaded. This is simply not true about the ACEs. It's almost like saying having a "dedicated PhysX card" that allows PhysX calculation to be offloaded.

Just FYI, even AMD GCN optimization guidelines also mention:

If the application is doing graphics + compute switch too often for drawing a frame, that means something is wrong with the app already.

But yes, theoretically, if accounting for 20 µs context switching every frame, it will have on average 5-8% idling time (i.e. 5-8% performance loss). Oh wait, that's the perf gain from enabling Async Compute on Pascal lol.

Again, the simple look at the difference in arch is misleading.

The Queue and Work Distributor is in hardware. The purpose of Work Distributor is to, as its name indicate, distribute work between SMs. If the SM needs to send its results back to the CPU to redistribute work between SMs, the latency cost would be too high. On a graphic pipeline, the data and instructions will need to go through the Work Distributor and the SMs multiple times. They wouldn't be able to get this kind of performance if they do this.

The driver queue, however, is in software. This is the same for both AMD and NVIDIA. The driver queue will send its data to the hardware queue to process.

Even the simplified look and the beyond3d post (by Ext3h) you linked show different things. Ext3h post indicates the queues, work distributor is in hardware. The simplified look indicates it is in software.

I would suggest you to go through the sources you link first before posting here to avoid misleading people..

Fun fact: My post isn't about whether Maxwell can or cannot do Async. That post was whether the unit is in hardware or software.

I didn't in my post mention that Maxwell v2 Async works the same as ACE. My point was that there's a hardware unit on NVIDIA that performs the equivalent task as (GCP + ACEs), it might not have the same capability but its purpose is the same, that is, to schedule and distribute task to the SMs/CUs. This unit is in hardware. You were saying this hardware unit is actually in software.

Even the sources that you posted contradicts between themselves.

Wow rm200 discount.. thats a lot.

Seems GTX1080 can get more perf from faster memory overclock.



This post has been edited by Demonic Wrath: Jul 17 2016, 11:38 PM

Wow that cable routing is really something.. You need to do something on the cable routing...

https://www.chiphell.com/thread-1618219-1-1.html

Time Spy: GTX1060 - 4100 score only