[Merged by Bors] - Clustered forward rendering #3153

superdump · 2021-11-20T17:58:56Z

Objective

Implement clustered-forward rendering.

Solution

FIXME - in the interest of keeping the merge train moving, I'm submitting this PR now before the description is ready. I want to add in some comments into the code with references for the various bits and pieces and I want to describe some of the key decisions I made here. I'll do that as soon as I can. Anyone reviewing is welcome to add review comments where you want to know more about how something or other works.

The summary of the technique is that the view frustum is divided into a grid of sub-volumes called clusters, point lights are tested against each of the clusters to see if they would affect that volume within the scene and if so, added to a list of lights affecting that cluster. Then when shading a fragment which is a point on the surface of a mesh within the scene, the point is mapped to a cluster and only the lights affecting that clusters are used in lighting calculations. This brings huge performance and scalability benefits as most of the time lights are placed so that there are not that many that overlap each other in terms of their sphere of influence, but there may be many distinct point lights visible in the scene. Doing all the lighting calculations for all visible lights in the scene for every pixel on the screen quickly becomes a performance limitation. Clustered forward rendering allows us to make an approximate list of lights that affect each pixel, indeed each surface in the scene (as it works along the view z axis too, unlike tiled/forward+).
WebGL2 is a platform we want to support and it does not support storage buffers. Uniform buffer bindings are limited to a maximum of 16384 bytes per binding. I used bit shifting and masking to pack the cluster light lists and various indices into a uniform buffer and the 16kB limit is very likely the first bottleneck in scaling the number of lights in a scene at the moment if the lights can affect many clusters due to their range or proximity to the camera (there are a lot of clusters close to the camera, which is an area for improvement). We could store the information in textures instead of uniform buffers to remove this bottleneck though I don’t know if there are performance implications to reading from textures instead if uniform buffers.
Because of the uniform buffer binding size limitations we can support a maximum of 256 lights with the current size of the PointLight struct
The z-slicing method (i.e. the mapping from view space z to a depth slice which defines the near and far planes of a cluster) is using the Doom 2016 method. I need to add comments with references to this. It’s an exponential function that simplifies well for the purposes of optimising the fragment shader. xy grid divisions are regular in screen space.
Some optimisation work was done on the allocation of lights to clusters, which involves intersection tests, and for this number of clusters and lights the system has insignificant cost using a fairly naïve algorithm. I think for more lights / finer-grained clusters we could use a BVH, but at some point it would be just much better to use compute shaders and storage buffers.
Something else to note is that it is absolutely infeasible to use plain cube map point light shadow mapping for many lights. It does not scale in terms of performance nor memory usage. There are some interesting methods I saw discussed in reference material that I will add a link to which render and update shadow maps piece-wise, but they also need compute shaders to work well. Basically for now you need to sacrifice point light shadows for all but a handful of point lights if you don’t want to kill performance. I set the limit to 10 but that’s just what we had from before where 10 was the maximum number of point lights before this PR.
I added a couple of debug visualisations behind a shader def that were useful for seeing performance impact of light distribution - I should make the debug mode configurable without modifying the shader code. One mode shows the number of lights affecting each cluster by tinting toward red for few lights or green for many lights (maxes out at 16, but not sure that’s a reasonable max). The other shows which cluster the surface at a fragment belongs to by tinting it with a randomish colour. This can help to understand deeper performance issues due to screen space tiles spanning multiple clusters in depth with divergent shader execution times.

Also, there are more things that could be done as improvements, and I will document those somewhere (I'm not sure where will be the best place... in a todo alongside the code, a GitHub issue, somewhere else?) but I think it works well enough and brings significant performance and scalability benefits that it's worth integrating already now and then iterating on.

Calculate the light’s effective range based on its intensity and physical falloff and either just use this, or take the minimum of the user-supplied range and this. This would avoid unnecessary lighting calculations for clusters that cannot be affected. This would need to take into account HDR tone mapping as in my not-fully-understanding-the-details understanding, the threshold is relative to how bright the scene is.
Improve the z-slicing to use a larger first slice.
More gracefully handle the cluster light list uniform buffer binding size limitations by prioritising which lights are included (some heuristic for most significant like closest to the camera, brightest, affecting the most pixels, …)
Switch to using a texture instead of uniform buffer
Figure out the / a better story for shadows

I will also probably add an example that demonstrates some of the issues:

What situations exhaust the space available in the uniform buffers
- Light range too large making lights affect many clusters and so exhausting the space for the lists of lights that affect clusters
- Light range set to be too small producing visible artifacts where clusters the light would physically affect are not affected by the light
Perhaps some performance issues
- How many lights can be closely packed or affect large portions of the view before performance drops?

Josh015 · 2021-11-20T19:03:16Z

Yo, what do I need to do to pull this down and try it out? I've got a demo project that supports hundreds of moving lights and objects that's been sorely in need of something like this:
https://github.com/Josh015/cubism-demo-rs

superdump · 2021-11-20T19:18:56Z

Yo, what do I need to do to pull this down and try it out? I've got a demo project that supports hundreds of moving lights and objects that's been sorely in need of something like this:
https://github.com/Josh015/cubism-demo-rs

This is based on the pipelined-rendering branch of the bevy repo. So you would need to get your demo working with that by not using the prelude, using PipelinedDefaultPlugins instead of DefaultPlugins and using things from bevy_render2 / bevy_pbr2 etc instead of the old renderer. Hopefully that’s enough to get you going. If not it may be better to wait until it is merged into main. We’re weeks away from 0.6 now. :)

superdump · 2021-11-20T19:28:05Z

Some of the reference material:

The main initial reference material as it is an accessible article: http://www.aortiz.me/2018/12/21/CG.html
“Practical Clustered Shading” which is part 2 of https://efficientshading.com/2015/01/01/real-time-many-light-management-and-shadows-with-clustered-shading/ (Part 3 shows the shadow mapping techniques I mentioned)
The z-slicing method mentioned in the aortiz article which is from Tiago Sousa’s Siggraph 2016 talk about Doom 2016: http://advances.realtimerendering.com/s2016/Siggraph2016_idTech6.pdf

Josh015 · 2021-11-21T04:14:31Z

Okay, I got it working. This example is intentionally overkill, but here's a scene with 256 point lights enabled:

pipelined/bevy_pbr2/src/render/pbr.wgsl

pipelined/bevy_pbr2/src/render/mesh_view_bind_group.wgsl

pipelined/bevy_render2/src/render_resource/uniform_vec.rs

superdump · 2021-11-25T12:12:57Z

Some of the reference material:

* The main initial reference material as it is an accessible article:  http://www.aortiz.me/2018/12/21/CG.html

* “Practical Clustered Shading” which is part 2 of https://efficientshading.com/2015/01/01/real-time-many-light-management-and-shadows-with-clustered-shading/ (Part 3 shows the shadow mapping techniques I mentioned)

* The z-slicing method mentioned in the aortiz article which is from Tiago Sousa’s Siggraph 2016 talk about Doom 2016: http://advances.realtimerendering.com/s2016/Siggraph2016_idTech6.pdf

I added these as a comment before the cluster-related code in src/light.rs as I couldn't really think of a better place to do it, but we can of course move any of it anywhere.

slyedoc · 2021-12-02T13:56:38Z

Am I missing something, when given a window description and providing a size, say 500x500, you get lots of artifacts and WARN bevy_pbr2::render::light: cluster offset and count out of bounds!

Can reproduce in examples/3d/cornell_box_pipelined.rs adding a WindowDescriptor, artifacts move down the screen as aspect ratio gets greater.

superdump · 2021-12-02T14:18:40Z

Am I missing something, when given a window description and providing a size, say 500x500, you get lots of artifacts and WARN bevy_pbr2::render::light: cluster offset and count out of bounds!

Can reproduce in examples/3d/cornell_box_pipelined.rs adding a WindowDescriptor, artifacts move down the screen as aspect ratio gets greater.

You're probably not missing anything, just I hadn't found a situation where that happened outside of stress tests. My guess would be that the light sources are close to the camera, and so because there are a lot of clusters close to the camera, the lights intersect many of them, and we run out of space. This is something that speaks to using a texture for the cluster light lists instead of trying to squeeze them into a 16kB uniform. However, a simpler solution that was used in one of the reference materials was to just only have one depth slice for the first 5 units along z, and then use the 'real' exponential mapping after that. I should probably just do that. I didn't because I wanted a request for N depth slices to actually produce N depth slices, rather than N - however many depth slices are in the first 5 units + 1, and I didn't find a good mathematical way of doing that. I think that was me being a bit technically pure with the implementation and the pragmatic approach is to do exactly that - make the first slice a fixed size. I'll do that as soon as I can, probably by dynamically calculating the first depth boundary >= M units along z, and using that as the far boundary of the first slice.

slyedoc · 2021-12-02T17:39:49Z

Sorry mate, you're so far ahead of me on this that I hate to even take up your time. I should have been more clear, added pic to show the result, maybe I used the term artifact incorrectly.

Images

only change was adding

    App::new()
        .insert_resource(WindowDescriptor {
            width: 500.0,
            height: 500.0,
            ..Default::default()
        })

INFO bevy_render2::renderer: AdapterInfo { name: "GeForce RTX 2080 Ti", vendor: 4318, device: 7687, device_type: DiscreteGpu, backend: Vulkan }

superdump · 2021-12-02T17:41:47Z

Sorry mate, you're so far ahead of me on this that I hate to even take up your time. I should have been more clear, added pic to show the result, maybe I used the term artifact incorrectly.

Images
only change was adding
    App::new()
        .insert_resource(WindowDescriptor {
            width: 500.0,
            height: 500.0,
            ..Default::default()
        })

INFO bevy_render2::renderer: AdapterInfo { name: "GeForce RTX 2080 Ti", vendor: 4318, device: 7687, device_type: DiscreteGpu, backend: Vulkan }

Yup, I could reproduce it when adding the window size as 500x500. Thanks for finding this issue! I’ll address it as soon as I have time to.

slyedoc · 2021-12-02T17:51:59Z

Ok after reading your first response a few more times I get it, thanks for all you do, gl

superdump · 2021-12-05T20:26:15Z

Am I missing something, when given a window description and providing a size, say 500x500, you get lots of artifacts and WARN bevy_pbr2::render::light: cluster offset and count out of bounds!

Can reproduce in examples/3d/cornell_box_pipelined.rs adding a WindowDescriptor, artifacts move down the screen as aspect ratio gets greater.

I was wrong in my initial response. This was actually about the way the clusters are configured. There can be maximum 4096 clusters, and I am using a constant 24 depth slices, which leaves the condition: number of tiles in x * number of tiles in y * 24 <= 4096 to avoid the error message you saw. I just pushed a commit that fixes this. Thanks again for reporting it! :)

Now compiles and runs but nothing displays

It should not be disabled by default - oops! Also put it inside a shader def as it doesn't need to be there unless debugging.

Co-authored-by: Jakob Hellermann <[email protected]>

…orward rendering

When using a square aspect ratio, tile sizes were calculated such that the maximum number of clusters was exhausted. This new approach is aspect-ratio independent.

cart · 2021-12-09T03:08:30Z

Alrighty I've wrapped up my final pass on this. I think its in a good spot to merge. I do want to eventually revisit putting the Clusters calculation in the "user app" instead of in the render app, as that feels like a "renderer implementation detail". But I also agree that it would involve rethinking visibility a bit. Time to move forward!

cart · 2021-12-09T03:08:37Z

bors r+

# Objective Implement clustered-forward rendering. ## Solution ~~FIXME - in the interest of keeping the merge train moving, I'm submitting this PR now before the description is ready. I want to add in some comments into the code with references for the various bits and pieces and I want to describe some of the key decisions I made here. I'll do that as soon as I can.~~ Anyone reviewing is welcome to add review comments where you want to know more about how something or other works. * The summary of the technique is that the view frustum is divided into a grid of sub-volumes called clusters, point lights are tested against each of the clusters to see if they would affect that volume within the scene and if so, added to a list of lights affecting that cluster. Then when shading a fragment which is a point on the surface of a mesh within the scene, the point is mapped to a cluster and only the lights affecting that clusters are used in lighting calculations. This brings huge performance and scalability benefits as most of the time lights are placed so that there are not that many that overlap each other in terms of their sphere of influence, but there may be many distinct point lights visible in the scene. Doing all the lighting calculations for all visible lights in the scene for every pixel on the screen quickly becomes a performance limitation. Clustered forward rendering allows us to make an approximate list of lights that affect each pixel, indeed each surface in the scene (as it works along the view z axis too, unlike tiled/forward+). * WebGL2 is a platform we want to support and it does not support storage buffers. Uniform buffer bindings are limited to a maximum of 16384 bytes per binding. I used bit shifting and masking to pack the cluster light lists and various indices into a uniform buffer and the 16kB limit is very likely the first bottleneck in scaling the number of lights in a scene at the moment if the lights can affect many clusters due to their range or proximity to the camera (there are a lot of clusters close to the camera, which is an area for improvement). We could store the information in textures instead of uniform buffers to remove this bottleneck though I don’t know if there are performance implications to reading from textures instead if uniform buffers. * Because of the uniform buffer binding size limitations we can support a maximum of 256 lights with the current size of the PointLight struct * The z-slicing method (i.e. the mapping from view space z to a depth slice which defines the near and far planes of a cluster) is using the Doom 2016 method. I need to add comments with references to this. It’s an exponential function that simplifies well for the purposes of optimising the fragment shader. xy grid divisions are regular in screen space. * Some optimisation work was done on the allocation of lights to clusters, which involves intersection tests, and for this number of clusters and lights the system has insignificant cost using a fairly naïve algorithm. I think for more lights / finer-grained clusters we could use a BVH, but at some point it would be just much better to use compute shaders and storage buffers. * Something else to note is that it is absolutely infeasible to use plain cube map point light shadow mapping for many lights. It does not scale in terms of performance nor memory usage. There are some interesting methods I saw discussed in reference material that I will add a link to which render and update shadow maps piece-wise, but they also need compute shaders to work well. Basically for now you need to sacrifice point light shadows for all but a handful of point lights if you don’t want to kill performance. I set the limit to 10 but that’s just what we had from before where 10 was the maximum number of point lights before this PR. * I added a couple of debug visualisations behind a shader def that were useful for seeing performance impact of light distribution - I should make the debug mode configurable without modifying the shader code. One mode shows the number of lights affecting each cluster by tinting toward red for few lights or green for many lights (maxes out at 16, but not sure that’s a reasonable max). The other shows which cluster the surface at a fragment belongs to by tinting it with a randomish colour. This can help to understand deeper performance issues due to screen space tiles spanning multiple clusters in depth with divergent shader execution times. Also, there are more things that could be done as improvements, and I will document those somewhere (I'm not sure where will be the best place... in a todo alongside the code, a GitHub issue, somewhere else?) but I think it works well enough and brings significant performance and scalability benefits that it's worth integrating already now and then iterating on. * Calculate the light’s effective range based on its intensity and physical falloff and either just use this, or take the minimum of the user-supplied range and this. This would avoid unnecessary lighting calculations for clusters that cannot be affected. This would need to take into account HDR tone mapping as in my not-fully-understanding-the-details understanding, the threshold is relative to how bright the scene is. * Improve the z-slicing to use a larger first slice. * More gracefully handle the cluster light list uniform buffer binding size limitations by prioritising which lights are included (some heuristic for most significant like closest to the camera, brightest, affecting the most pixels, …) * Switch to using a texture instead of uniform buffer * Figure out the / a better story for shadows I will also probably add an example that demonstrates some of the issues: * What situations exhaust the space available in the uniform buffers * Light range too large making lights affect many clusters and so exhausting the space for the lists of lights that affect clusters * Light range set to be too small producing visible artifacts where clusters the light would physically affect are not affected by the light * Perhaps some performance issues * How many lights can be closely packed or affect large portions of the view before performance drops?

bors · 2021-12-09T03:36:29Z

Pull request successfully merged into main.

Build succeeded:

# Objective We keep getting issues where things break at small window sizes, e.g #3368 (caused by #3153), #3596 ('caused' by #3545) ## Solution - Add a test that we can make small windows. Currently, this fails on my machine with some quite scary vulkan errors: ``` 2022-01-08T22:55:13.770261Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (0x7cd0911d)] Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x1adbd410a60, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (225,60), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (225,56), minImageExtent = (225,56), maxImageExtent = (225,56). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274) 2022-01-08T22:55:13.770808Z ERROR wgpu_hal::vulkan::instance: objects: (type: DEVICE, hndl: 0x1adbd410a60, name: ?) 2022-01-08T22:55:13.787403Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (0x7cd0911d)] Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x1adbd410a60, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (225,56), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (225,52), minImageExtent = (225,52), maxImageExtent = (225,52). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274) ``` etc. This might be a new issue here, although I'm surprised it's vulkan giving this error; wgpu should stop it if this is illegal.

# Objective We keep getting issues where things break at small window sizes, e.g bevyengine#3368 (caused by bevyengine#3153), bevyengine#3596 ('caused' by bevyengine#3545) ## Solution - Add a test that we can make small windows. Currently, this fails on my machine with some quite scary vulkan errors: ``` 2022-01-08T22:55:13.770261Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (0x7cd0911d)] Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x1adbd410a60, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (225,60), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (225,56), minImageExtent = (225,56), maxImageExtent = (225,56). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274) 2022-01-08T22:55:13.770808Z ERROR wgpu_hal::vulkan::instance: objects: (type: DEVICE, hndl: 0x1adbd410a60, name: ?) 2022-01-08T22:55:13.787403Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 (0x7cd0911d)] Validation Error: [ VUID-VkSwapchainCreateInfoKHR-imageExtent-01274 ] Object 0: handle = 0x1adbd410a60, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x7cd0911d | vkCreateSwapchainKHR() called with imageExtent = (225,56), which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR(): currentExtent = (225,52), minImageExtent = (225,52), maxImageExtent = (225,52). The Vulkan spec states: imageExtent must be between minImageExtent and maxImageExtent, inclusive, where minImageExtent and maxImageExtent are members of the VkSurfaceCapabilitiesKHR structure returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR for the surface (https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01274) ``` etc. This might be a new issue here, although I'm surprised it's vulkan giving this error; wgpu should stop it if this is illegal.

superdump mentioned this pull request Nov 20, 2021

Renderer Rework: Initial Merge Tracking Issue #2535

Closed

64 tasks

superdump mentioned this pull request Nov 20, 2021

PBR / Clustered Forward Rendering #179

Closed

superdump force-pushed the clustered-forward-rendering branch from 45696df to 90557d4 Compare November 21, 2021 09:48

alice-i-cecile added A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible S-Needs-Review labels Nov 21, 2021

jakobhellermann reviewed Nov 22, 2021

View reviewed changes

pipelined/bevy_pbr2/src/render/pbr.wgsl Outdated Show resolved Hide resolved

pipelined/bevy_pbr2/src/render/mesh_view_bind_group.wgsl Outdated Show resolved Hide resolved

pipelined/bevy_render2/src/render_resource/uniform_vec.rs Outdated Show resolved Hide resolved

superdump force-pushed the clustered-forward-rendering branch from f07fbe4 to 6cc04d7 Compare November 25, 2021 11:35

superdump changed the base branch from pipelined-rendering to main November 25, 2021 11:35

superdump force-pushed the clustered-forward-rendering branch 2 times, most recently from f9e823b to 0802ff4 Compare December 2, 2021 08:44

superdump added 8 commits December 5, 2021 21:36

WIP clustered forward

ae605ad

More WIP clustered forward

ecbe8c4

Some more plumbing WIP

cd89fb6

More WIP

19c6a5d

Now compiles and runs but nothing displays

A bunch of bugfixes and debug stuff

2787a8f

Minor tweaks

87a909f

bevy_pbr2: Do not queue shadow passes when shadows are disabled

185df2f

bevy_pbr2: Flip screen y for calculating clusters

65d2647

superdump and others added 15 commits December 5, 2021 21:36

Clean up rebase mistakes

41caae7

bevy_pbr2: Clean up clustered-forward debug code

37acff5

It should not be disabled by default - oops! Also put it inside a shader def as it doesn't need to be there unless debugging.

bevy_pbr2: Clean up WIP debugging stuff

8df8d5d

bevy_pbr2: Limit the number of point light shadow maps queued

8f0e600

bevy_pbr2: Fix up scheduling of systems

ae7cc0e

Appease clippy

da4ee64

pbr.wgsl: Use index accessors for matrices

0bf9846

Co-authored-by: Jakob Hellermann <[email protected]>

mesh_view_bind_group.wgsl: Fix code in comment

8eaffdf

Co-authored-by: Jakob Hellermann <[email protected]>

uniform_vec: Remove code used for debugging

5afd959

Fix a couple of comments

396d86b

Fix comment indentation style

93b508f

bevy_pbr2: Improvements to comments

552b463

bevy_pbr2: Add some comments about reference material for clustered-f…

4656c22

…orward rendering

bevy_pbr2: Appease clippy

098847a

bevy_pbr2: Aspect-ratio independent cluster tile configuration

cdeb00b

When using a square aspect ratio, tile sizes were calculated such that the maximum number of clusters was exhausted. This new approach is aspect-ratio independent.

superdump force-pushed the clustered-forward-rendering branch from 8a4a2a2 to cdeb00b Compare December 5, 2021 20:36

bors bot changed the title ~~Clustered forward rendering~~ [Merged by Bors] - Clustered forward rendering Dec 9, 2021

bors bot closed this Dec 9, 2021

DJMcNab mentioned this pull request Dec 17, 2021

Minimising panics again #3368

Closed

DJMcNab mentioned this pull request Jan 8, 2022

[Merged by Bors] - Add an example to test small window sizes #3597

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Merged by Bors] - Clustered forward rendering #3153

[Merged by Bors] - Clustered forward rendering #3153

superdump commented Nov 20, 2021 •

edited

Loading

Josh015 commented Nov 20, 2021

superdump commented Nov 20, 2021

superdump commented Nov 20, 2021

Josh015 commented Nov 21, 2021 •

edited

Loading

superdump commented Nov 25, 2021

slyedoc commented Dec 2, 2021

superdump commented Dec 2, 2021

slyedoc commented Dec 2, 2021

superdump commented Dec 2, 2021

slyedoc commented Dec 2, 2021

superdump commented Dec 5, 2021 •

edited

Loading

cart commented Dec 9, 2021

cart commented Dec 9, 2021

bors bot commented Dec 9, 2021

[Merged by Bors] - Clustered forward rendering #3153

[Merged by Bors] - Clustered forward rendering #3153

Conversation

superdump commented Nov 20, 2021 • edited Loading

Objective

Solution

Josh015 commented Nov 20, 2021

superdump commented Nov 20, 2021

superdump commented Nov 20, 2021

Josh015 commented Nov 21, 2021 • edited Loading

superdump commented Nov 25, 2021

slyedoc commented Dec 2, 2021

superdump commented Dec 2, 2021

slyedoc commented Dec 2, 2021

superdump commented Dec 2, 2021

slyedoc commented Dec 2, 2021

superdump commented Dec 5, 2021 • edited Loading

cart commented Dec 9, 2021

cart commented Dec 9, 2021

bors bot commented Dec 9, 2021

superdump commented Nov 20, 2021 •

edited

Loading

Josh015 commented Nov 21, 2021 •

edited

Loading

superdump commented Dec 5, 2021 •

edited

Loading