AMD: Navi Speculation, Rumours and Discussion [2019-2020]

Status
Not open for further replies.
tunafish said:
Yes and no. Large caches were large consumers when transistor leakage current was a major problem, but finfets can push leakage really low, leaving only the active switching as the energy cost, and the only part of a cache that switches any given clock is the part that is accessed, and the access path. As caches grow in size, their energy consumption is almost flat. So while caches consume a lot, making caches larger makes them consume less per area. Improving hit rate of course increases energy consumption (as cache is effectively hit and therefore accessed more often), but linearly increasing cache size doesn't linearly increase hit rate. So again you are winning on power per area.
Click to expand...

And while getting a cache hit increases the energy consumption of the cache, it decreases the energy consumption of the whole system, because it saves a much more energy-intensive trip to DRAM.
 
SimBy said:
What is this nonsense? Some hardware blog quoting some random nobody on twitter who says AMD CFO Devinder Kumar detailing how RT works. CFO talking architecture details? Devinder probably doesn't even know what RT is.
Click to expand...

Think also that cant be true. 20TF is alot still, but i hope for more from AMD's side.
 
SimBy said:
There are only three options. Massive cache is real, die size is wrong, it's more than 80CUs.
Click to expand...
No, there are *MORE* options!

How about:
* a single CU resources got beefier - more cache/buffers, more advanced data formats/instructions supported, etc. This might not be the same as the consoles.
* the whole chip got massively frequency optimized - tighter timings though the whole pipe can potentially eat a lot of transistors. Again, not the same as the consoles.
* feeding 8 shader arrays with 10CUs each might require a bit of workload distribution overhead - scheduling, ACEs, queues, etc.
* new uncore - new ROPs, new rasterizer (?), new VCN, XGMI - ate the transistors
* caches, buffers got buffed (but not that single 128MB cache...) - even Vega 10 contained 45MB of SRAM for some reason
* the chip really contains both HBM + GDDR memory interfaces for some weird (AMDish) reason

Btw the 80CUs is nearly given. It's doubled the Navi10, which is nice and round. Every single opensource mention points to 80CUs. All the leakz so far pont to 80CUs for the top config.

This is a completely different situation to RV770 - there was a single unlucky mention of 480SPs made by F@H project lead. So everybody trusted that...
 
PSman1700 said:
Think also that cant be true. 20TF is alot still, but i hope for more from AMD's side.
Click to expand...
20TF shouldn't be too far off from the RTX 3080. Even though that is advertised as being a ~30TF card, it is closer to a 20TF card if it was the Turing architecture. Ampere's TFs are quite inefficient compared to Turing.

As for the 20CUs being used for RT, I don't see why they would equip some CUs with BVH acceleration and not others. So if this is true, it is most likely a baseline setting in the driver which could be changed game to game. I suspect you can't let the code run wild on both rasterization and RT but that it needs some sort of workload allocation.
 
NightAntilli said:
20TF shouldn't be too far off from the RTX 3080. Even though that is advertised as being a ~30TF card, it is closer to a 20TF card if it was the Turing architecture. Ampere's TFs are quite inefficient compared to Turing.
Click to expand...

A 3080 is a 30TF product, it can do math at 30TFs if needed. A potentional 20TF RDNA2 product probably wouldnt match it in future games, but closer then the numbers project. Not it matters, cause i doubt that source anyway.
We had that other spec sheet indicating a a close to 25TF navi21/31 GPU (6900XT?). I would have no doubt something like that being close to a 3080 in most situations. And somewhere, i think AMD has a 3080 beater in the works, as there must be a reason for NV upping the ante so much. There must be heat from AMD coming for NV offering such large jumps and adjusting price to humane levels.

RDNA2 seems to clock high, a big full fat navi2 gpu could be a serious performer. It's the reason i wait, i want an AMD GPU again, as a pc gamer i want competition for a healthier market, and more intresting data points to discuss.
 
yuri said:
*snip*

This is a completely different situation to RV770 - there was a single unlucky mention of 480SPs made by F@H project lead. So everybody trusted that...
Click to expand...
Everybody else was saying 640SPs. I think it was Chiphell that was throwing around the 800SP but nobody really believed it.

God the RV770 was awesome. I got the 4850 a week before launch for $150 at bestbuy.
 
Globalisateur said:
@Love_In_Rio
@iroboto
I think the excellent RT we have seen so far on a few PS5 games could be mostly explained because of easy and mature APIs. Sony have being thinking about RT since at least 2013 as Cerny was already considering it for PS4 (but couldn't do it because of how expensive it was).
Click to expand...
Sorry I missed this name highlight. Yea it could have played a factor; but API and things like this are very guarded. It’s very difficult to tell unfortunately, I haven’t read much on Sony’s work on the API side of things except that they have been looking at this for a while.

I would say based upon the recent response by devs to the DF RT video from @Dictator it looks like some very smart decisions are being made to make it happen. I’m unsure of how much API flexibility plays into it, but I suspect the more restrictive it is the harder it is to tune the performance of RT.

That being said, RT calls should just be an extension to the existing GNM as they are extensions to DX12 and Vulkan. So I'm not exactly sure how much can be pushed more than just calling the 4 steps you saw, determine ray distance, intersect rays, shade, denoise
 
Last edited:
iroboto said:
I would say based upon the recent response by devs to the DF RT video from @Dictator it looks like some very smart decisions are being made to make it happen. I’m unsure of how much API flexibility plays into it, but I suspect the more restrictive it is the harder it is to tune the performance of RT.
Click to expand...
Curious about those devs responses, any link to them?.

Thanks in advance.
 
Status
Not open for further replies.
Back
Top