AMD RDNA3 Specifications Discussion Thread

It's all memey shit anyway.
CMOS won because it's literally sand, and sand is cheap and ubiquitous.
Graphene isn't cheap or ubiquitous.
it's not my intention to stretch this topic here, but i remember reading some article of a cost efficient method to make carbon nanotubes from regular coal by being blown inside a pressurized chamber with high consistency but unfortunately can't find that article.
But anyway my point was/is seeing as how the cost of silicon wafers are reaching stupid high levels as well, can we really confidently say it wouldn't be cheap? As for ubiquitous, it can be made from coal, how is that not cheap or ubiquitous?
 
Like other said this is first AMD RT implementation. I think we will see midgen console and they will be much more interesting than base console from a performance point of view with AMD improvement made for 2nd generation RT.

And some Nvidia researcher are not very happy of DXR lack of LOD support.


Don't think we will see a mid gen console refresh until rdna 4 imo. Well sony might push forward with an RDNA 3 . Going by last generation sony launched a refresh 3 years in which would be 2023 and ms pushed for a refresh in year 4 which would be 2024. MS would likely have access to RDNA 4 is we assume every other year for amd refreshes ( RDNA 2 was 2020 and now RDNA 3 is 2023)
 
Don't think we will see a mid gen console refresh until rdna 4 imo. Well sony might push forward with an RDNA 3 . Going by last generation sony launched a refresh 3 years in which would be 2023 and ms pushed for a refresh in year 4 which would be 2024. MS would likely have access to RDNA 4 is we assume every other year for amd refreshes ( RDNA 2 was 2020 and now RDNA 3 is 2023)

I don't think we will see a midgen console refresh before 2024. This generation will be longer they have time.
 
I don't think we will see a midgen console refresh before 2024. This generation will be longer they have time.
you could be right. We will have to see what both companies due. I just used last gen as an example of what we could expect. Both of them may wait for 2026 and we could get rdna 5 or whatever amd moves onto in the refreshes. who really knows. But the longer they wait the less likely hood they will use RDNA 3 which is second gen amd rt.
 
it's not my intention to stretch this topic here, but i remember reading some article of a cost efficient method to make carbon nanotubes from regular coal by being blown inside a pressurized chamber with high consistency
Try getting this into mass productions at volumes necessary for semiconductor markets.
We're bending physics over and fucking it with EUV just to keep CMOS scaling because that's way cheaper than anything else.
Also CNTs are like the ideal fab contaminant and is PITA to handle overall.
 
You know, it's like, their 2nd implementation and it doesn't look like they're following anything.

Their not following anything indeed, i was implying they will, not that they are at the moment.

You do realize that the console solution is AMDs first gen solution, right? The flexibility is there from hardwares perspective at least on AMD (could be for NV/Intel too, dunno), it's the software (APIs) limiting it on PC.

The consoles are in a even worse shape regarding RT and ML, their performances for said technologies are too slow no matter how flexible it is. But thats not the topic for this.


Like other said this is first AMD RT implementation. I think we will see midgen console and they will be much more interesting than base console from a performance point of view with AMD improvement made for 2nd generation RT.

Right, this belongs in the console speculation topic. How fast and great AMD's implementation is can be tested with RDNA3/4 products perhaps, instead of speculating on next gen consoles (mid gen wont even see the light of day).
 
Their not following anything indeed, i was implying they will, not that they are at the moment.



The consoles are in a even worse shape regarding RT and ML, their performances for said technologies are too slow no matter how flexible it is. But thats not the topic for this.




Right, this belongs in the console speculation topic. How fast and great AMD's implementation is can be tested with RDNA3/4 products perhaps, instead of speculating on next gen consoles (mid gen wont even see the light of day).

It is interesting to see on consoles not on PC with DXR 1.0.
 
Define precise. Lumen s/w is using SDF representation for those which are considerably less precise than proxy meshes used for Lumen h/w.
If you want 1:1 mapping then Nanite must be done in a different way - but is it really needed?
Yes, it is needed. But your comparison of Lumen SDF for GI is not suited, as for GI geometric or material precision is neither needed nor good.
Shadows is the best example. Say we want area light shadows of a tree. This means soft shadows on the ground and sharp self shadows on the tree. Shadow maps can't do this well, but RT can.
Though, if we use proxy geometry for the tree different from the visual mesh, we get self shadows and peter panning, so exactly the problems RT promises to finally solve.
Thus, shadow maps will remain the only robust solution for Nanite models. RT can be used only for GI or reflections (to some degree), where error is acceptable.
(That's my personal conclusions and assumptions, maybe somebody can confirm or correct me.)

Now you may ask if shadows are that important, and if accelerating GI and reflections isn't much more benefit.
But for me HW RT can not accelerate my GI, nor can it make it more accurate.
Thus, all i get from HW RT would be imperfect reflections, which isn't worth the extra cost of maintaining proxy geometry and runtime BVH building just for that.
Much more likely i'm better off with compute tracing my surfel hierarchy to get imperfect reflections. A bit blurrier, but probably faster on average, and much less memory for sure.

RT doesn't prevent any progress with LOD, what it does is prevent using said progress inside the results of RT itself. These are two completely different issues.
No, LOD is the independent problem here. Triangle meshes work for both raster and RT.
But current RT does not work for resolution adaptive triangle meshes, which are the only option to achieve fine grained LOD using triangles.
Thus, current RT APIs do prevent any progress to achieve such fine grained LOD for RT. Period, and no further discussion required. That's the true situation.
The only option for LOD for RT is discrete LOD. But that's no solution to the problem. It does not work for large models. You need to split them into multiple pieces, which causes overlapping BVH like kitbashing, increased workload on generating TLAS, visual glitches, and increased content production costs.

There is at least one
Which one? Just don't say Avatar again, which won't require RT. So which game will be the first with RT on minimal specs? (just out of interest)

It can "beat" h/w by being considerably less precise and glitchy while running at the same or lower performance.
Not sure. Less precision can actually halp for GI, as a prefiltered sample gives a good average otherwise requiring many point samples for the same result.
But i won't argue. If you say Lumen sucks, that's two of us. Portal RTX looks way better. ; )

But these even if used during content creation aren't present in the shipping code as is anywhere for the same reasons why they are introducing issues in UE5 - they are bad for actual rendering, with or without TR.
Misunderstanding? The first UE5 demo (Land of Nanite?) used heavy kitbashing. They mentioned up to 20 layers of models, like onion skin. This can't be optimized away for a shipping game, because all those 20 models are somewhere visible.
If they are not visible but deep below the visible surface (will happen few times), raster will cull them, and RT will find the closer intersection before traversing them, for the most cases. It should not degrade perf. too much.
But lets close this for now and see if shipping games indeed use such insane detail levels at all.

There is, it's using the same proxy mesh as Nanite is using anyway. Proxy meshes there are not for RT.
Ahrg. You can't deal with your shiny god having some fails too, no?
You can generate proxy meshes using Nanite, but that's not it's distinctive feature.
Nanites function is (visually) continuous detail, which only is possible if you edit a static mesh locally. The entire mesh becomes 'dynamic', even if it's meant to look static.
To support this for HW RT, the only current option would be to rebuild the BVH from scratch every frame, for each instance of every model in the whole scene. This is not possible in real time.
You surely understand this, so stop pretending you wouldn't, please.
No further corrections from my side about this.

We can safely say that this is not the case as otherwise we'd already see the h/w being used this way if not in Vulkan IHV EXTs then on PS5 at least.
No. Because PC holds back consoles just as much as consoles hold back PC. It isn't worth to make specific solutions just for one platform.
And there are no VK extensions to expose BVH data structures.

DXR 2.0 when
Let's see if the platform lives long enough to require this.
 
Last edited:
it's not my intention to stretch this topic here, but i remember reading some article of a cost efficient method to make carbon nanotubes from regular coal by being blown inside a pressurized chamber with high consistency
Meh.
I want room sized, British cold fusion reactors first.
Bullshit? Likely not. They sold ARM because they no longer need it.
Don't think we will see a mid gen console refresh until rdna 4 imo.
Meh.
Give me a rdna4 PSP instead.
 
Back
Top