Add FidelityFX Super Resolution 2.2 (FSR 2.2.1) support. #81197

DarioSamo · 2023-08-31T13:55:46Z

FidelityFX Super Resolution 2.2

Introduces support for FSR2 as a new upscaler option available from the project settings.

It's worth noting that while I've done my best effort in making improvements to the pipeline to provide the information as well as possible to FSR2 with the minimal performance impact, some artifacts inherent to the algorithm are to be expected. This is a pretty competitive area at the moment where both DLSS and FSR aren't perfect in all cases and it'll vary a lot on the type of content that is used. While I can address artifacts introduced by my own implementation due to errors, if the contents of the render fit what FSR2 expects, there's not much else I can do. Therefore, we should probably limit reporting to noticeable issues (e.g. broken results) that aren't FSR2 problems.

To verify

There's some UX issues where it'd be appreciated to gather some feedback on how they should be solved.

We can arguably improve loading times in general if FSR2 is not used by opting to move shader initialization outside of the FSR2Effect constructor, but maybe the delay when turning on the feature is not desired.

While the FSR version included in the PR mostly matches the public GitHub version, some changes have been made to better accommodate for Godot's needs.

TODO

Production edit: This closes Integrate AMD FSR 2 in the Vulkan renderer (currently, FSR 1.0 is supported) godot-proposals#4280.

🍀 This work has been financed and kindly donated to the Godot Engine project by W4 Games. 🍀

mrjustaguy · 2023-08-31T15:24:25Z

My initial report on FSR 2.2 vs TAA

FSR 2.2 is not compatible with MSAA, as it breaks rendering at lower resolutions, though it is usable with Native resolution if TAA is also enabled (else it turns into a jittering mess)

Aside From that, Comparing with TAA, There is no Motion pixelization with FSR2, However static scenes with high frequency detail are a little less stable, It also seems to be properly resolving Transparencies unlike TAA which breaks with transparencies causing anything affected by transparent surfaces to go crazy (say Quad effects show the underlying quad moving with TAA, not so with FSR 2.2)

FSR 2.2 costs 2x as TAA, However looks significantly better IMHO and is well worth it, but All other Anti Aliasing should probably be forced to off when FSR 2.2 is on
One thing that FSR is not good for however is what it was intended for, Upscaling. It results in a highly pixelated look, especially around Alpha transparencies, and kinda feels like mixing Integer Scaling and FSR 1 with TAA, however these issues seem to be FSR 2 issues and not Godot's Implementation of it (Same issues have been observed in shipped games, Such as Star Wars Jedi Survivor)

Saul2022 · 2023-08-31T15:54:15Z

as noted by mrj quality increases a lot with fsr 2.2, though performance on an igpu is pain xdd, though the flickering is gone unlike taa 1.0. some screenshots: at scaling quality at 0.5 the pixelated one is bilinear, the flicker fsr 1 and the quality one is on 2.2

Calinou · 2023-08-31T18:26:03Z

Note that this PR includes changes to optimize motion vector generation (by deriving from the depth buffer when possible), which may improve performance substantially, even with traditional native TAA. Therefore, this PR might be enough to close #61905 (I haven't tested yet).

While the FSR version included in the PR mostly matches the public GitHub version, some changes have been made to better accommodate for Godot's needs.

I'd recommend adding // -- GODOT start -- and // -- GODOT end -- before and after modified sections in FSR2 code and shaders, so that updating these files is easier in the future. We do this in third-party libraries where we need to modify the code. cc @akien-mga

PS: The .patch file included is considered as a binary file in GitHub's web viewer, even though it's a text file. Maybe we need to fix something in .gitattributes.

DarioSamo · 2023-08-31T18:53:03Z

Note that this PR includes changes to optimize motion vector generation (by deriving from the depth buffer when possible), which may improve performance substantially, even with traditional native TAA. Therefore, this PR might be enough to close #61905 (I haven't tested yet).

We'll probably see the biggest gains when the render list is sorted in a way that only renders static geometry first and dynamic geometry afterwards. This PR doesn't take care of that nor does it add that behavior to the existing TAA shader, but we can very well take advantage of the implementation here.

I'd recommend adding // -- GODOT start -- and // -- GODOT end -- before and after modified sections in FSR2 code and shaders, so that updating these files is easier in the future. We do this in third-party libraries where we need to modify the code.

Sounds good to me.

ettiSurreal · 2023-08-31T22:44:49Z

Well someone has to ask about this.
FSR 3.0 is apparently supposed to come out as soon as this month, so any words on this?

Calinou · 2023-08-31T22:47:54Z

Well someone has to ask about this. FSR 3.0 is apparently supposed to come out as soon as this month, so any words on this?

The FSR 3 code isn't available yet. This will likely be worked on after it's open sourced and has a Vulkan + GLSL port, but we can't give an ETA.

BastiaanOlij

Most of my remarks are more general ones, except for some of the FSR logic that ended up in RenderSceneBuffers, but either should be in RenderBufferDataForwardClustered or handled by the FSR effect itself like other effects do.

All in all this looks amazing!

servers/rendering/renderer_rd/environment/sky.cpp

servers/rendering/renderer_rd/forward_clustered/render_forward_clustered.cpp

servers/rendering/renderer_rd/storage_rd/render_scene_buffers_rd.cpp

servers/rendering/renderer_rd/renderer_scene_render_rd.cpp

BastiaanOlij · 2023-09-01T02:03:09Z

servers/rendering/renderer_rd/renderer_scene_render_rd.cpp

@@ -732,6 +735,11 @@ void RendererSceneRenderRD::_render_buffers_debug_draw(const RenderDataRD *p_ren
 		}
 	}

+	if (debug_draw == RS::VIEWPORT_DEBUG_DRAW_INTERNAL_BUFFER) {


Should probably have made this remark earlier on, but we need a better name then internal buffer. Internal buffer is far to non-descript. Which internal buffer? We have dozens of internal buffers...

Do you think we should solve this in this particular PR? It matches the name of the internal texture on Render Buffers so that's pretty much why I used that.

Best alternatives I can think of is something like Color Buffer or related.

servers/rendering/renderer_rd/shaders/effects/fsr2_accumulate_pass.glsl

servers/rendering/renderer_rd/storage_rd/render_scene_buffers_rd.cpp

Calinou · 2023-09-01T03:16:43Z

This fails to build with MinGW from Linux (Fedora 38) for me:

Compiling servers/rendering/renderer_rd/storage_rd/utilities.cpp ...
servers/rendering/renderer_rd/effects/fsr2.cpp: In function 'FfxErrorCode create_pipeline_rd(FfxFsr2Interface*, FfxFsr2Pass, const FfxPipelineDescription*, FfxPipelineState*)':
servers/rendering/renderer_rd/effects/fsr2.cpp:334:47: error: invalid conversion from 'const wchar_t*' to 'size_t' {aka 'long long unsigned int'} [-fpermissive]
  334 |                         wcsncpy(binding.name, L"r_dilated_motion_vectors", sizeof(binding.name) / sizeof(wchar_t));
      |                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                               |
      |                                               const wchar_t*
servers/rendering/renderer_rd/effects/fsr2.cpp:334:97: error: invalid conversion from 'long long unsigned int' to 'const wchar_t*' [-fpermissive]
  334 |                         wcsncpy(binding.name, L"r_dilated_motion_vectors", sizeof(binding.name) / sizeof(wchar_t));
      |                                                                            ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
      |                                                                                                 |
      |                                                                                                 long long unsigned int
servers/rendering/renderer_rd/effects/fsr2.cpp:334:32: error: too few arguments to function 'errno_t wcsncpy_s(wchar_t*, size_t, const wchar_t*, size_t)'
  334 |                         wcsncpy(binding.name, L"r_dilated_motion_vectors", sizeof(binding.name) / sizeof(wchar_t));
      |                                ^
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/wchar.h:1561,
                 from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cwchar:44,
                 from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/postypes.h:40,
                 from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/iosfwd:40,
                 from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/system_error:40,
                 from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/mutex:41,
                 from ./core/os/mutex.h:37,
                 from ./servers/rendering/renderer_rd/shader_rd.h:34,
                 from ./servers/rendering/renderer_rd/shaders/effects/fsr2_accumulate_pass.glsl.gen.h:5,
                 from servers/rendering/renderer_rd/effects/fsr2.h:34,
                 from servers/rendering/renderer_rd/effects/fsr2.cpp:31:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/sec_api/wchar_s.h:316:27: note: declared here
  316 |   _CRTIMP errno_t __cdecl wcsncpy_s(wchar_t *_Dst,size_t _DstSizeInChars,const wchar_t *_Src,size_t _MaxCount);
      |                           ^~~~~~~~~
servers/rendering/renderer_rd/effects/fsr2.cpp: In function 'FfxResource get_resource_rd(RID*, const wchar_t*)':
servers/rendering/renderer_rd/effects/fsr2.cpp:496:27: error: invalid conversion from 'const wchar_t*' to 'size_t' {aka 'long long unsigned int'} [-fpermissive]
  496 |         wcsncpy(res.name, name, sizeof(res.name) / sizeof(wchar_t));
      |                           ^~~~
      |                           |
      |                           const wchar_t*
servers/rendering/renderer_rd/effects/fsr2.cpp:496:50: error: invalid conversion from 'long long unsigned int' to 'const wchar_t*' [-fpermissive]
  496 |         wcsncpy(res.name, name, sizeof(res.name) / sizeof(wchar_t));
      |                                 ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
      |                                                  |
      |                                                  long long unsigned int
servers/rendering/renderer_rd/effects/fsr2.cpp:496:16: error: too few arguments to function 'errno_t wcsncpy_s(wchar_t*, size_t, const wchar_t*, size_t)'
  496 |         wcsncpy(res.name, name, sizeof(res.name) / sizeof(wchar_t));
      |                ^
/usr/x86_64-w64-mingw32/sys-root/mingw/include/sec_api/wchar_s.h:316:27: note: declared here
  316 |   _CRTIMP errno_t __cdecl wcsncpy_s(wchar_t *_Dst,size_t _DstSizeInChars,const wchar_t *_Src,size_t _MaxCount);
      |                           ^~~~~~~~~
scons: *** [servers/rendering/renderer_rd/effects/fsr2.windows.editor.x86_64.o] Error 1
scons: building terminated because of errors.
[Time elapsed: 00:01:15.512]

Command line: scons -j1 platform=windows optimize=speed lto=full progress=no debug_symbols=yes

Also, the Viewport constant for FSR2 is missing or not exposed:

Benchmark

OS: Fedora 38
CPU: Intel Core i9-13900K
GPU: GeForce RTX 4090 (NVIDIA 535.98)
Resolution: 3840×2160
Project: https://github.com/Calinou/godot-reflection/tree/fsr2-test

All tests done with this PR. I couldn't notice a performance difference with master compared to this PR when using native (or FSR 1) TAA.

Mode	Native	Quality	Balanced	Performance	Ultra Performance
Bilinear (+ TAA)	270 FPS (3.70 mspf)	499 FPS (2.00 mspf)	566 FPS (1.76 mspf)	671 FPS (1.49 mspf)	875 FPS (1.14 mspf)
FSR 1¹ (+ TAA)	N/A	453 FPS (2.20 mspf)	513 FPS (1.94 mspf)	599 FPS (1.66 mspf)	788 FPS (1.26 mspf)
FSR 2	229 FPS (4.36 mspf)	376 FPS (2.65 mspf)	420 FPS (2.38 mspf)	476 FPS (2.10 mspf)	585 FPS (1.70 mspf)

Binary size

Stripped Linux x86_64 optimize=speed lto=full editor build:

master: 104,858,720 bytes
This PR: 106,485,888 bytes (+ 1.62 MB)

Android APK size (release export template, arm64 only):

master: 19,065,334 bytes
This PR: 19,287,926 bytes (+ 223 KB)

Given the increase in binary size, we should look into excluding as much FSR2 code as possible on mobile/web platforms, as it won't be used there.

Visual comparison

Still scene

Output resolution: 3840×2160

TAA Native	FSR2 Native
native	fsr2_native

Bilinear Quality	Bilinear Balanced	Bilinear Performance	Bilinear Ultra Performance
quality	balanced	performance	ultra_performance

FSR1 Quality	FSR1 Balanced	FSR1 Performance	FSR1 Ultra Performance
fsr1_quality	fsr1_balanced	fsr1_performance	fsr1_ultra_performance

FSR2 Quality	FSR2 Balanced	FSR2 Performance	FSR2 Ultra Performance
fsr2_quality	fsr2_balanced	fsr2_performance	fsr2_ultra_performance

Scene in motion

Output resolution: 1920×1080

Camera is rotating towards the left. This means newly discovered pixels are on the left of the image. These are the ones to watch out for disocclusion artifacts 🙂

TAA Native	FSR2 Native

FSR2 Quality	FSR2 Balanced	FSR2 Performance

@DarioSamo I've noticed the disoccluded pixels look pin-sharp, almost like the image is using nearest-neighbor filtering before being upscaled. Is this expected? I recall most games looking softer with newly disoccluded pixels, even if fizzle does occur in more complex scenes.

Videos

All videos are in 1920×1080 (matching the rendering resolution used to record those videos), with high-quality 4:4:4 (full chroma) VP9 encoding. Each video is about 40 MB, so previews have been disabled.

Command used to record videos:

path/to/godot.binary --path /path/to/godot-reflection/ --resolution 1920x1080 --write-movie "$PWD/fsr2_balanced/input.png" --quit-after 367 -- --fsr2 --balanced --spin

ffmpeg -r 60 -i input%08d.png -c:v libvpx-vp9 -pix_fmt yuv444p -crf 15 fsr2_balanced.webm

Using same scale factors as FSR2 for easier comparison. ↩

mrjustaguy · 2023-09-01T07:57:55Z

there are some that don't look smooth and exhibit very similar FSR 2 behaviors, such as Star Wars Jedi Survivor mentioned above, though that is the only FSR 2 game where I've heard of such complaints so could be just bad implementation there too, and not an actual FSR 2 issue.

DarioSamo · 2023-09-01T11:44:53Z

@DarioSamo I've noticed the disoccluded pixels look pin-sharp, almost like the image is using nearest-neighbor filtering before being upscaled. Is this expected? I recall most games looking softer with newly disoccluded pixels, even if fizzle does occur in more complex scenes.

That sounds about right to me. You can check the sample in https://github.com/GPUOpen-Effects/FidelityFX-FSR2 as well if you'd like a reference to compare to from AMD themselves, but I don't think anything in the implementation could cause that.

Saul2022 · 2023-09-01T15:08:00Z

We'll probably see the biggest gains when the render list is sorted in a way that only renders static geometry first and dynamic geometry afterwards.

Yea though if you plan to add it will there be a sething where we choose if an object is static or dynamic ?, kind of similar to bastian pr, but for geometry.

DarioSamo · 2023-09-01T15:52:46Z

Yea though if you plan to add it will there be a sething where we choose if an object is static or dynamic ?, kind of similar to bastian pr, but for geometry.

Nope, the plan would be to auto-detect it based on whether the element has moved or not.

DarioSamo · 2023-09-01T16:53:22Z

Did all the changes that I marked on the TODO list as well as change the logic and possibly fixing that compilation error pointed out for MINGW.

Saul2022 · 2023-09-01T17:33:10Z

Nope, the plan would be to auto-detect it based on whether the element has moved or not.

Alright, but it can have an effect even dissabling taa? I mostly ask, because it could fix this issue indirectly #73411 (comment)

DarioSamo · 2023-09-01T17:35:04Z

No, there would be no effect when TAA or FSR2 isn't used as the performance degradation comes from writing motion vector information. If motion vectors aren't required, then there's no point in splitting the render lists.

DarioSamo · 2023-09-04T14:38:04Z

I've added the optimization we talked about, a new type of render list for geometry that requires motion vectors will be used when FSR2 is used and motion is deemed as necessary. This should lead to significant savings in bandwidth since only geometry that moves will write motion vectors.

This improvement could be extended to the TAA shader once it's able to derive motion vectors from depth, but that'll probably be best separated into its own PR as there are some design changes that are required on the algorithm to support it correctly.

Calinou · 2023-09-12T15:20:50Z

Likewise DOF doesn't work at all with FSR 2 turned on

DoF in Godot is dependent on input resolution (i.e. before upscaling), given how the DoF strength is currently never scaled according to resolution. #57210 needs to be salvaged to prevent this.

Rytelier · 2023-09-15T14:23:07Z

There appear to be ghosting related to moving shaders which probably should be investigated.
I tested it on a "mirror" camera viewport shader which has ghosting when moving shader's camera.

DarioSamo · 2023-09-15T14:29:42Z

There appear to be ghosting related to moving shaders which probably should be investigated. I tested it on a "mirror" camera viewport shader which has ghosting when moving shader's camera.

I'm not sure there's much to investigate here, it's not gonna grab motion vectors from a flat animated surface. Godot doesn't support sampling the motion vectors from your other render target.

The best we can hope for is to allow people to be able to output to the reactivity mask somehow, but that's not a feature that Godot currently has as a render target. I'm fairly sure you'd find the same problems with TAA as well.

An specific draw mode for surfaces like this might be a good idea, like proposed here #77523.

DarioSamo · 2023-09-22T14:31:27Z

I've verified DOF is broken when using FSR2 as it was suggested on a comment before, will look into fixing it.

DarioSamo · 2023-09-22T17:16:09Z

@mrjustaguy DoF should be working now, thanks for the report.

Calinou · 2023-09-22T18:36:22Z

I've tested performance again on https://github.com/Calinou/godot-reflection/tree/fsr2-test with the latest revision of this PR (cf3fd3b1a). All tests done in 3840×2160 on a GeForce RTX 4090.

No AA: 334 FPS (3.00 mspf)
Native TAA: 264 FPS (3.79 mspf)
FSR2 native: 227 FPS (4.40 mspf)
FSR2 quality: 358 FPS (2.80 mspf)
FSR2 balanced: 405 FPS (2.47 mspf)
FSR2 performance: 459 FPS (2.18 mspf)

PS: Is #81350 incorporated in this PR? I've tested the latest revision of this PR, but mipmap bias isn't adjusted according to AMD's formula when FSR2 is enabled. This is noticeable if you decrease resolution scale all the way down near a checkerboard texture. Further manual changes of the Texture Mipmap Bias project settings aren't visible either.

InitialCon · 2023-09-22T20:39:43Z

Testing out this PR with Screen Space Reflections enabled and it seems that using FSR2 causes them to be even more jittery than when using the built-in taa. Is this a bug or just a downside of them being less blurry?

I'm using @Calinou's reflection test scene with normal settings.

Calinou · 2023-09-22T20:42:49Z

Is this a bug or just a downside of them being less blurry?

I think this is just a consequence of SSR looking less blurry, making the jitter more obvious. SSR needs to be redesigned to take advantage of TAA jitter into account at some point.

InitialCon · 2023-09-22T20:46:26Z

Cool, just wanted to be sure in case it was a bug. I've seen the sdfgi lighting jittering a bit too but that might also be a downside of using a sharper taa solution.

DarioSamo · 2023-09-22T20:57:03Z

PS: Is #81350 incorporated in this PR? I've tested the latest revision of this PR, but mipmap bias isn't adjusted according to AMD's formula when FSR2 is enabled. This is noticeable if you decrease resolution scale all the way down near a checkerboard texture. Further manual changes of the Texture Mipmap Bias project settings aren't visible either.

Nope it's not incorporated. Now that it's merged I'll rebase it based on that (although I'll go a bit less aggressive than AMD's formula by using -0.5 instead of -1 as it causes some visible jittering)

DarioSamo · 2023-09-22T21:43:01Z

Rebased and now mipmap bias works properly. Texture quality should now be maintained better when using lower scales.

mrjustaguy · 2023-09-24T09:36:48Z

I don't remember if this was mentioned anywhere before, so here goes:
What's the plan regarding Mesh LODing with FSR2 on? Are they planned to be always running as Native LODs with FSR2 or using current behavior (which shows Lower LODs in the reconstruction that can become quite apparent, not so with Bilinear/FSR1)

clayjohn

Looks great to me! I left one nitpick on an error message, but overall the code looks very good.

I tested locally with the TPS demo and tried various post FX (DoF, Glow, Auto exposure, etc) and it appears to work well.

Let's get this merged before the next dev release so we can get some testing before beta.

servers/rendering/renderer_viewport.cpp

clayjohn

Should be good to merge after a rebase to squash the commits

DarioSamo · 2023-09-25T13:07:19Z

Done.

thirdparty/README.md

Introduces support for FSR2 as a new upscaler option available from the project settings. Also introduces an specific render list for surfaces that require motion and the ability to derive motion vectors from depth buffer and camera motion.

akien-mga

Third-party code integration looks good.

akien-mga · 2023-09-25T15:23:20Z

Thanks!

clayjohn added enhancement topic:rendering topic:3d labels Aug 31, 2023

clayjohn added this to the 4.2 milestone Aug 31, 2023

mrjustaguy mentioned this pull request Aug 31, 2023

Integrate AMD FSR 2 in the Vulkan renderer (currently, FSR 1.0 is supported) godotengine/godot-proposals#4280

Closed

Calinou added the performance label Aug 31, 2023

Calinou mentioned this pull request Sep 1, 2023

Mipmap bias slider in the project settings no longer has any effect #81214

Closed

BastiaanOlij reviewed Sep 1, 2023

View reviewed changes

DarioSamo force-pushed the fsr2-rd branch from e032da2 to b48671b Compare September 1, 2023 16:52

DarioSamo force-pushed the fsr2-rd branch 2 times, most recently from 594e4b3 to b1944df Compare September 4, 2023 14:27

DarioSamo force-pushed the fsr2-rd branch 2 times, most recently from 349b4df to 14ab457 Compare September 4, 2023 17:13

DarioSamo marked this pull request as ready for review September 4, 2023 17:15

DarioSamo requested a review from a team as a code owner September 4, 2023 17:15

bitsawer mentioned this pull request Sep 15, 2023

TAA Bad Quality #81709

Open

Calinou mentioned this pull request Sep 16, 2023

Fix massive validation errors when enabling TAA + MSAA #81775

Merged

akien-mga mentioned this pull request Sep 17, 2023

Add FidelityFX Super Resolution 2.2 (FSR 2.2.1) support. (#5) #81800

Closed

DarioSamo force-pushed the fsr2-rd branch from 1d79e2b to cf3fd3b Compare September 22, 2023 17:14

DarioSamo force-pushed the fsr2-rd branch from cf3fd3b to 93cdffa Compare September 22, 2023 21:40

clayjohn reviewed Sep 25, 2023

View reviewed changes

servers/rendering/renderer_viewport.cpp Outdated Show resolved Hide resolved

clayjohn approved these changes Sep 25, 2023

View reviewed changes

DarioSamo force-pushed the fsr2-rd branch from 57f2a16 to 2a0f6c2 Compare September 25, 2023 13:06

bruvzg reviewed Sep 25, 2023

View reviewed changes

thirdparty/README.md Show resolved Hide resolved

akien-mga reviewed Sep 25, 2023

View reviewed changes

thirdparty/README.md Show resolved Hide resolved

DarioSamo force-pushed the fsr2-rd branch from 2a0f6c2 to 057367b Compare September 25, 2023 13:37

akien-mga approved these changes Sep 25, 2023

View reviewed changes

akien-mga merged commit cd39da2 into godotengine:master Sep 25, 2023
15 checks passed

This was referenced Sep 26, 2023

Document AMD FidelityFX Super Resolution 2.2 support godotengine/godot-docs#8056

Merged

Add DLSS 2.0 support godotengine/godot-proposals#2239

Closed

Add FidelityFX Super Resolution 2.2 (FSR 2.2.1) support. #81197

Add FidelityFX Super Resolution 2.2 (FSR 2.2.1) support. #81197

Conversation

DarioSamo commented Aug 31, 2023 • edited Loading

FidelityFX Super Resolution 2.2

To verify

TODO

mrjustaguy commented Aug 31, 2023 • edited Loading

Saul2022 commented Aug 31, 2023

Calinou commented Aug 31, 2023 • edited Loading

DarioSamo commented Aug 31, 2023 • edited Loading

ettiSurreal commented Aug 31, 2023

Calinou commented Aug 31, 2023 • edited Loading

BastiaanOlij left a comment

Choose a reason for hiding this comment

BastiaanOlij Sep 1, 2023

Choose a reason for hiding this comment

DarioSamo Sep 5, 2023 • edited Loading

Choose a reason for hiding this comment

Calinou commented Sep 1, 2023 • edited Loading

Benchmark

Binary size

Visual comparison

Still scene

Scene in motion

Videos

Footnotes

mrjustaguy commented Sep 1, 2023

DarioSamo commented Sep 1, 2023

Saul2022 commented Sep 1, 2023 • edited Loading

DarioSamo commented Sep 1, 2023 • edited Loading

DarioSamo commented Sep 1, 2023

Saul2022 commented Sep 1, 2023 • edited Loading

DarioSamo commented Sep 1, 2023

DarioSamo commented Sep 4, 2023 • edited Loading

Calinou commented Sep 12, 2023 • edited Loading

Rytelier commented Sep 15, 2023

DarioSamo commented Sep 15, 2023 • edited Loading

DarioSamo commented Sep 22, 2023

DarioSamo commented Sep 22, 2023

Calinou commented Sep 22, 2023 • edited Loading

InitialCon commented Sep 22, 2023

Calinou commented Sep 22, 2023 • edited Loading

InitialCon commented Sep 22, 2023

DarioSamo commented Sep 22, 2023

DarioSamo commented Sep 22, 2023 • edited Loading

mrjustaguy commented Sep 24, 2023

clayjohn left a comment

Choose a reason for hiding this comment

clayjohn left a comment

Choose a reason for hiding this comment

DarioSamo commented Sep 25, 2023

akien-mga left a comment

Choose a reason for hiding this comment

akien-mga commented Sep 25, 2023

DarioSamo commented Aug 31, 2023 •

edited

Loading

mrjustaguy commented Aug 31, 2023 •

edited

Loading

Calinou commented Aug 31, 2023 •

edited

Loading

DarioSamo commented Aug 31, 2023 •

edited

Loading

Calinou commented Aug 31, 2023 •

edited

Loading

DarioSamo Sep 5, 2023 •

edited

Loading

Calinou commented Sep 1, 2023 •

edited

Loading

Saul2022 commented Sep 1, 2023 •

edited

Loading

DarioSamo commented Sep 1, 2023 •

edited

Loading

Saul2022 commented Sep 1, 2023 •

edited

Loading

DarioSamo commented Sep 4, 2023 •

edited

Loading

Calinou commented Sep 12, 2023 •

edited

Loading

DarioSamo commented Sep 15, 2023 •

edited

Loading

Calinou commented Sep 22, 2023 •

edited

Loading

Calinou commented Sep 22, 2023 •

edited

Loading

DarioSamo commented Sep 22, 2023 •

edited

Loading