¿The future of directx 12 nvidia?
  2 / 2    
I will insist on an answer, because I would like to know what you think and if nvidia going to do something about it or just going to take vega with directx 12 and maxwell and pascal forget all of us.
I will insist on an answer, because I would like to know what you think and if nvidia going to do something about it or just going to take vega with directx 12 and maxwell and pascal forget all of us.

#16
Posted 09/14/2016 08:49 AM   
Nvidia Pascal Graphics cards do support Async Compute through the use of a Pre-Emptive scheduler on a hardware level.. This means That when Async Compute is enabled on Nvidia Pascal cards through drivers and the game.. The card will intelligently balance the load between the main graphics pipeline and the Async Compute Pipelines.. When the Devs finally implement DX12 properly.. And Nvidia actually state that Async is enabled through drivers for pascal you will see better gains... But You will only see performance drops for now.. Most games that use DX12 is showing negative gains even on AMD hardware.. So I would not worry about it. This technique of utilising Async Compute will show positive gains when compared with OpenGL and DX11.. But we must wait for Nvidia and Devs to improve the API's and drivers first.
Nvidia Pascal Graphics cards do support Async Compute through the use of a Pre-Emptive scheduler on a hardware level.. This means That when Async Compute is enabled on Nvidia Pascal cards through drivers and the game.. The card will intelligently balance the load between the main graphics pipeline and the Async Compute Pipelines.. When the Devs finally implement DX12 properly.. And Nvidia actually state that Async is enabled through drivers for pascal you will see better gains... But You will only see performance drops for now.. Most games that use DX12 is showing negative gains even on AMD hardware.. So I would not worry about it. This technique of utilising Async Compute will show positive gains when compared with OpenGL and DX11.. But we must wait for Nvidia and Devs to improve the API's and drivers first.

#17
Posted 09/14/2016 10:16 AM   
[quote="Bladestormy"]Nvidia Pascal Graphics cards do support Async Compute through the use of a Pre-Emptive scheduler on a hardware level.. This means That when Async Compute is enabled on Nvidia Pascal cards through drivers and the game.. The card will intelligently balance the load between the main graphics pipeline and the Async Compute Pipelines.. When the Devs finally implement DX12 properly.. And Nvidia actually state that Async is enabled through drivers for pascal you will see better gains... But You will only see performance drops for now.. Most games that use DX12 is showing negative gains even on AMD hardware.. So I would not worry about it. This technique of utilising Async Compute will show positive gains when compared with OpenGL and DX11.. But we must wait for Nvidia and Devs to improve the API's and drivers first. [/quote] thanks, but I see that it will only see gains in 2017, with the engine CryEngine that there is no demos or games directx 12 natives, it may be that tyme spy. My 1060 takes 4660 points, but it is a test not a native game directx 12. Anyway thanks for your answer.
Bladestormy said:Nvidia Pascal Graphics cards do support Async Compute through the use of a Pre-Emptive scheduler on a hardware level.. This means That when Async Compute is enabled on Nvidia Pascal cards through drivers and the game.. The card will intelligently balance the load between the main graphics pipeline and the Async Compute Pipelines.. When the Devs finally implement DX12 properly.. And Nvidia actually state that Async is enabled through drivers for pascal you will see better gains... But You will only see performance drops for now.. Most games that use DX12 is showing negative gains even on AMD hardware.. So I would not worry about it. This technique of utilising Async Compute will show positive gains when compared with OpenGL and DX11.. But we must wait for Nvidia and Devs to improve the API's and drivers first.


thanks, but I see that it will only see gains in 2017, with the engine CryEngine that there is no demos or games directx 12 natives, it may be that tyme spy.

My 1060 takes 4660 points, but it is a test not a native game directx 12.

Anyway thanks for your answer.

#18
Posted 09/14/2016 03:11 PM   
Okay, there is a lot of misunderstanding about async compute. I try to explain the difference as simple as possible. First of all, it is not possible to release a DX12 driver without multi-engine support. Also async compute is not a driver, but a DXGI feature, so every DX12 implementation must support it. For a DX12 application the driver has two choice: place the selected compute pipelines to the independent compute queues, or send them to the OS, which will place them to the graphics queue. NV doing the latter for a lot of DX12 titles. Except Rise of the Tomb Raider (only for Pascal) and 3DMark Time Spy. In the architecture side, the main difference of the IHV implementations is the concurrency and interleaving support. In the practice GCN can work very well with any codepath. Pascal is better than Maxwell, but still not work well with mixed graphics-compute warp interleaving. But it won’t get negative scaling like Maxwell. Probably the secret of GCN is the ability to execute compute pipelines along with any graphics pipeline on the same CU with any state. But there are not much data on how they are doing this. GCN1 is not as good as GCN2/3/4 at this, but it is still the second best desing. The important thing for the devs is to think about what scenarios can work on both AMD and Nvidia. In theory the best scenario for the game engines is to offload the long running compute jobs to a compute queue, so these can run asynchronously with the graphics pipelines, and this is the best case scenario for AMD too. But this is also the worst case scenario for Nvidia, even for Pascal. Now most games are designed for this, and Nvidia can’t handle it well. I think this is an education problem, because most of the devs are not care, or not want to care the architectural differences. In this case they desing their approach for the consoles, which is good for GCN, and that's all. But there is another way. Time Spy use a much safer approach. Not the best for AMD and for NVIDIA, but it can boost the performance on both IHV. For DX12 this problem is manageable for NV. If the async implementation is not good for them, than the driver just refuse the independent placement of the selected compute pipelines, and send them to the OS scheduler. Vulkan will be much harder, because the COMPUTE_BIT flag is a natural state, so the driver will be forced to accept the selected compute pipelines. It will be a funny situation, if the application won't handle the fragmentation explicitly.
Okay, there is a lot of misunderstanding about async compute. I try to explain the difference as simple as possible.

First of all, it is not possible to release a DX12 driver without multi-engine support. Also async compute is not a driver, but a DXGI feature, so every DX12 implementation must support it. For a DX12 application the driver has two choice: place the selected compute pipelines to the independent compute queues, or send them to the OS, which will place them to the graphics queue. NV doing the latter for a lot of DX12 titles. Except Rise of the Tomb Raider (only for Pascal) and 3DMark Time Spy.

In the architecture side, the main difference of the IHV implementations is the concurrency and interleaving support. In the practice GCN can work very well with any codepath. Pascal is better than Maxwell, but still not work well with mixed graphics-compute warp interleaving. But it won’t get negative scaling like Maxwell. Probably the secret of GCN is the ability to execute compute pipelines along with any graphics pipeline on the same CU with any state. But there are not much data on how they are doing this. GCN1 is not as good as GCN2/3/4 at this, but it is still the second best desing.

The important thing for the devs is to think about what scenarios can work on both AMD and Nvidia. In theory the best scenario for the game engines is to offload the long running compute jobs to a compute queue, so these can run asynchronously with the graphics pipelines, and this is the best case scenario for AMD too. But this is also the worst case scenario for Nvidia, even for Pascal. Now most games are designed for this, and Nvidia can’t handle it well.

I think this is an education problem, because most of the devs are not care, or not want to care the architectural differences. In this case they desing their approach for the consoles, which is good for GCN, and that's all. But there is another way. Time Spy use a much safer approach. Not the best for AMD and for NVIDIA, but it can boost the performance on both IHV.

For DX12 this problem is manageable for NV. If the async implementation is not good for them, than the driver just refuse the independent placement of the selected compute pipelines, and send them to the OS scheduler. Vulkan will be much harder, because the COMPUTE_BIT flag is a natural state, so the driver will be forced to accept the selected compute pipelines. It will be a funny situation, if the application won't handle the fragmentation explicitly.

#19
Posted 09/14/2016 05:51 PM   
To extend my earlier post, there are some other differences in DX12. The biggest is the recommendation for the devs about how to use the root signature. AMD, Microsoft and Intel recommends that the root signature should only have pointers to descriptor tables, root signatures, and buffer pointers. Now Nvidia recommends to place constants, CBVs, SRVs and UAVs directly into the root signature. This is a hude difference! And in the reality it doesn't always possible to place buffer views into the root signature. So Nvidia recommends a really questionable approach They don't have much choise, because placing constants and CBVs directly in root will speed up their pixel shader performance, but theres is a catch! There is a reason why Microsoft recommends the "avoid root at all cost" opinion. The devs have to keep track all the descriptor tables or the heaps, because these might use the GPU at some point, and at that point it is not useful to modify them. Now the root signature is not trackable by the developer. If any root argument changes, the driver must maintain a version of all the root arguments. If the devs places constants, CBVs, SRVs and UAVs in the root, than it brings back the DX11-style state change tracking and it can cause a lot of stalls. So on an Nvidia GPU the devs have to choose between the inefficient state change tracking or the reduced pixel shader performance.
To extend my earlier post, there are some other differences in DX12. The biggest is the recommendation for the devs about how to use the root signature. AMD, Microsoft and Intel recommends that the root signature should only have pointers to descriptor tables, root signatures, and buffer pointers. Now Nvidia recommends to place constants, CBVs, SRVs and UAVs directly into the root signature. This is a hude difference! And in the reality it doesn't always possible to place buffer views into the root signature. So Nvidia recommends a really questionable approach They don't have much choise, because placing constants and CBVs directly in root will speed up their pixel shader performance, but theres is a catch! There is a reason why Microsoft recommends the "avoid root at all cost" opinion. The devs have to keep track all the descriptor tables or the heaps, because these might use the GPU at some point, and at that point it is not useful to modify them. Now the root signature is not trackable by the developer. If any root argument changes, the driver must maintain a version of all the root arguments. If the devs places constants, CBVs, SRVs and UAVs in the root, than it brings back the DX11-style state change tracking and it can cause a lot of stalls. So on an Nvidia GPU the devs have to choose between the inefficient state change tracking or the reduced pixel shader performance.

#20
Posted 09/14/2016 06:25 PM   
What a total crappy thread again. Every architecture is as good as well any software can run on it. Even if you accept that GCN architecture can have better GPU utilization in most DX12 apps, which are written for it, it's CURRENTLY worse architecture than Maxwell/Pascal. Here is why: 1. 99% of all games today are OGL, DX11, DX10 and older. Maxwell/Pascal has much better efficiency in those APIs -> better solution for 99% of all apps. 2. There is not a single DX12 ONLY game which would run significantly worse on NVIDIA HW. 3. GCN architecture was designed with DX12 in mind way too soon, which actually backfired to AMD -> bad efficiency in older APIs for years! 4. By the time DX12 will be widely and uniquely supported by games (at least 2-3 years), NVIDIA will have at least VOLTA 2 architecture, which most likely will be the best architecture for the time of purchase again. 5. It's all about speed. I want to play all games at stable 60FPS on maximum details NOW, which AMD doesn't deliver. Cards are getting old because of SPEED not because of architecture. Those 5-10% which you will gain on GPU because of higher efficiency in DX12 are pointless if your GPU is struggling to achieve 30FPS!
What a total crappy thread again. Every architecture is as good as well any software can run on it.

Even if you accept that GCN architecture can have better GPU utilization in most DX12 apps, which are written for it, it's CURRENTLY worse architecture than Maxwell/Pascal. Here is why:

1. 99% of all games today are OGL, DX11, DX10 and older. Maxwell/Pascal has much better efficiency in those APIs -> better solution for 99% of all apps.

2. There is not a single DX12 ONLY game which would run significantly worse on NVIDIA HW.

3. GCN architecture was designed with DX12 in mind way too soon, which actually backfired to AMD -> bad efficiency in older APIs for years!

4. By the time DX12 will be widely and uniquely supported by games (at least 2-3 years), NVIDIA will have at least VOLTA 2 architecture, which most likely will be the best architecture for the time of purchase again.

5. It's all about speed. I want to play all games at stable 60FPS on maximum details NOW, which AMD doesn't deliver. Cards are getting old because of SPEED not because of architecture. Those 5-10% which you will gain on GPU because of higher efficiency in DX12 are pointless if your GPU is struggling to achieve 30FPS!

#21
Posted 09/14/2016 06:33 PM   
any good answer to explain the problem nvidia directx 12 and Vulkan ?.
any good answer to explain the problem nvidia directx 12 and Vulkan ?.

#22
Posted 09/18/2016 12:57 AM   
[quote="Bladestormy"]Nvidia Pascal Graphics cards do support Async Compute through the use of a Pre-Emptive scheduler on a hardware level.. This means That when Async Compute is enabled on Nvidia Pascal cards through drivers and the game.. The card will intelligently balance the load between the main graphics pipeline and the Async Compute Pipelines.. When the Devs finally implement DX12 properly.. And Nvidia actually state that Async is enabled through drivers for pascal you will see better gains... But You will only see performance drops for now.. Most games that use DX12 is showing negative gains even on AMD hardware.. So I would not worry about it. This technique of utilising Async Compute will show positive gains when compared with OpenGL and DX11.. But we must wait for Nvidia and Devs to improve the API's and drivers first. [/quote] no. just no. please stop perpetuating this sillyness. pre-emption is not async.
Bladestormy said:Nvidia Pascal Graphics cards do support Async Compute through the use of a Pre-Emptive scheduler on a hardware level.. This means That when Async Compute is enabled on Nvidia Pascal cards through drivers and the game.. The card will intelligently balance the load between the main graphics pipeline and the Async Compute Pipelines.. When the Devs finally implement DX12 properly.. And Nvidia actually state that Async is enabled through drivers for pascal you will see better gains... But You will only see performance drops for now.. Most games that use DX12 is showing negative gains even on AMD hardware.. So I would not worry about it. This technique of utilising Async Compute will show positive gains when compared with OpenGL and DX11.. But we must wait for Nvidia and Devs to improve the API's and drivers first.


no.

just no.

please stop perpetuating this sillyness. pre-emption is not async.



In Memory of Chris "ChrisRay" Arthington, 1982-2010

Specs:
CPU:Intel Xeon x5690 @ 4.2Ghz, Mainboard:Asus Rampage III Extreme, Memory:48GB Corsair Vengeance LP 1600
Video:EVGA Geforce GTX 1080 Founders Edition, NVidia Geforce GTX 1060 Founders Edition
Monitor:ROG PG279Q, BenQ BL2211, Sound:Creative XFI Titanium Fatal1ty Pro
SDD:Crucial MX300 275, Crucial MX300 525, Crucial MX200 250
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Phantom 820, PSU:Seasonic X-850, OS:Windows 7 SP1
Cooler: ThermalRight Silver Arrow IB-E Extreme

WIP:
CPU:Intel Xeon x5660, Mainboard:Asus Rampage II Gene, Memory:16GB Corsair Vengeance 1600 LP
Video:EVGA Geforce GTX 680+ 4GB, Palit Geforce GTX 550ti
Monitor:Pending, Sound:Pending
SDD:Pending
HDD:Pending
Case:NZXT Guardian 921RB, PSU:Corsair 620HX, OS:Windows 7 SP1
Cooler: ThermalRight True Spirit 120M

#23
Posted 09/18/2016 12:59 AM   
please answer nvidia someone who says what really happens and we have to wait for the drivers and if this would improve ahead of 2017.
please answer nvidia someone who says what really happens and we have to wait for the drivers and if this would improve ahead of 2017.

#24
Posted 09/18/2016 12:59 AM   
The old cards i have now are not dead yet so what is the rush? I figure it takes games and video cards at least a year to get a new version of DirectX figured out. Then there are the driver issues that plague the sector too. my advise, refill your coffee and kick back and wait till next year for a new video card
The old cards i have now are not dead yet so what is the rush?

I figure it takes games and video cards at least a year to get a new version of DirectX figured out. Then there are the driver issues that plague the sector too.

my advise, refill your coffee and kick back and wait till next year for a new video card

Image
Corsair Carbide 300R, Corsair TX850V2, Asus PA238QR HDMI+DP+DVI+VGA
Asus HD7870-DC2-2GD5-V2 / EVGA GTX 660 Ti FTW Signature 2 and box of several others.

Follow me Twitter and on YouTube

I have been a vegan since 1969. I have experienced more prejudice than anyone could possibly ever imagine.

#25
Posted 09/18/2016 06:31 PM   
DX12 is still going to be a good while before games start to really take off with the new API. But I do think Nvidia is simply marketing the cards, sure they will work with DX12, but its not like what the make it out to be, they seem to be ignoring the fact that some Nvidia cards actually decrease in performance with DX12 enabled. Its mostly to get ya'll to buy their cards by slapping a DX12 sticker on the box. Its like slapping a Lambo sticker on a Honda.
DX12 is still going to be a good while before games start to really take off with the new API. But I do think Nvidia is simply marketing the cards, sure they will work with DX12, but its not like what the make it out to be, they seem to be ignoring the fact that some Nvidia cards actually decrease in performance with DX12 enabled. Its mostly to get ya'll to buy their cards by slapping a DX12 sticker on the box. Its like slapping a Lambo sticker on a Honda.

OS: Windows 8.1 x64
CPU: Intel Core i7 3770s 4.2ghz
RAM: 32GBGB Corsair Vengeance 2400mhz
VIDEO: 2x GTX 780 ti's
MOBO: Asus P8Z77-V
PSU: EVGA Supernova G2 1300watt

#26
Posted 09/19/2016 12:54 PM   
  2 / 2    
Scroll To Top