Digital Foundry Article Technical Discussion [2023]
- Thread starter BRiT
- Start date
- Status
They're also preloading some elements of the BHV that have to be calculated in real time on the GPU on PC by the looks of it.
Looking forward to Alex's video so that I can run some settings matches comparisons on my system.
Also, the developer mentions having a compute fallback for GPUs that don't support hardware-accelerated ray tracing but based on the in-game settings, there doesn't appear to be a way to toggle rt on/off. Does the game just auto-detect your GPU and toggle it on if it detects that it supports hardware ray tracing?
Another question, the interview mentions that on consoles, the bottom-level BVH is pre-built offline. What does that mean? They then say that the top-level BVH is on the CPU. Basically, no GPU cycles are wasted on BVH on consoles. On PC, all instances are sent to the GPU which builds the acceleration structure, and the top-level BVH is built on the CPU. If I understand correctly,
Consoles: Bottom-level BVH (offline), Top-level BVH (CPU)
PC: Bottom-level BVH (GPU), Top-level BVH (CPU), instances are also all sent to the GPU for it to build the acceleration structure
On consoles, the BVH doesn't even seem to touch the GPU, correct? This would mean a lot of rendering time is spared on the GPU, right?
Another question, the interview mentions that on consoles, the bottom-level BVH is pre-built offline. What does that mean? They then say that the top-level BVH is on the CPU. Basically, no GPU cycles are wasted on BVH on consoles. On PC, all instances are sent to the GPU which builds the acceleration structure, and the top-level BVH is built on the CPU. If I understand correctly,
Consoles: Bottom-level BVH (offline), Top-level BVH (CPU)
PC: Bottom-level BVH (GPU), Top-level BVH (CPU), instances are also all sent to the GPU for it to build the acceleration structure
On consoles, the BVH doesn't even seem to touch the GPU, correct? This would mean a lot of rendering time is spared on the GPU, right?
Last edited:
A detailed deep dive from the devs of Avatar Pandora.
Avatar: Frontiers of Pandora - the big developer tech interview
Digital Foundry's Alex Battaglia interviews Massive's Nikolay Stefanov and Oleksandr Koshlo about Avatar: Frontiers of Pandora and the Snowdrop engine.www.eurogamer.net
Super interesting. Looks like they've made sensible tradeoffs to make good use of the available hardware on console and PC. There's no per-pixel radiance caching which could explain the flat visuals in low light scenarios but overall result is still very good. Still would have been nice to have ReSTIR or similar in the "uber" option.
The interview mentions culling of entire level sectors, instances and meshlets. Apparently consoles do all 3 but PCs only cull sectors and instances before processing individual triangles. Given the density of overlapping objects in the environment this could mean lots more hidden triangles go through vertex transform and shading on PC. I wonder if that explains why Ampere is punching above its weight in this game.
Johnny Awesome
Veteran
Logic. Just because Kojima has a following doesn't make his games good.
cheapchips
Veteran
Nice bit of extra context from a Senior Rendering Engineer at The Coalition, Chris Wallis.
Last edited:
Your logic makes zero sense. You are equating Kojima fans, which are gamers who just want to have fun, with followers of complex political figures and events that involve conflict, society and war. If you want to bring a good argument, bring a real one based on relevant facts that explains how and why people specifically like Kojima games. Not bring unrelated examples to make a point because you can't find a relevant factual argument that is directly related
@Bold That's not true for AMD HW ...
The idea of "formats" itself as there being special memory/layout doesn't exist at all in the mesh shading pipeline. What you have is an "arbitrary payload" of data as the input for mesh shading. While it's true that the common mesh shading pipeline lacks those functionality, console developers don't have to deal with those limitations on PC. You can absolutely use tessellation and stream out with mesh shaders on consoles and the reverse is true as well in that you can also use mesh shaders with the overloaded legacy geometry pipeline ...
PC wouldn't be as annoying for developers to optimize if it didn't have separate interfaces as a consequence of there being multiple disjoint geometry pipelines implementations as seen on other hardware vendors. A unified hardware geometry pipeline design as is the case with the primitive shaders means that hardware can have a singular unified interface for it as well ...
A detailed deep dive from the devs of Avatar Pandora.
Avatar: Frontiers of Pandora - the big developer tech interview
Digital Foundry's Alex Battaglia interviews Massive's Nikolay Stefanov and Oleksandr Koshlo about Avatar: Frontiers of Pandora and the Snowdrop engine.
I think this is hands down one of the best techical game interview i have ever red. Most of the "technical" interviews are just sales pitch or just dumb down features checklist without even getting into details of implementation, challenges etc etc. This is great. Also super impressed by Alex knowledge, to understand subject on such a high level and ask relevant and interesting questions great just great.
I doubt that the internal hardware, such as the tessellator, understands the meshlet format. Vertex pipeline's hw performs deduplication by itself and operates on IBs and VBs instead of meshlets. It has no notion of a fixed meshlet size. That's why meshes have to be converted between the two. Why do you think that mesh shaders can access the fixed pipe hardware on consoles? Why would there be any trouble in beating the traditional vertex pipeline hardware if it was available in mesh shaders on consoles? Does not make any sense to me.
Last edited:
There is no such thing as a "meshlet format" as I mentioned previously. What you have is any arbitrary payload of data. Meshlet's aren't truly backed by any sort of special memory like we see with vertex buffers. Meshlet's are just a collection of arbitrary data in regular memory just like any other plain old buffer resources that's used by other shaders. Mantle doesn't have "vertex buffers" at all so how do you figure it gets the geometry data ?
If you used RGP before and have profiled any games using hardware tessellation on RDNA3 you will see surface shader waves being registered along with primitive shader waves (the hardware stage compatible with mesh shader programs) in the wavefront distribution statistics. That implies that between the surface shader stage (hardware's hull shader) and the primitive shader stage (hardware's geometry shader), there is a fixed function tessellator going on which matches up with open source documentation. That means mesh shaders on consoles or rather primitive shaders can interface with the hardware tessellation unit. As for stream out, you can do a bit of trivial emulation to make it work with primitive shaders as hinted in the DirectX specifications ...
Well that's because mesh shaders just like geometry shaders both feature more powerful and flexible programming models! D3D12 bindless is more powerful and flexible than it's predecessor's (D3D11) register slot based binding model and do you know how hard it is realize the benefits of the former model with explicit barriers ?
More functionality = More slow paths
@Dictator wonder if the DF/EG staff can get behind the scene info on what happened at T10 during the development cycle. Clearly, it's not 'from the ground up.' Looks more of a lipstick on a pig from previous game as a backup plan when clearly the first option didn't go well.
I mean this is just straight up lying lol
I mean this is just straight up lying lol
Last edited:
Digital Foundry feels very out of touch when it comes to multiplayer games. Would be nice if they had a more multiplayer focused person on staff. As much as their are people that don't understand free-to-play, live service or continually updated multiplayer games, there are a lot of gamers that don't enjoy incredibly expensive linear narrative games. I've been playing games since the 80s, and almost all of the best experiences I've had playing games were with other people. It was playing brawlers in the arcade with my friends, playing couch co-op games on NES/SNES, playing Doom 2 multiplayer matches organized on BBS's, Counter-Strike beta, MUDs, MMOs in the late 90s/early 2000s, Diablo 2 multiplayer, Battlefield, Battle Royale games, co-op survival games etc. I think the worst thing that happened to consoles was the PS2 era, and somewhat the 360/PS3 era where many games seemed to be single-player narrative games and the number of actual fun couch co-op games disappeared (except for some niche games like sports games, fighting game series). Online multiplayer coming to consoles was great, because it brought back some of what went missing when couch co-op started to dwindle. There's room for a lot of perspectives and I feel like it's missing on DF, though as primarily a tech focus'd channel maybe it doesn't matter.
If this is 'laser scanned' T10 need to get a refund on their laser. Look at the track width and and run off. Esp on the right side. The track irl and proper sims is more narrow while the run off irl is much wider than FM version.
This looks like they knew the edge to edge width of the track + runoff and then took liberties on how to spend that budget instead of staying true to the track. How do you get run off width that far from reality?????
DF is a tech-focused channel. Multiplayer games are the last place you wanna look for impressive rendering techniques. The most popular stuff out there is Minecraft, Fortnite, Counter-Strike, DOTA2, PUBG, Genshin Impact and a bunch of others. In the case of Minecraft and Fortnite, DF did do some coverage for the cool new tech they introduced. Why would they do a piece on a bunch of games meant to run on the lowest-speced hardware available?
When did I suggest this?
Also, here's a tech channel that primarily dealt with multiplayer games. One of the best gaming tech channels there ever was.
There's more to tech than rendering. Not that Digital Foundry has to pick up any of the content that a channel like BattleNonSense used to produce (that channel is mostly retired). I just think that when they have these panel discussions it seems to be a bunch of people that mostly agree with each other about everything. Would be nice to have a different perspective on the panel, not that they'd necessarily have to move away from their main focus which is analysis the cutting edge of graphics.
- Status
Similar threads
