Current Generation Games Analysis Technical Discussion [2020-2021] [XBSX|S, PS5, PC]

[Allandor]

...
What does VRS has to do with this? It is explained by Matt. VRS intends to save processing power, same as culling. Question is, according to him, VRS will act on unnecessary triangles, and culling them earlier (as by not generating them at all) would bring more savings than VRS.

If you "cull" something (like it is done for ages) it won't be processed at all. VRS is about shading areas you won't notice (in the dark/same color in a larger area). You can't cull there, because those things are still on the monitor and still need processing. If you would exclude those areas completely, you would really notice it.
Culling is there to exclude calculations for invisible parts. Due to camera or other objects over that. Like already stated, this is done for ages. If at all (Sony is not very open about it) it is a bit more effective than before, but you can't compare it to no culling at all, as this is already done before. If they made something better it will (hopefully) be a bit more effective than before. If GPUs would still render everything that is not in the camera angle or behind other objects, performance would be much, much worse. E.g. this is also why RT is so expensive. In worst case, objects/triangles that where culled before, have not to get rendered (at least partially) again because or a reflection, shadow, ... .

 

[see colon]

Won't culling become less effective once you start having to process things off camera for ray tracing anyway?

 

[jlippo]

Won't culling become less effective once you start having to process things off camera for ray tracing anyway?

Rasterization culling is not affected by the RT BVH or tracing of rays.
If it gives shaves off 4ms for rasterizer part of the scene it will do the same with RT.
If the shaders for rasterization changes, you would want to benchmark impact with those for both cases as well.

 

[see colon]

Rasterization culling is not affected by the RT BVH or tracing of rays.
If it gives shaves off 4ms for rasterizer part of the scene it will do the same with RT.
If the shaders for rasterization changes, you would want to benchmark impact with those for both cases as well.

So if a scene uses RT GI, and you have for example, a room with a door with light entering from that doorway, and the renderer culls the entirety of the unseen room beyond that door, how would you calculate the light being bounced from the unseen room into the room the camera is in without processing the unseen room at least a little. I understand that tracing rays would be unaffected, and in a general sense what BHV is, but if you are talking about calculating the color of light being bounced off walls and objects in an unseen room into room where the camera is, how can culling be just as effective in that scene as one that doesn't use RT GI? You have to process the unseen room at least a little in the RT example, right? Where you would be discarding it from the renderer completely in a hypothetical perfect world culling example.

 

[iroboto]

So if a scene uses RT GI, and you have for example, a room with a door with light entering from that doorway, and the renderer culls the entirety of the unseen room beyond that door, how would you calculate the light being bounced from the unseen room into the room the camera is in without processing the unseen room at least a little. I understand that tracing rays would be unaffected, and in a general sense what BHV is, but if you are talking about calculating the color of light being bounced off walls and objects in an unseen room into room where the camera is, how can culling be just as effective in that scene as one that doesn't use RT GI? You have to process the unseen room at least a little in the RT example, right? Where you would be discarding it from the renderer completely in a hypothetical perfect world culling example.

The acceleration structure holds the triangles if I recall correctly, since the intersections is being accelerated by the hardware. The accelerators would perform the intersections in the BVH, and that should be separate from rasterization geometry. Once you know the intersections you should be able to figure out what you can and cannot cull.

 

[jlippo]

So if a scene uses RT GI, and you have for example, a room with a door with light entering from that doorway, and the renderer culls the entirety of the unseen room beyond that door, how would you calculate the light being bounced from the unseen room into the room the camera is in without processing the unseen room at least a little. I understand that tracing rays would be unaffected, and in a general sense what BHV is, but if you are talking about calculating the color of light being bounced off walls and objects in an unseen room into room where the camera is, how can culling be just as effective in that scene as one that doesn't use RT GI? You have to process the unseen room at least a little in the RT example, right? Where you would be discarding it from the renderer completely in a hypothetical perfect world culling example.

Rasterization and shading triangles used with rasterization does not know any of that.
So when you cull the scene presentation used for rasterization, an addition of different representation of scene for RT doesn't necessarily affect the culling.

RT scene in most cases can be quite different from the one used during rasterization pass.
It can also be culled, shaded differently. (Or be voxels instead of polygons etc.)

 

[see colon]

Ahh, so it doesn't use any of the scene data rendered by the rasterizer anyway. I was thinking that the BHV helped accelerate finding the intersections and the used the same rasterized data for RT. That makes more sense now.

 

[Metal_Spirit]

If you "cull" something (like it is done for ages) it won't be processed at all. VRS is about shading areas you won't notice (in the dark/same color in a larger area). You can't cull there, because those things are still on the monitor and still need processing. If you would exclude those areas completely, you would really notice it.
Culling is there to exclude calculations for invisible parts. Due to camera or other objects over that. Like already stated, this is done for ages. If at all (Sony is not very open about it) it is a bit more effective than before, but you can't compare it to no culling at all, as this is already done before. If they made something better it will (hopefully) be a bit more effective than before. If GPUs would still render everything that is not in the camera angle or behind other objects, performance would be much, much worse. E.g. this is also why RT is so expensive. In worst case, objects/triangles that where culled before, have not to get rendered (at least partially) again because or a reflection, shadow, ... .

When you create a vertex he has to through the vertex shader stage, and get placed on the world that the virtual camera sees (the frustrum), with some attributes calculated to achieve the desired graphical effect. But some triangles that are made up by these vertices may end up being outside the viewing frustum, or facing away from the camera, or even too small to be meaningful. Its at this stage that these triangles are thrown away by culling saving the rasterizers and the subsequent pipeline stages from doing wasteful work.

But up until this stage, there is work done and these attributes are computed. Position calculation and the other computations made until now are performed together in the vertex shader, and we cannot determine the vertex's position without executing the vertex shader.

Both Primitive and vertex Shaders have ways to improve this, but I will quote Mark Cerny on the DF interview about the specific GE of the PS5.

Elsewhere, another aspect of the Cerny presentation paid off spectacularly. One of the key features of the new GPU is the Geometry Engine, giving developers unprecedented control over triangles and other primitives and easy control over geometry culling. There's nothing new in terms of principles here - it boils down to removing the need to render triangles that end up being invisible in the final frame. The less geometry you process, the less work there is for the GPU, meaning that resources can be used elsewhere.

This is what Matt means. VRS and the GE are diferent things, but the gains from the more efficient culling are bigger than VRS. And according to Matt VRS even works on some vertices that will end up removed.

 

[cwjs]

until this stage, there is work done and these attributes are computed. Position calculation and the other computations made until now are performed together in the vertex shader, and we cannot determine the vertex's position without executing the vertex shader.

Sure -- that's part of what the vertex, hull, domain, whatever shaders do -- which may be replaced by GE (maybe thats public -- i dont know) and are definitely being replaced my mesh shaders. However, that replacement still has to do all the same work. You have to figure out where a triangle is before you can decide whether to cull it or not. By culling you save down the road: on rasterizing, and on the fragment shader.

This is what Matt means. VRS and the GE are diferent things, but the gains from the more efficient culling are bigger than VRS. And according to Matt VRS even works on some vertices that will end up removed.

No -- it does work on fragments (rasterized from triangles) that could have been culled if you had something like GE, mesh shaders, some kind of compute based rasterization etc, that gave you better culling. There's no such thing as shading culled triangles though, thats the whole reason you cull them.

 

[Metal_Spirit]

No -- it does work on fragments (rasterized from triangles) that could have been culled if you had something like GE, mesh shaders, some kind of compute based rasterization etc, that gave you better culling. There's no such thing as shading culled triangles though, thats the whole reason you cull them.

I believe I said vertices not triangles.

And that was also what Matt said.

"...
VRS without GE means you’re still processing vertices you can/should eliminate in earlier stages to begin with. More free compute/memory."

And on a side note, Leviathan Gamer claims that he analised the AMD drivers, and that Mesh Shaders are a software API working over Primitive Shaders, and that he sees no evidence of any kind of hardware changes on RDNA2 for its support.

He may be wrong though.

 

[PSman1700]

Leviathan Gamer claims

He may be wrong though.

 

[Proelite]

For what it's worth Star Citizen devs said you can get mesh shaders or some form of it running on RDNA 1.

 

[PSman1700]

For what it's worth Star Citizen devs said you can get mesh shaders or some form of it running on RDNA 1.

Id guess on older hardware aswell, just that performance might not be on the same level.

 

[Lurkmass]

Ahh, so it doesn't use any of the scene data rendered by the rasterizer anyway. I was thinking that the BHV helped accelerate finding the intersections and the used the same rasterized data for RT. That makes more sense now.

Games with hybrid RT/Raster rendering pipelines generally have two scene representations involving the both the depth buffer and BVH.

We have a depth buffer to accelerate primary visibility for rasterization. In this case 'culling' would take on the form of removing geometry outside the frustum, any back-facking or occluded geometry. The BVH is used for accelerating primary and secondary rays. Culling a BVH involves complicated heuristics for removing both geometry and light sources that have the least amount of contribution to our frame. We save on performance this way by not including mostly irrelevant geometry that won't have any or a very little amount of secondary rays reaching our main camera view and reducing the number of less important light sources will have the same effect. The end result is that we have less geometry to test our rays against and less rays to generate for a smaller number of light sources.

 

[Allandor]

...
And that was also what Matt said.

"...
VRS without GE means you’re still processing vertices you can/should eliminate in earlier stages to begin with. More free compute/memory."

And on a side note, Leviathan Gamer claims that he analised the AMD drivers, and that Mesh Shaders are a software API working over Primitive Shaders, and that he sees no evidence of any kind of hardware changes on RDNA2 for its support.

He may be wrong though.

As stated before. He is not really wrong here, he just has no point. In his tweet he compares VRS and Culling which both have absolute nothing to do with each other.
Better culling is good (which means, just a more effective culling) to free up resources (not really memory)
VRS (if implemented correctly) is also good to free up resources.

Having both would be even better.

and btw, Mesh shaders also do cull much better than before. As far as I know it wasn't possible before to just load needed resources there. "Problem" is just, that the developer has to implement this, but they go further as they only load visible parts into memory. While with normal culling only applies to what is currently rendered. You would still have to load all the resources (from the later culled parts) into memory if you don't have a replacement for mesh-shaders.
But we really just don't know if you can do the same as with mesh-shaders on the PS5 GPU. There might just be tricks to mimic it, but Sony isn't very open about their architecture and features. Sometime it is an advantage (for us in these forums) that MS also has windows and Directx as all those features get "openly" documented for the PC space.

 

[Deleted member 13524]

There seems to be this misconception that you either cull more efficiently or use VRS.

Matt Hargett's suggestion seems to be that if you reduce the geometry more effectively then the performance gains out of using VRS are lowered.
Makes sense that if there are less surfaces to apply pixel shader effects on, then there are less pixel shader effects to calculate, therefore the compute requirements also go down.

That's not to say VRS is worthless, only that it's trying to solve a problem (excess use of compute with no effect on perceived image quality) that would be more efficiently solved earlier in the rendering pipeline.
I guess it's easier to retrofit an existing game/engine with VRS (like what the Coalition did with Gears Tactics) than it is to implement a more effective geometry reduction pipeline which probably requires a deeper engine revamp.

Also, I think it's important to note that the GE isn't just being used for back-face culling, it can also discard front-facing triangles AFAIK. Reducing the geometry based on e.g. Z distance is probably a good way to save resources, not just back-face culling.

Starting to wonder if it's a mandate from Microsoft? Why else would all 3P games be following the same trend here?

3P games are made by developers who are stretching too thin on all the consoles they need to develop for.
My guess is they're starting with defining the render settings for the Series S to get as-good-as-possible visuals, and then they just increase render resolution for the Series X as much as they can.

Sony really needs to find a way on improving PS5 BC experience, rather than just simply letting it be. Microsoft has made some awesome strides on this front, seems Sony (at this point anyhow) is simply content with BC just working.

I disagree.
Sony needs to focus on delivering new-gen games for their new-gen console. That has been their strategy all along, which is very different to Microsoft's plan to extend their platform to several devices of different generations as much as they can.
For most people, enhanced BC is only important for the first year or two while new-gen games are scarce. It's also a lot less important for the PS5 than it is for the Series consoles considering the disparity in their 1st-year game release roadmaps.

 

[cwjs]

I believe I said vertices not triangles.

That's semantics (in most real cases), the vertices are transformed in order to draw triangles. If your renderer is point based (no tris, just points) then the same rules in my post applies, just replace 'vertices' with 'triangles'. By working in chunks with a baked in bounding box, mesh shaders do allow you to avoid placing some vertices, and i suppose we can presume that GE does too. But the pixel shader is both where it really hurt not to cull and where comparisons to VRS make sense.

For what it's worth Star Citizen devs said you can get mesh shaders or some form of it running on RDNA 1.

Yes -- with compute shaders. Shipped games with meshlet based rendering (aka, bascally mesh shaders) exist in some form dating back to at least assasins creed unity: https://advances.realtimerendering....siggraph2015_combined_final_footer_220dpi.pdf . The slides called 'mesh cluster rendering' describe the same general technique demonstrated here:

(this is cool trivia to impress anybody wondering why the game both looks and performs so differently than most other games of the time!)

Matt Hargett's suggestion seems to be that if you reduce the geometry more effectively then the performance gains out of using VRS are lowered.
Makes sense that if there are less surfaces to apply pixel shader effects on, then there are less pixel shader effects to calculate, therefore the compute requirements also go down.

Yep -- this is part of what i've been trying to communicate in my posts in this thread. VRS is nice, but its relatively marginal compared to better culling. Of course, multiple platforms and techniques provide better culling, so this isn't a ps5 advantage or a xsx advantage -- it's just conveying that its not the end of the world if one platform doesnt support hardware vrs.

 

[thicc_gaf]

3P games are made by developers who are stretching too thin on all the consoles they need to develop for.
My guess is they're starting with defining the render settings for the Series S to get as-good-as-possible visuals, and then they just increase render resolution for the Series X as much as they can.

That's likely what they're doing. It's a tad worrisome tho, because it feeds directly into some of the earlier worries when the Series S was announced; i.e games using Series S as the baseline and simply scaling up resolution and graphics settings for Series X.

I'm hoping at some point very soon that swings in the other direction, because I can't picture Series X getting pushed to its fullest potential if it's just a resolution upscaler for Series S games. And, if 3P devs (due to pub deadlines and budgets) can't make that the case, Microsoft's 1P studios should definitely do such, even if it involves a bit more work.

IMO they have to use Series X as the baseline because anything less isn't going to position their marquee system in a good spotlight compared to PS5, and I want both systems to push the envelope with both visual fidelity and game design this gen not just one.

 

[Deleted member 13524]

That's likely what they're doing. It's a tad worrisome tho, because it feeds directly into some of the earlier worries when the Series S was announced; i.e games using Series S as the baseline and simply scaling up resolution and graphics settings for Series X.

I'm hoping at some point very soon that swings in the other direction, because I can't picture Series X getting pushed to its fullest potential if it's just a resolution upscaler for Series S games. And, if 3P devs (due to pub deadlines and budgets) can't make that the case, Microsoft's 1P studios should definitely do such, even if it involves a bit more work.

IMO they have to use Series X as the baseline because anything less isn't going to position their marquee system in a good spotlight compared to PS5, and I want both systems to push the envelope with both visual fidelity and game design this gen not just one.

More work/time dedicated to choosing console-specific settings/features is of course the answer with the best results. But when a 3P needs to develop a cross-platform game for no less than 4 "old" consoles plus 3 "new" ones, that might become an impossible choice.
There are cases where the Series X was seemingly used as baseline, but the end result was a SeriesS being left out of new-gen features like ray-tracing or 60FPS modes, resulting in a poorer experience than the one provided by the older One X.

Regardless, we should hope for this to be solved when 3P stop making games for the 8th-gen consoles, but the temptation to keep developing games for an userbase of 160 million will be too great for a long time.

 

[OlegSH]

Matt Hargett's suggestion seems to be that if you reduce the geometry more effectively then the performance gains out of using VRS are lowered.

They can't be lowered, especially with deferred shading where geometry is completely decoupled from pixels shading.
Reducing geomery processing time can only make savings on pixels processing larger since pixel processing will take larger fraction of frame time.

With the simplest implementation of forward shading, there can be some correlation between geometry culling speed and VRS gains, but nobody does bare-bones forward rendering these days.
People usually do at least depth prepass with forward shading to save on redundant fragments shading and fill in normals and depth for screen-space effects. Hence early culling in primitive shaders or meshshaders will again do nothing to reduce pixel shading time.
Only the simplest forward rendering without depth prepass can benefit from the early culling so that backface geometry is not shaded, but there are other tools to kill those fragments.
Also, early culling won't fix the main issue with forward renderers - it won't help with small triangles. We are approaching 1 pixel sized triangles in games and with forward shading this means that quad shading granularity will eventually lead to 4x supersampling for 1 pixel sized triagles, so shading efficiency will be 1/4.