Current Generation Games Analysis Technical Discussion [2022] [XBSX|S, PS5, PC]

@Jay
https://forum.beyond3d.com/posts/2234150/

@iroboto
https://forum.beyond3d.com/posts/2234158/

I apologize for the late response and thank you for the links.
But then I was talking about the advantages of Mesh Shaders (animated flora, deformation of the car body, etc.), which are not involved in the UE5 demos. And officially, as far as I know, it has not yet been announced that Epic has solved these problems for its engine.

+ xsx supports both Mesh Shaders and Primitive Shaders.
Which of them and to what extent is used in The Matrix Awakens for xsx?
Andrew Lauritzen's answer is very vague.
 
@Jay
https://forum.beyond3d.com/posts/2234150/

@iroboto
https://forum.beyond3d.com/posts/2234158/

I apologize for the late response and thank you for the links.
But then I was talking about the advantages of Mesh Shaders (animated flora, deformation of the car body, etc.), which are not involved in the UE5 demos. And officially, as far as I know, it has not yet been announced that Epic has solved these problems for its engine.

+ xsx supports both Mesh Shaders and Primitive Shaders.
Which of them and to what extent is used in The Matrix Awakens for xsx?
Andrew Lauritzen's answer is very vague.
It's not exactly clear yet where they use it, but with respect to Nanite, they provided messaging that it would be used when it runs faster than their compute shader variant. Given how much the fixed function pipeline requires triangles to be of a certain size (to meet it's performance spec 4RBEs * 4 pixels per RBE for 1 triangle), one can only assume that a mesh with triangle sizes of 8px or greater, would be forwarded to the fixed function hardware to do. Where meshes with less than 8px triangles would be provided for the compute shader process to handle.

Whatever the case is, the mesh shader should not be trying to rasterize any mesh that has a pixel sized triangle or framerate will tank entirely.

Outside of Nanite like the character models, cars, etc, are all fair game for Mesh Shaders to do their work. Whether it's implemented is not yet documented, but from what I understand there are only a few exceptions in which a developer would _not_ use mesh shaders over the traditional rasterization route. So provided this, I suspect it's just a matter of time for all engines to largely move most of their work to mesh shaders.

RE: Primitive Shaders
IIRC, currently that's not exposed on direct X, so I'm not confident that it is available on Series consoles unless it's specific to the XDK now. Given that Mesh Shaders do what primitive shaders do + amplification shaders, I don't really see the reason to support both when developers need to support PC and Xbox (and primitive shader support is only available on AMD).
 
Last edited:
RE: Primitive Shaders
IIRC, currently that's not exposed on direct X, so I'm not confident that it is available on Series consoles unless it's specific to the XDK now. Given that Mesh Shaders do what primitive shaders do + amplification shaders, I don't really see the reason to support both when developers need to support PC and Xbox (and primitive shader support is only available on AMD).
The Matrix Awakens was not intended for PC and was originally developed for ps5, which does not support Mesh Shader.
Therefore, it might have been easier to run Primitive Shaders on xsx than to redo the pipeline for Mesh Shaders.

In the future, of course, they will have to implement full support for Mesh Shaders in UE5.
 
Therefore, it might have been easier to run Primitive Shaders on xsx than to redo the pipeline for Mesh Shaders.
I don't see the pipeline being any different here. They both alter the front end, they appear to be a direct swap in for each other. I'm pretty sure it's much easier to use Mesh Shaders (as written by the UE team) than it is trying to shoehorn XSX to do Primitive shaders which may not even be exposed by the API.
 
The Matrix Awakens was not intended for PC and was originally developed for ps5, which does not support Mesh Shader.
Therefore, it might have been easier to run Primitive Shaders on xsx than to redo the pipeline for Mesh Shaders.

In the future, of course, they will have to implement full support for Mesh Shaders in UE5.

If the MA devs didn't have the resources or the time to implement mesh shaders then why not just use the plain ole fixed function pipeline? If Nanite only works for rigid meshes which makes up 90% of a typical scene and this holds true for MA, then mesh or primitive shaders aren't doing a ton of work anyways. It doesn't seem like Matrix Awakens throws a lot of things that Nanite tends to have issue with so why not use the traditional pipeline for things Nanite doesn't handle well?

The fixed function hardware is limited to a fraction of the work it is normally designed to handle.
 
Last edited:
I don't see the pipeline being any different here. They both alter the front end, they appear to be a direct swap in for each other. I'm pretty sure it's much easier to use Mesh Shaders (as written by the UE team) than it is trying to shoehorn XSX to do Primitive shaders which may not even be exposed by the API.
I can't vouch for the accuracy of the information (it's hard to find it by Primitive Shaders), but from what I've seen:
- PrSh can optionally use tessellation
- PrSh can work via NGG (that is, it can recode the old shader type into a new one)
- there is a hardware limitation of capabilities (for RDNA/2: 8 prim shader in /4 prima shader out per clock cycle)

Mesh Shaders do not support tessellation.
Only native development is suitable for MSh.
 
I can't vouch for the accuracy of the information (it's hard to find it by Primitive Shaders), but from what I've seen:
- PrSh can optionally use tessellation
- PrSh can work via NGG (that is, it can recode the old shader type into a new one)
- there is a hardware limitation of capabilities (for RDNA/2: 8 prim shader in /4 prima shader out per clock cycle)

Mesh Shaders do not support tessellation.
Only native development is suitable for MSh.

Yes it does, in conjunction with the optional amplification shader.
 
Yes it does, in conjunction with the optional amplification shader.
Though I think Rabbit is referring to leveraging the hardware tesselator in the FF pipeline. The primitive shader combined with tesselation will do a surface shader followed into a tesselation stage. I'm not sure if the hardware tesselator is used there (I suspect so), whereas Mesh Shaders create a similar effect to tesselation using amplification shaders.
 
Yes it does, in conjunction with the optional amplification shader.
Amplification Shader is about something else.

Surface Shader is an optimized and integrated on-the-fly Vertex Shader and Hull Shader (TCS) stages.
(When the tessellator is active)

oWQ2SfI.png

hsXuJgN.png
 
Amplification Shader is about something else.

Surface Shader is an optimized and integrated on-the-fly Vertex Shader and Hull Shader (TCS) stages.
(When the tessellator is active)

oWQ2SfI.png

hsXuJgN.png

https://devblogs.microsoft.com/dire...on-shaders-reinventing-the-geometry-pipeline/

What does an Amplification Shader do?
While the Mesh Shader is a fairly flexible tool, it does not allow for all tessellation scenarios and is not always the most efficient way to implement per-instance culling. For this we have the Amplification Shader. What it does is simple: dispatch threadgroups of Mesh Shaders. Each Mesh Shader has access to the data from the parent Amplification Shader and does not return anything. The Amplification Shader is optional, and also has access to groupshared memory, making it a powerful tool to allow the Mesh Shader to replace any current pipeline scenario.

The mesh shader can do tessellation it just doesn't allow for all scenarios unless used in conjunction with an amplification shader. The amplification shader can also be used for culling and early LOD decisions.
 
Last edited:
@dobwal
Sorry, it seemed to me that it was clear from the context that we are talking about a hardware tessellator / a typical stage of the pipeline in game development (which does not require additional costs for implementation).
 
@dobwal
Sorry, it seemed to me that it was clear from the context that we are talking about a hardware tessellator / a typical stage of the pipeline in game development (which does not require additional costs for implementation).
Regardless, I don’t think there’s been any indication yet that Xbox has exposed NGG. Mesh Shaders is where the industry is headed, NGG is a good transition towards Mesh Shaders, but There has been no documentation that developers can explicitly code Primitive Shaders on Xbox. At best MS enabled the usage of NGG to convert the geometry front end to primitive shaders, but I don’t think Epic coded for it, and it would suit them better anyway to leverage Mesh.
 
But everything aside from them looks like a mid tier PS4 game.
There are singular elements of it that you may see and then be able to point to some last gen game and say, "This isn't any better than that", but as a whole package? All at 60fps? No way. It's easily beyond anything from last gen as a whole. It's a very impressive looking game, all the moreso being done by a studio that's never really made a game with AAA-style presentation levels.

I also think we're getting into that "I've forgotten what last gen console games actually looked like" territory that seems to happen when people say they aren't impressed by next gen titles.
 
Back
Top