I no longer understand what you are arguing with me about here. One way or another, the rasterizer must know the number of primitives and vertices in a meshlet and the type of primitives, as rasterizers only support triangles, lines, and points. This should be either encoded in the data layout of meshlet itself or calculated at runtime. There are no other options for compatibility with the rasterizers. In order to be compatible with the rasterizers, the meshlet should resemble the internal interstage buffer formats, which can't be arbitrary, period, yet it speaks nothing about compatibility with other FP blocks, the thing I was arguing with you about.Any per-vertex/primitive attributes are only defined for the mesh shader's output as clearly laid out in the specifications. If you looked at the DispatchMesh API intrinsic, there's nothing in there that states that the payload MUST have some special geometry data/layout. The only hard limitation is the amount of data the payload can contain. There's another variant of the function without using task shaders where you don't have to specify a payload at all!
Given your line of argument, I can argue that tessellation and higher geometry density didn't "catch on" early in the generation due to the subpar hardware implementations, which suffered from spillovers into the video memory at higher expansion rates and generally resulted in low performance across many generations of hardware. The irony of the situation is that we still have mesh shaders on some vendors falling short of expectations in virtually every benchmark I've seen so far, possibly because they still have to make a round trip through the memory for the expansion or for other reasons. Maybe history is repeating itself, and the subpar hardware implementation by some vendors is the reason behind the low adoption of mesh shaders so far.A combination of factors such as the variable output nature of geometry shaders made it difficult for hardware implementations to be efficient and features in the original legacy geometry pipeline such as hardware tessellation and stream out didn't catch on so the idea of mesh shading is a "reset/redo button" of sorts so that hardware vendors don't have to implement them ...
Thanks for explaining the commonly known stuff I never asked you about. However, I wish you had instead provided proof that tessellation stages can be accessed within the mesh shaders on AMD's hardware to confirm your theories.The difference between graphics shaders and compute shaders is that they both operate in their own unique hardware pipelines so there's no way for them to directly interface with each other in most cases.
Also interesting to see the comparison between HW and SW RT and the huge difference that can make in scenes with more extensive RT use.
However, I would have preferred if their hardware implementation was impressive. Turning just the RT reflections from the Ultra preset to Unobtanium causes performance to drop from 8 ms to 22 ms for reflections only. Like how?The software RT implementation is impressive. Hopefully they share more details at GDC etc. Would be interesting to compare with UE5’s SDF tracing.
However, I would have preferred if their hardware implementation was impressive. Turning just the RT reflections from the Ultra preset to Unobtanium causes performance to drop from 8 ms to 22 ms for reflections only. Like how?
They just have a color per object (Metro style) in BVH, objects don't feature textures, any complex materials, and have very simplified geometry. There are no multiple bounces for lighting in the reflections, and the roughness cut-off is nothing special. Yet, this is something comparable to the performance cost of path tracing at maximum settings in Alan Wake 2. I wonder where all these milliseconds are spent, as the game is pretty basic in the RT department? I've also seen all sorts of light leaking and other RT bugs, which will hopefully be addressed in upcoming patches.
NVIDIA's RT subsystems are optimal equally for both DXR 1.0 and DXR1.1, for Intel the only optimal path is DXR1.0 and for AMD the only optimal path is DXR1.1, NVIDIA is the only vendor to handle both optimally.Could it have anything to do with it using DXR1.1 which I understand is suboptimal on Nvidia architectures (while being optimal for RDNA2)?
Inline RT is completely fine with nvidia's architectures. I guess a bit of profiling would have been helpful here, but I'm too lazy to spend vacation on this)Could it have anything to do with it using DXR1.1 which I understand is suboptimal on Nvidia architectures (while being optimal for RDNA2)?
Could it have anything to do with it using DXR1.1 which I understand is suboptimal on Nvidia architectures (while being optimal for RDNA2)?
Avatar is better, just not substantially so IMO. Metro does GI far better as an example.I know probe GI well enough from games and in these games I never saw such a lighting quality as the one from Avatar. Old GI looks much worse and much less accurate than the RT GI in Avatar. Probe GI looks old-fashioned, while the lighting in Avatar looks like something from a new generation. Avatar's Rt GI is light, but not cheap. You've seen how much faster the RT hardware is.
Avatar is better, just not substantially so IMO. Metro does GI far better as an example.
Avatar has a lack of consistency with areas more often looking improper and flat with light bounce not being quite correct.What specifically is Metro doing better?
It's also important to remember Metro is also a substantially worse looking game that screams 'last gen' and wasn't exactly a looker when it released.
I'm sure it's sparse environments in relation to Avatar are easier to light with GI.
As is DF tradition, we round off the year with a look at the team's personal picks for the best game graphics of 2023. Covering off the very best in both PC and console rendering, Alex Battaglia, John Linneman and Oliver Mackenzie share their thoughts on the most impressive visuals of the year, leading to an open debate on which title did it best: Alan Wake 2, Avatar: Frontiers of Pandora or Cyberpunk 2077's RT Overdrive?
I haven't dealt with Metro for too long to say anything about it.Avatar is better, just not substantially so IMO. Metro does GI far better as an example.
Can you show the screenshots of this inconsistency? The game looks damn near perfect in the jungle.Avatar has a lack of consistency with areas more often looking improper and flat with light bounce not being quite correct.
Glad to see Hi-Fi Rush on the list. Might be the prettiest cel-shaded game ever and they absolutely nailed that Saturday morning cartoon look