Guru3D Thermal Paste Roundup 2019
Back-to-school Microsoft Office 2016 $18 Win 10 Pro $12
TeamGroup T-Force Vulcan 1TB SSD Review
Corsair K57 RGB Wireless keyboard review
AMD Ryzen 7 3800X review
PowerColor 5700 RED DEVIL review
MSI Radeon RX 5700 XT Evoke review
ASUS Radeon RX 5700 XT ROG STRIX review
ViewSonic Elite XG240R Monitor Review
Promo: URCDKey Summer Sale Windows 10 Pro for $11
AMD Could Do DLSS Alternative with Radeon VII through DirectML API
There is an interesting development, as you know the GeForce RTX graphics cards have tensor cores, dedicated cores for optimizing and accelerating anything AI and Deep Learning. A spawn from that technology for gaming is DLSS, which NVIDIA is marketing strongly. With the October 2018 update for Windows 10, Microsoft has released the DirectML API for DirectX 12.
ML stands for Machine Learning - and makes it possible to run trained neural networks on any DX12 graphics card. Basically, the Deep Learning optimization or algorithm if you will, becomes a shader that can be run over the traditional shader engine, without a need for tensor cores. In an interview with AMD they mention that the team is working on this and it seems, Radeon VII seems very well suited for the new API. Japanese website 4gamer.net spoke with AMD marketing manager Adam Kozak, AMD is currently testing DirectML with Radeon VII and was positively impressed by the results, and that is exciting news for AMD offering them an AI/DL alternative.
While AMD is testing this on Radeon VII, logic obviously dictates that it would work well on Radeon RX Vega 64 and Radeon RX Vega 56 as well. This allows, for example, an alternative implementation to Nvidia's DLSS.
Only 1+1=2
Of course, should this become an actual supported thing, then it can't be addressed AMD alone, this question remains: will game developers actually implement, experiment and integrate support for DX ML into games?
It also has to be said, it works reversed, DirectML could also make use of Nvidia's Tensor cores, certainly giving them an advantage. As the Radeon card would see a performance hit, whereas the RTX cards can simply offload the algorithm towards its Tensor cores. Time will tell, but this certainly is an interesting development as long as your graphics card is powerful enough, of course.
AMD Could take Back 30% of the Processor Market - 09/26/2018 07:55 AM
Good times for AMD. Intel is under a lot of scrutinies lately, scandals with their top-tier staff, issues with 14nm production, delays at 10nm and vulnerabilities are only a few of them. Meanwhile...
AMD Could Potentially Get 19B investment - 02/11/2015 10:48 AM
More news from AMD today as it seems the company might get a nice cash injection. Loongson Technology, a CPU joint venture between Beijing-based chip designer BLX IC Design Corp, the Chinese Academy ...
AMD could be restructuring once more - 10/06/2014 10:04 AM
BSN reported earlier that AMD might be preparing one more round of restructuring, a pretty significant one as well. The reorganization would be announced later this month. Sources claim the restruct...
AMD could ship 28nm GPUs in December - 10/18/2011 10:45 AM
We can confirm this rumor as AMD has been 'carefully' talking about it. AMD might still be planning to introduce some 28nm GPUs in the second week of December. It's expected that these chips will be ...
AMD could ship 8 million Llano APUs this year - 08/05/2011 10:22 AM
AMD is doing well with Llano alright, Sources at motherboard makers told DigiTimes that AMD shipped about 1 million Llano APUs in June and 1.3-1.5 million units in July. Total shipments for 2011 are e...
Fox2232
Senior Member
Posts: 9545
Joined: 2012-07-20
Senior Member
Posts: 9545
Joined: 2012-07-20
#5637471 Posted on: 02/09/2019 08:01 AM
Both RT cores and tensor cores are present inside the same streaming multiprocessor as main SPs/SIMDs (you really shouldn't call them "shaders") and all three are built from separate transistors. Theoretically all three units should be able to run in parallel but on Turing this is limited (by available intra-SM bandwidth and data paths most likely) in such a way that RT and SIMDs can run in parallel but tensors and SIMDs can't (hence this frame graph).
Shader code is any code and any code can be whatever "true" or not raytracing code too. DXR can be used for full path tracing (which is what I assume you mean by "true raytracing") just as well as some hybrid raster+RT solutions (like that of BFV) - it all depends on the code. DXR has no limitations here.
Weird, I do remember YT discussion with that nVidia's engineer who IIRC said that RT is not done in parallel with shading, but tensors execution being separate... hence the other thread and actual benchmark.
On other hand die shot confirms that tensors are incorporated in SMs. (You are right there.) But that image you posted is just fictional workload and does not say anything about parallel execution. (Other than that nVidia believes that in their example 2080 Ti does 78 of something they decided not to name... maybe General TOPs?.)
If one took it as it is there, then there would be no parallel execution at all. As that's die shot and few blurry rectangles driven over other SMs instead of showing overlap. But then in numbers they show total of 168% of different workload types. Actual benchmarks are yet to confirm even those separate 100TFLOPs (10 Gigarays) or 114 FP16 Tensor FLOPs... Interestingly enough written as FLOPs not TFLOPs.
If nVidia made that image for some purpose, it was to confuse people.
Both RT cores and tensor cores are present inside the same streaming multiprocessor as main SPs/SIMDs (you really shouldn't call them "shaders") and all three are built from separate transistors. Theoretically all three units should be able to run in parallel but on Turing this is limited (by available intra-SM bandwidth and data paths most likely) in such a way that RT and SIMDs can run in parallel but tensors and SIMDs can't (hence this frame graph).
Shader code is any code and any code can be whatever "true" or not raytracing code too. DXR can be used for full path tracing (which is what I assume you mean by "true raytracing") just as well as some hybrid raster+RT solutions (like that of BFV) - it all depends on the code. DXR has no limitations here.
Weird, I do remember YT discussion with that nVidia's engineer who IIRC said that RT is not done in parallel with shading, but tensors execution being separate... hence the other thread and actual benchmark.
On other hand die shot confirms that tensors are incorporated in SMs. (You are right there.) But that image you posted is just fictional workload and does not say anything about parallel execution. (Other than that nVidia believes that in their example 2080 Ti does 78 of something they decided not to name... maybe General TOPs?.)
If one took it as it is there, then there would be no parallel execution at all. As that's die shot and few blurry rectangles driven over other SMs instead of showing overlap. But then in numbers they show total of 168% of different workload types. Actual benchmarks are yet to confirm even those separate 100TFLOPs (10 Gigarays) or 114 FP16 Tensor FLOPs... Interestingly enough written as FLOPs not TFLOPs.
If nVidia made that image for some purpose, it was to confuse people.
dr_rus
Senior Member
Posts: 2980
Joined: 2007-04-17
Senior Member
Posts: 2980
Joined: 2007-04-17
#5637535 Posted on: 02/09/2019 01:04 PM
It actually does say everything about parallel execution as it shows what can be run in parallel inside one frame. RT cores do BVH traversal and this can be done in parallel to FP32 CUDA cores/FP16 tensor cores workload.
Don't pay attention to the die shot and its coloring. In fact, I'm not so sure that we've even seen a real die shot of any TU10x chip so far - most of what is available on the web seems more like artistic representations (i.e. fake drawings).
But that image you posted is just fictional workload and does not say anything about parallel execution.
It actually does say everything about parallel execution as it shows what can be run in parallel inside one frame. RT cores do BVH traversal and this can be done in parallel to FP32 CUDA cores/FP16 tensor cores workload.
As that's die shot and few blurry rectangles driven over other SMs instead of showing overlap.
Don't pay attention to the die shot and its coloring. In fact, I'm not so sure that we've even seen a real die shot of any TU10x chip so far - most of what is available on the web seems more like artistic representations (i.e. fake drawings).
Fox2232
Senior Member
Posts: 9545
Joined: 2012-07-20
Senior Member
Posts: 9545
Joined: 2012-07-20
#5637559 Posted on: 02/09/2019 02:49 PM
It actually does say everything about parallel execution as it shows what can be run in parallel inside one frame. RT cores do BVH traversal and this can be done in parallel to FP32 CUDA cores/FP16 tensor cores workload.
Don't pay attention to the die shot and its coloring. In fact, I'm not so sure that we've even seen a real die shot of any TU10x chip so far - most of what is available on the web seems more like artistic representations (i.e. fake drawings).
Yes, it kind of hints it. I think I decoded those numbers below for magical flops. But As they suggest that RT is squeezed in between Shader execution, why is there that drastic fps drop in DX-R game like BF 5?
1st "14 * 80%" says that for 80% of frame time FP32 shading is used, last "114 * 20%" that DNN processing is used.
Then there is "100 * 40%" for raytracing which on frame time is displayed as in parallel ("/ /" sign) with FP32 shading. And "14 * 28%" for INT32 shading run in some other mode (" + " sign) with FP32 shading too.
But it does not add up to reality where DX-R doubles time it takes to render frame, right?
It actually does say everything about parallel execution as it shows what can be run in parallel inside one frame. RT cores do BVH traversal and this can be done in parallel to FP32 CUDA cores/FP16 tensor cores workload.
Don't pay attention to the die shot and its coloring. In fact, I'm not so sure that we've even seen a real die shot of any TU10x chip so far - most of what is available on the web seems more like artistic representations (i.e. fake drawings).
Yes, it kind of hints it. I think I decoded those numbers below for magical flops. But As they suggest that RT is squeezed in between Shader execution, why is there that drastic fps drop in DX-R game like BF 5?
1st "14 * 80%" says that for 80% of frame time FP32 shading is used, last "114 * 20%" that DNN processing is used.
Then there is "100 * 40%" for raytracing which on frame time is displayed as in parallel ("/ /" sign) with FP32 shading. And "14 * 28%" for INT32 shading run in some other mode (" + " sign) with FP32 shading too.
But it does not add up to reality where DX-R doubles time it takes to render frame, right?
dr_rus
Senior Member
Posts: 2980
Joined: 2007-04-17
Senior Member
Posts: 2980
Joined: 2007-04-17
#5637563 Posted on: 02/09/2019 03:01 PM
Mostly because adding RT to a frame means not only using RT cores for BVH traversal calculations but shading the data which you get as a result of these traversals which can be done only on CUDA cores which significantly adds to overall processing time of a frame. AFAIK, BFV is mostly shading limited even when using RT.
One thing everyone should understand about DXR is that its performance is 100% up to the application which is using it. The more RT calculations you add to a frame - the slower it will be compared to a non-RT frame. It is totally possible to render a frame with path tracing through DXR but this will take some minutes instead of milliseconds. Saying that DXR "doubles the time it takes to render a frame" is meaningless - DXR doesn't render anything, it's an API, through which an application can render some (or all) parts of a frame with raytracing. How exactly an application does it, to what degree, is a choice of this application, not DXR API.
But As they suggest that RT is squeezed in between Shader execution, why is there that drastic fps drop in DX-R game like BF 5?
Mostly because adding RT to a frame means not only using RT cores for BVH traversal calculations but shading the data which you get as a result of these traversals which can be done only on CUDA cores which significantly adds to overall processing time of a frame. AFAIK, BFV is mostly shading limited even when using RT.
But it does not add up to reality where DX-R doubles time it takes to render frame, right?
One thing everyone should understand about DXR is that its performance is 100% up to the application which is using it. The more RT calculations you add to a frame - the slower it will be compared to a non-RT frame. It is totally possible to render a frame with path tracing through DXR but this will take some minutes instead of milliseconds. Saying that DXR "doubles the time it takes to render a frame" is meaningless - DXR doesn't render anything, it's an API, through which an application can render some (or all) parts of a frame with raytracing. How exactly an application does it, to what degree, is a choice of this application, not DXR API.
Fox2232
Senior Member
Posts: 9545
Joined: 2012-07-20
Senior Member
Posts: 9545
Joined: 2012-07-20
#5637566 Posted on: 02/09/2019 03:09 PM
In case of BF5 it is not even visually impressive, but doubles those frame times. It is all talk and blame outside of GPU. It is always software's fault, right?
But in reality of things, it looks like there is really not much (or any) evidence to support statement that RT is somewhat executed in parallel.
Maybe in a year when we have 10 games with DX-R one finally does it right... or people come to realization that it is not done in parallel.
But for now, I can only say that tensors provide additional computational power while RT does not.
One thing everyone should understand about DXR is that its performance is 100% up to the application which is using it. The more RT calculations you add to a frame - the slower it will be compared to a non-RT frame. It is totally possible to render a frame with path tracing through DXR but this will take some minutes instead of milliseconds. Saying that DXR "doubles the time it takes to render a frame" is meaningless - DXR doesn't render anything, it's an API, through which an application can render some (or all) parts of a frame with raytracing. How exactly an application does it, to what degree, is a choice of this application, not DXR API.
In case of BF5 it is not even visually impressive, but doubles those frame times. It is all talk and blame outside of GPU. It is always software's fault, right?
But in reality of things, it looks like there is really not much (or any) evidence to support statement that RT is somewhat executed in parallel.
Maybe in a year when we have 10 games with DX-R one finally does it right... or people come to realization that it is not done in parallel.
But for now, I can only say that tensors provide additional computational power while RT does not.
dr_rus
Senior Member
Posts: 2980
Joined: 2007-04-17
Senior Member
Posts: 2980
Joined: 2007-04-17
#5637571 Posted on: 02/09/2019 03:34 PM
RT cores don't provide general purpose compute power, sure, but they do accelerate one specific step in RT computations - BVH traversal - which frees up available compute capacity for shading. Which in turn makes limited usage of real time RT somewhat possible even on mid-class consumer videocards.
But for now, I can only say that tensors provide additional computational power while RT does not.
RT cores don't provide general purpose compute power, sure, but they do accelerate one specific step in RT computations - BVH traversal - which frees up available compute capacity for shading. Which in turn makes limited usage of real time RT somewhat possible even on mid-class consumer videocards.
Fox2232
Senior Member
Posts: 9545
Joined: 2012-07-20
Senior Member
Posts: 9545
Joined: 2012-07-20
#5637577 Posted on: 02/09/2019 03:50 PM
That's marketing. I look at results. You should too. Maybe next generation on 7nm will be better, but for now it is not much of an visual difference at too high of a frame time cost.
RT cores don't provide general purpose compute power, sure, but they do accelerate one specific step in RT computations - BVH traversal - which frees up available compute capacity for shading. Which in turn makes limited usage of real time RT somewhat possible even on mid-class consumer videocards.
That's marketing. I look at results. You should too. Maybe next generation on 7nm will be better, but for now it is not much of an visual difference at too high of a frame time cost.
dr_rus
Senior Member
Posts: 2980
Joined: 2007-04-17
Senior Member
Posts: 2980
Joined: 2007-04-17
#5637587 Posted on: 02/09/2019 04:27 PM
It's certainly possible to use RT h/w in Turing to get performance boost for some effects without or with minor improvement to image quality. RT can be used for a lot of things. There's no inherent frame time cost.
Maybe next generation on 7nm will be better, but for now it is not much of an visual difference at too high of a frame time cost.
It's certainly possible to use RT h/w in Turing to get performance boost for some effects without or with minor improvement to image quality. RT can be used for a lot of things. There's no inherent frame time cost.
Click here to post a comment for this news story on the message forum.
Senior Member
Posts: 2980
Joined: 2007-04-17
Both RT cores and tensor cores are present inside the same streaming multiprocessor as main SPs/SIMDs (you really shouldn't call them "shaders") and all three are built from separate transistors. Theoretically all three units should be able to run in parallel but on Turing this is limited (by available intra-SM bandwidth and data paths most likely) in such a way that RT and SIMDs can run in parallel but tensors and SIMDs can't (hence this frame graph).
Shader code is any code and any code can be whatever "true" or not raytracing code too. DXR can be used for full path tracing (which is what I assume you mean by "true raytracing") just as well as some hybrid raster+RT solutions (like that of BFV) - it all depends on the code. DXR has no limitations here.