EEVEE-Next: Shadow Rendering Refactor #110979
Split shadow rendering per LOD per tilemap and improve
fragment shader invocation rate by using multi-viewport.
Also changes the layout of the atlas to be 4 x 4 x Layers.
This allow to grow the atlas while keeping the content
and page indirection correct, but this isn't implemented
in this patch.
Shadow rendering using atomic proved to be less than ideal
and performance were not quite to an acceptable level.
The previous method had issue with atomic contention when
a lot of triangle would overlap and too many fragment shader
invocations with quite complex indirection rules and biases
which made the technique costly.
The new implementation leverage multi viewport and
layered rendeing to effectively replace the need for atomic
and render directly to the shadow atlas. Using the well
supported extension these are free on modern hardware and
do not need a geometry shader.
One view per tile is needed since we use the viewport index
and the layer index as a way to index a specific tile in the
Geometric Complexity Problem
The counterpart of this is that we need to draw one geometry
instance per tile which is 32x32 time more instances (at most)
than with the previous method.
This means that we will have to find a way to mitigate this
geometry cost by either reducing the number of tiles per
tilemaps (in other words, making the system less memory efficient)
or splitting complex objects' geometry into smaller, more
cull friendly chunks (for example, like the sculpt PBVH nodes).
The later seems to be a longer term solution as it requires
way too much engineering time we have right now.
Update Lag Problem
This also mean we can only update up to 64 tile per redraw
which is not enough even in the most basic cases. This leads
to missing or over shadowing when a light updates until there
is no updates and the shadow rendering can catch up.
One possible solution is to update a lower LODs first waiting
until there is no update to render. This would allow no artifact
during the transforms (unless there is too many light updates
even for lowest LOD, but that was an issue also for the
previous implementation). This could also help with the
In the end, we decided to have one view per lod. This limits
the complexity of the fragment shader (improve speed),
reduces the number of views per tilemap (fix update lag),
and reduces the number of instances.
This also mean we cannot render directly to the atlas anymore
and reverted to the atomic solution. Using the smallest
possible viewport, we assure that there isn't that much fragment
shader invocations which was one of the bottleneck. And also
reduces the amount of geometry instances that pass the
- Change atlas to 2D Array
- Change atomic to also use layers
- Add viewport array support to main
- Change the final code to output one view per page and set render resolution to page size
- Setup viewport array in shadow render code, set render resolution to 4*4 pages.
- Add non atomic rendering
- Fix Directional shadows
- Fix Adaptive Bias
- Fix Update Lag
- Fix Geometric Cost
This add the possibility to define different viewports inside a single framebuffer and let the vertex shader decide which viewport to render to. This only contain the GL implementation.
This follows the same emulation path as gpu_Layer. Layer and ViewportIndex now use the same extension `ARB_shader_viewport_layer_array`
This was caused by the free unused data pass in the init phase that would reset the clip data of the first tilemap. Uploading and checking for an invalid index fixes the issue.
# Conflicts: # source/blender/draw/engines/eevee_next/shaders/eevee_shadow_tilemap_init_comp.glsl
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?