Rendering speed run - experimental viewer test

[animats]

Here's a speed run through Port Babbage using my experimental renderer written in Rust. This shows what's possible with modern code on a gamer PC. A recent improvement in WGPU, the cross-plaform rendering system (Linux, Windows, Mac) sped up the frame rate. This is running at 60 FPS.

(now obsolete and will be removed: https://video.hardlimit.com/w/gZXjufLwfeu7yzFavTk6tS, please use new version below.)

https://video.hardlimit.com/w/sFPkECUxRUSxbKXRkCmjJK

 

• Full mesh detail.
• Draw distance is one entire region.
• Textures are being loaded dynamically at the necessary level of detail. The system tries to maintain one texel per pixel. In a few places you'll see the texture loading catching up. Look carefully at the vendors in the store when the camera suddenly enters a store.
• NVidia 3070, 6 core / 12 hardware thread AMD CPU, 32 GB.
• Everything is in cache. (JPEG 2000 decoding is still far too slow. That gets attention next month.)
• Shadows are on, but the only lighting is the sun and ambient.
• You'll see a menu bar pop up at times. There's a menu system now. The menus are normally hidden, for a clutter-free look, but appear when the cursor touches the edges of the window. Like most video players.

This is still a long way from being usable. Progress continues.

The video is on Hardlimit, which is a federated alternative to YouTube. I use that for technical videos because they allow large files at high frame rates and don't seem to transcode it to a lower rate.

Edited July 21, 2022 by animats

[Henri Beauchamp]

Very nice, but nothing extraordinary as far as the frame rate is concerned... With the Cool VL Viewer, I get 30 to 220 fps in roughly (*) the same conditions, but with a weaker GPU (GTX 1070 Ti ”only”) and with a 1920x1200 screen, and with the handicap of the JPEG2000 image decoding.

While I do admire your work, I'm sad that you chose to rewrite your viewer from scratch, and in Rust, instead of contributing a Vulkan renderer and/or a better image fetcher/decoder to the existing C++ code base...

(*) The viewer cannot rez just a single sim like yours do, so the draw distance must be kept lower (between 128m and 192m while following your track in Port Babbage) than I normally keep it (256m for sims with neighbouring sims) to avoid rezzing too many things from the neighbouring sims, which of course slows down the frame rate. It would be simpler to compare if you could choose an island to make your tests: then I'd push the DD to 512m (as I always do in islands) and we would have a way better ground for performances comparisons.

[Extrude Ragu]

3 hours ago, Henri Beauchamp said:

Very nice, but nothing extraordinary as far as the frame rate is concerned... With the Cool VL Viewer, I get 30 to 220 fps in roughly (*) the same conditions, but with a weaker GPU (GTX 1070 Ti ”only”) and with a 1920x1200 screen, and with the handicap of the JPEG2000 image decoding.

I'd love to know what you're doing to get 220fps in Cool VL Viewer.

I just tried this same test, went to Port Babbage on a fresh install of Cool VL Viewer

Graphics preset ultra... I did change ALM to Sun/Moon only,, I'm getting 20fps max. Running windowed. Window size  1858 x 1057

Hardware info and all that:

Cool VL Viewer v1.30.0.8, 64 bits, Jul 16 2022 11:01:42
RestrainedLove viewer v2.09.29.27
Release notes

You are at 161863.2, 257451.3, 105.8  in Port Babbage located at
simhost-01f3ee741ab37953e.agni.secondlife.io (35.86.162.11:13002)
Alias: ec2-35-86-162-11.us-west-2.compute.amazonaws.com
Second Life Server 2022-07-06.573149
Release notes

CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (3997.69 MHz)
Memory: 16317MB
OS version: Microsoft Windows 10 64 bits v10.0 (build 10586.1826)
Memory manager: OS native
Graphics card vendor: NVIDIA Corporation
Graphics card: NVIDIA GeForce RTX 2060/PCIe/SSE2
Windows graphics driver version: 30.00.0015.1109
OpenGL version: 4.6.0 NVIDIA 511.09
Detected VRAM: 6144MB
J2C decoder: OpenJPEG: 1.4.0.635f
Audio driver: FMOD Studio v2.02.07
Networking backend: libcurl 7.47.0/OpenSSL 1.0.2u/zlib 1.2.11.zlib-ng
Embedded browser: Dullahan 1.12.3/CEF 91.1.21/Chromium 91.0.4472.114
Packets lost: 657/601147 (0.1%)

Built with: MSVC v1916
Compiler-generated maths: SSE2.

Compile flags used for this build:
/O2 /Oi /DNDEBUG /D_SECURE_SCL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /std:c++14 /EHs /fp:fast /MP /TP /W2 /c /nologo /GS- /Zc:threadSafeInit- /DLL_WINDOWS=1 /DUNICODE /D_UNICODE /DWINVER=0x0601 /D_WIN32_WINNT=0x0601 /DLL_PHMAP=1 /DLL_NETBIOS=1 /DBOOST_ALL_NO_LIB /DLL_FMOD=1 /DAPR_DECLARE_STATIC /DAPU_DECLARE_STATIC /DXML_STATIC /DCURL_STATICLIB=1

 

[animats]

3 hours ago, Henri Beauchamp said:

While I do admire your work, I'm sad that you chose to rewrite your viewer from scratch, and in Rust, instead of contributing a Vulkan renderer and/or a better image fetcher/decoder to the existing C++ code base...

LL started on a better image fetcher with a proper priority queue as part of Project Interesting, some years back. There's an abandoned project viewer where you can see the remnants of that cancelled effort.

It's difficult to make major changes to the LL family viewers. I've contributed code to Firestorm. I put in the improvement to interpolation that made sinking and flying into the air at region crossings a thing of the past. But the kind of changes I'm doing here are way beyond what one can do from the outside.

It's 20 year old single-thread code. Retrofitting reliable multi-threading to old C++ code is difficult. The enormous advantage of doing this in Rust is that the code does not crash for unknown reasons. There are no bad pointers. There are no race conditions. Those are all caught at compile time. Once all the compile errors are fixed, the code usually works. In two years I have not needed to use a debugger. For hard problems like this, Rust is the way to go.

All this is still at the proof of concept stage. I've told some of the Lindens that it's too soon to use this approach for anything with a deadline. As yet, no AAA game title has been written in Rust. The foundations of the Rust 3D graphics ecosystem are not solid yet. I'm relying on multiple Rust packages that are still under heavy development. Enough people are working on them that the pieces are coming along.

The question is whether we can have metaverses with user created content, a big world, and the visual quality and performance of AAA games. The answer appears to be yes. There are people who have said this is impossible. It's not. It's just hard.

 

 

[Henri Beauchamp]

56 minutes ago, Extrude Ragu said:

I'd love to know what you're doing to get 220fps in Cool VL Viewer.

I just tried this same test, went to Port Babbage on a fresh install of Cool VL Viewer

Graphics preset ultra... I did change ALM to Sun/Moon only,, I'm getting 20fps max. Running windowed. Window size  1858 x 1057

Like I wrote in my first reply, I used roughly equivalent settings to those of Animats' viewer. In particular, his viewer does not render water reflections, neither transparent water, it does not render avatars, it does not render particles, all of which are extremely taxing on the frame rates... Also, I had to adjust the draw distance, to keep the camera FOV at the limit of the sim border (since his viewer renders just one sim, while normal viewers render whatever is in the draw distance and camera FOV, including in neighbouring sims).

Finally, 220fps was the highest I got, not the average, which was closer to 60fps, with dropouts to 30fps or so, during textures decoding/rezzing.

If you still do not believe me, here is a capture I just did. Note the settings, the FOV in the mini-map (that's the hardest thing to reproduce to allow a proper comparison, thus my suggestion to do a test in an island instead), and how the textures rezzing slows down the frame rate (I tried to demonstrate this at the end of the video, especially since my viewer got a boost feature for textures rezzing that is great to rez them super fast, but does impact the frame rate while they rez).

Edited July 21, 2022 by Henri Beauchamp

[Henri Beauchamp]

12 minutes ago, animats said:

It's 20 year old single-thread code. Retrofitting reliable multi-threading to old C++ code is difficult. The enormous advantage of doing this in Rust is that the code does not crash for unknown reasons. There are no bad pointers. There are no race conditions. Those are all caught at compile time. Once all the compile errors are fixed, the code usually works. In two years I have not needed to use a debugger. For hard problems like this, Rust is the way to go.

The renderer needs a rewrite to use Vulkan instead of OpenGL, yes... But threading is a piece of cake to do in C++, especially with Nat Linden's excellent work in the ”performance viewer” and the addition of new threaded work queues. Once the renderer converted to Vulkan, threading it will be also waaaaay easier.

As for Rust vs C++, I'm afraid you will not convince me... but I guess that's just because I'm a C programmer at heart. 😛

[Extrude Ragu]

Just so you can see what I'm experiencing.. I do show my settings here and tried to match them up to yours. It's strange to me because I don't think our hardware is that dissimilar in capability, you can see that my frame rate totally tanks whenever the camera gets moved and stays tanked for a long time, with the scene taking a long time to load (Especially noticeable at 5:00 to 6:30)

[Extrude Ragu]

Running off an SSD too

It's not that I don't believe you it's just bizarre to me that my experience is so different

 

[Henri Beauchamp]

22 minutes ago, Extrude Ragu said:

Just so you can see what I'm experiencing.. I do show my settings here and tried to match them up to yours. It's strange to me because I don't think our hardware is that dissimilar in capability, you can see that my frame rate totally tanks whenever the camera gets moved and stays tanked for a long time, with the scene taking a long time to load (Especially noticeable at 5:00 to 6:30)

There is an issue with the driver (recent NVIDIA drivers have various issues), as shows the bogus red color of the UI (chat input line for example)... Try and downgrade to a driver that does not show such an issue. Make also sure you did set up your driver to use multi-threading (some TPVs use the NVAPI under Windows to force this on for themselves with NVIDIA cards, but my viewer does not, meaning you must properly configure your driver for it).

Also, your CPU is old (4790K @ 4GHz) and, once the GPU powerful enough (which is your case), the SL viewers frame rates scale almost proportionally to the CPU mono-core performances... In comparison, I got a 9700K @ 5GHz; look at the viewer log, at the very start, and you will see a micro-benchmark result I added (”CPU single-core performance factor relative to a 9700K @ 5GHz”), that will give your your CPU mono-core performance ratio compared to mine.

Finally, you are running the viewer under Windows, and running it under Linux would give you a 15-20% speed boost...

Edited July 21, 2022 by Henri Beauchamp

[Extrude Ragu]

3 minutes ago, Henri Beauchamp said:

There is an issue with the driver (recent NVIDIA drivers have various issues), as shows the bogus red color of the UI (chat input line for example)... Try and downgrade to a driver that does not show such an issue.

Also, you CPU is old (4790K @ 4GHz) and, once the GPU powerful enough (which is your case), the SL viewers frame rates scale almost proportionally to the CPU mono-core performances... In comparison, I got a 9700K @ 5GHz; look at the viewer log, at the very start, and you will see a micro-benchmark result I added, that will give your your CPU performance ratio compared to mine.

Finally, you are running the viewer under Windows, and running it under Linux would give you a 15-20% speed boost...

Yes the CPU is admittedly quite old I brought it back in 2015, although I would have thought at 4GHZ clock speed per core it would not be that much slower, maybe I am wrong though I am not a hardware expert

How far back do you recommend with GPU drivers?

[Henri Beauchamp]

12 hours ago, Extrude Ragu said:

Yes the CPU is admittedly quite old I brought it back in 2015, although I would have thought at 4GHZ clock speed per core it would not be that much slower, maybe I am wrong though I am not a hardware expert

Check the micro-benchmark ratio in the viewer log, and you will see...

12 hours ago, Extrude Ragu said:

How far back do you recommend with GPU drivers?

Not sure for Windows... Linux had bogus 515 drivers, but they got fixed now... The bugs appeared at the end of May.

EDIT: this is not a NVIDIA driver bug, but a Windows 11 bug that got apparently introduced in the last (July 2022) patch Tuesday update (KB5015814, perhaps ?). I just updated my third PC's Windows 11 partition and suddenly saw that bug happening; since that PC uses an old GTX 460 card which driver did not get updated in many months (it went out of support for Win11), it cannot be the fault of that driver (that worked beautifully). After installing the latest preview update (KB5015882), the bug seems to have been cured (your other option being to revert the July updates).

Edited July 22, 2022 by Henri Beauchamp

[Paul Hexem]

LL is hiring people that have been out of the loop for decades to play on twitter instead of paying for this work. Blows my mind.