Next Generation Hardware Speculation with a Technical Spin [post E3 2019, pre GDC 2020] [XBSX, PS5]

It looks only slightly less mental in reality than in than in the drawing. It's hard to determine scale but it's potentially large enough for a couple of 120mm fans on the rear.

 

prediction:

8 core 16 thread zen 2 CPU running at 3.2ghz
44CU/40CU navi running at 2.344ghz*
16 GB gddr6 ram
1 TB ssd

* - Ray tracing be "hardware accelerated" using DXR in the sense that the gpu's shaders can be considered "hardware". As for Coalition dev Colin Penny's comment about "dedicated ray tracing cores", perhaps this is a misunderstanding.

 

There is no way it will be 2.3 ghz. Id be surprised if its over 1.6.

 

NOOOOOOOOOOOOOOOOOOOOOO! The "what constitutes hardware ray tracing" uncertainty has returned!

 

The 12 core 24T ryzen 7 3900 runs @4.60ghz boost, 105w tdp max. 8 core zen2 could be running higher, maybe boost?

 

zen2 cores in 3900 are top "quality" core, no ? Imo for consoles they don't need crazy speed, and need quantity ... around 2.4-2.8ghz max would still be a huge improvement over what we have now.

 

AMD has a patent for BVH traversal hardware in the TMUs. This seems the most likely implementation.

 

1 ray per TMU?

 

My only wish is that this GPU will be RDNA 1.5 at least.
I'm really happy seeing how AMD improved the actual delivered performance compared with Vega. Surely there's still room to improve and for me it's is much more important than the number of CU and Megahertz.

This and if Mark Cerny did something to improve Zen 2 memory latency.

 

Yes, I mean 3.2ghz boost. 1.6ghz base clock.

 

About Colin Penny's statement about "dedicated ray tracing cores", can someone contact Phil Spencer about it?

 

Or maybe it’s to allows stacking beyond 3 units which was the limit for PS4 dev kits?​

 

Just recently, when I read the gamespot interview, it still said "Having dedicated ray tracing cores in huge." I checked the interview, just now. Now it says "Having dedicated ray tracing hardware is huge." "Hardware" instead of "cores".

Sometimes when an article is incorrect they will quietly correct the mistake. I guess this means it's shaders after all.

 

It just means we still have no idea how it's implemented on either system.

Even if it's not dedicated cores but modified cu's, it's an assumption people make that one is overall better than the other when they have no idea how it will actually perform.

 

I think we have a fairly good idea.

http://www.freepatentsonline.com/20190197761.pdf

 

So we have an idea of how it's implemented, but no idea on general performance on the AMD side.

 

Async compute must be an integral part to that?

hm.

 

I can see why that may be a reasonable educated guess.
Even if it was done like that, was there customizations made, what is the performance like, etc.

Even then it's just an educated guess, I will stick with the view that we don't know. I'm more than prepared to be called stubborn until we get actual details about it.
I'm more than happy to see the discussions around different implementations, implications and patents though.

 

https://devblogs.microsoft.com/directx/announcing-microsoft-directx-raytracing/

Read this paragraph:

You may have noticed that DXR does not introduce a new GPU engine to go alongside DX12’s existing Graphics and Compute engines. This is intentional – DXR workloads can be run on either of DX12’s existing engines. The primary reason for this is that, fundamentally, DXR is a compute-like workload. It does not require complex state such as output merger blend modes or input assembler vertex layouts. A secondary reason, however, is that representing DXR as a compute-like workload is aligned to what we see as the future of graphics, namely that hardware will be increasingly general-purpose, and eventually most fixed-function units will be replaced by HLSL code. The design of the raytracing pipeline state exemplifies this shift through its name and design in the API. With DX12, the traditional approach would have been to create a new CreateRaytracingPipelineState method. Instead, we decided to go with a much more generic and flexible CreateStateObject method. It is designed to be adaptable so that in addition to Raytracing, it can eventually be used to create Graphics and Compute pipeline states, as well as any future pipeline designs.