search

spiralhalo / LumiLights

Gameplay focused visual improvements for Canvas
GNU Lesser General Public License v3.0
124 stars 11 forks source link

Screenspace reflections extremely slow under ground #59

Closed cmdremily closed 3 years ago

cmdremily commented 3 years ago

Describe the bug: Changing screenspace reflections profile from none to low, drops framerate from 80ish to 30-40ish when going under ground.

Where/when the bug happens or doesn't happen: Above ground is normal, albeit still unexpectedly high impact of SSR for a 3090. Under ground the impact from enabling SSR even on low is massive.

Screenshots or link to video:

https://drive.google.com/file/d/1WBI5UwyIB9hkDc9gDlBXb7tWfGJo4nqi/view?usp=sharing

Environment:

Content of .minecraft/canvas_shader_debug/failed/ if present (put "N/A" otherwise): N/A

Additional context: Win 10, RTX 3090, i7-8700K MCE on, 32 GiB RAM, -Xmx16G

sharpenedblade commented 3 years ago

This could be because of your hardware. The impact of SSR is not really noticeable on my igpu. What other mods do you have. Also does a shader with SSR on iris have this performance drop.

cmdremily commented 3 years ago

I forgot to mention that this is on 4K (video down sampled to 1080p, my regular streaming setup). If you're on 1080p, then 4k is 4x more pixels, could that be related?

What do you mean by Iris? Iris Plus Graphics? 8700K doesn't have that, it's Intel® UHD Graphics 630. I'm pretty sure that the iGPU is going to die if I try 4k with shaders. It could barely do 1080p with optifabric...

cmdremily commented 3 years ago

Other mods:

canvas-mc117-1.17-1.0.2005.jar cloth-config-5.0.38-fabric.jar fabric-api-0.37.0+1.17.jar fabric-carpet-1.17.1-1.4.44+v210714.jar itemscroller-fabric-1.17.0-0.15.0-dev.20210608.211652.jar libjf-1.2.0.jar litematica-fabric-1.17.0-0.0.0-dev.20210616.033538.jar lithium-fabric-mc1.17.1-0.7.3.jar malilib-fabric-1.17.0-0.10.0-dev.22+beta.1.jar minihud-fabric-1.17.0-0.19.0-dev.20210609.185508.jar respackopts-2.7.1.jar starlight-1.0.0-RC3+fabric.1.17.x.jar tweakeroo-fabric-1.17.0-0.10.0-dev.20210614.173711.jar voicechat-fabric-1.17.1-1.0.6.jar

sharpenedblade commented 3 years ago
  1. My igpu will not die at 1080p it runst at 8-10 fps
  2. My igpu normaly runs minecraft at 480p also known as the default minecraft windowed mode.
  3. 4k will slow down reflections a lot so turn on half reflection resolution, it will help a little.
  4. a 3070ti is not ment for 60 fps 4k. 30 fps in normal at 4x with a pack as heavy as lumi
  5. Underground performance loss is probably not ssr, or it is cuased by nvidia
  6. try flying under the stone platform in the void world
cmdremily commented 3 years ago

Another video, showing odd behavior even when no reflective surfaces should be in view, also showing below world (which is fine): https://drive.google.com/file/d/19guJvV110VVZPkzgDTJPKssxycTNVcjI/view?usp=sharing

Reduced to these mods, still same issue: canvas-mc117-1.17-1.0.2005.jar cloth-config-5.0.38-fabric.jar fabric-api-0.37.0+1.17.jar libjf-1.2.0.jar malilib-fabric-1.17.0-0.10.0-dev.22+beta.1.jar minihud-fabric-1.17.0-0.19.0-dev.20210609.185508.jar respackopts-2.7.1.jar

It's an OC RTX 3090, the most powerful consumer GPU available today. The hardware is fully capable of 4K 60FPS gaming of much more graphically demanding titles and it can easily push north of 300 FPS on 4K with "canvas standard" pipeline and a render distance of 17 chunks. It should be able to do more than 30 FPS looking straight down with Lumi and SSR on low.

I find it unlikely that the underground performance is caused by anything else than SSR, as toggling SSR off removes the massive FPS drop. See the video in OP and the new video in this post that shows how the FPS fluctuates wildly when moving a few blocks up or down when close to bedrock. NVIDIA being the cause seems unlikely as SSR works just fine without massive frame drops in other games like CP2077.

I tried in 1080p as well, the FPS is higher in general, but there is still a 50% ish drop in FPS when going under ground. But the FPS is so high overall that unless you're looking at the FPS counter, you don't notice it but the same behavior is still there.

sharpenedblade commented 3 years ago

I dont notice it on my igpu, so its not hardware perf, so it must be the driver, also by iris I mean the mod iris + sodium, its a different incompatible shaders mod. If you have linux installed, can you try with pop_os and the non free drivers. also post the canvas_shaderpipeline*.conf files in the .minecraft/config dir( Lumi config file). Nvidia is the cause on newer hardware many times. Lumi and cp2077 are totaly different, cp2077 doesnt even use opengl, as far as we know

cmdremily commented 3 years ago

Looking straight down, 108 FPS. Digg down twice, 28 FPS. Flip SSR off, solid 100+ FPS: https://drive.google.com/file/d/1V_Zz5wMJmVqa-tqnlZGIhD9UGL_D9apV/view?usp=sharing

To me this is indicating that there is something in the inputs to the SSR algorithm that changes and triggers a pathological case when moving down in the above video, maybe it's the texture, or the Z-buffer contents, I can't tell. But something seems broken for sure.

Here's the pipeline options: canvas_pipeline_options.zip

"I dont notice it on my igpu, so its not hardware perf, so it must be the driver," - So you're saying it's impossible that Lumi's code could have poor scaling behavior in higher resolutions, bugs, or data races that are only visible once ran on more capable hardware where other bottlenecks are removed and the timings are different?

I used CP2077 as an exemplar, SSR is not broken in this way in any other game I've seen.

"Nvidia is the cause on newer hardware many times." Source?

sharpenedblade commented 3 years ago

Before you make such broad statements, please research about opengl, graphics, and drivers in general.

"I dont notice it on my igpu, so its not hardware perf, so it must be the driver," - So you're saying it's impossible that Lumi's code could have poor scaling behavior in higher resolutions, bugs, or data races that are only visible once ran on more capable hardware where other bottlenecks are removed and the timings are different?

No, when opengl is run, first a library to call the correct functions is loaded. Then you load the system opengl lib. The system opengl lib then calls into the hardware driver which is a piece of software that says how to communicate with a piece of hardware. The driver then compiles all shaders using whatever implementation they have into proprietary gpu code, which is the according to what you tell it, is sent to the gpu to be processed, and the displayed. This is not a complete or completely correct explanation, but it is basically it. Even a 3070 or a 3060 should have the same bug, its the same driver, but this might not be the case if there is specific optimization for the 3090 that cusses the bug. The reason I used my igpu as an example is not because it is slow, but because I know the driver for it is pretty stable. Also such a high performance drop can be caused by poor reflection code, but because it is only when underground, this is not true, it should decrease performance on all hardware and resolution.

"Nvidia is the cause on newer hardware many times." Source?

experience, the driver for newer hardware isn't as polished, so there may be unknown bugs. I did not say amd or intel don't have these, just nvidia's newest hardware has a lot of bugs.

Also can you attach the videos as files to your comment, it makes viewing them easier. Can you try going under the platform in a void superflat world, and turning off shadows.

cmdremily commented 3 years ago

Before you make such broad statements, please research about opengl, graphics, and drivers in general.

I have a M.Sc. in CS and I have 23 years experience with C++, and 12 years with Java. I've written an OS kernel for a MIPS32 CPU, I've written OpenGL programs, software rasterizers, raytracers, massively parallel encoding servers and everything in-between. I have a pretty good idea about OpenGL, graphics and drivers in general.

And from my experience, if the options are: The new code with few users of feature X (4K in this case) is broken, or the library/driver that has existed for over a decade with almost a hundred million monthly users is broken (steam survey, 120M users, 77% use NVIDIA GPUs). You need REALLY strong evidence for the latter, and such evidence has not been presented hitherto.

experience, the driver for newer hardware isn't as polished, so there may be unknown bugs. I did not say amd or intel don't have these, just nvidia's newest hardware has a lot of bugs.

I have used NVIDIA GPUs exclusively (not due to fangirlism, just that at every point I've needed a new GPU, they objectively won on my scoring criteria) since I got my first Geforce 256 Annihilator card after moving off my trusty S3Virge + 3Dfx Voodoo 2 SLI combo (that thing shredded in Quake 2 and Unreal Tournament back then), and as far as I can remember during these 22 years I've not had significant issues with the NVIDIA drivers. Other than getting Twinhead to work in XFree86 on my early Gentoo machines, but that was then and the drivers were rather immature. But since Xinerama became a thing I've not really had any issues with the NV drivers, Windows or Linux, in fact it's one of the few hardware/driver combos that hasn't given me any grief as of late, and their Linux drivers have always had the best performance of any other consumer GPUs, at least until RDNA2, haven't really looked since then. I've had more issues with Intel's iGPU drivers randomly stopping to render for an application in Win10. Sure new games often get game specific optimizations later that fix game specific issues and performance. But this is mostly only the case for AAA games that push the envelope and use the latest and greatest features that have less operating hours than the more mature features like SSR. And the hardware it's not "new" in the sense of immature anymore, the card was released over a year ago.

Basically, there isn't enough evidence to believe that this is a driver bug. And there is evidence to the contrary as SSR works fine in other titles. Therefore I do not believe your assertion that it's a driver bug without further proof.

And even if it is a driver issue that somehow has gone unnoticed hitherto, then it's unlikely to only affect the 3090 SKU of the GA10x series cards as they are really only differentiated by silicone binning and VRAM type of the PCB with minor stepping variations.

Also can you attach the videos as files to your comment, it makes viewing them easier.

Just click the link, and click play. The videos are larger than what GitHub allows so that's not possible.

Can you try going under the platform in a void superflat world, and turning off shadows.

Behavior in the void below bedrock is normal both on superflat and normal worlds.

sharpenedblade commented 3 years ago

Can you make a normal superflat world, dig 2 blocks down, and check if the fps drops. If the fps does drop, please send video with alt + f3, then a video with the canvas shader profiler on. Also try with lumi no shadows, and with no sky or cloud reflections enabled. THen try on Linux, with mesa using software rendering with llvm pipe. Then try with Nvidia non free drivers, and then finally with noveue. This is the ONLY way to rule out the driver and hardware, if you cant do that, then dont assume it is not the driver.

You need REALLY strong evidence for the latter, and such evidence has not been presented hitherto.

Every implementation of ssr is different. Lumi could use a combination of fetures, that are either incompatible with the spec, but other glsl compilers in drivers work, or the Nvidia driver does not compile the ssr glsl properly and according to the spec, so it somehow breaks. The fact that it is broken on on you nvidia, is the relly strong evedence. If it is just not noticeable on weaker hardware at lower res, then why isn't in alt+ f3, the shader profiler in canvas, and when running on a igpu at 1080p, which is a situation like a 3090 at 12k.

I have used NVIDIA GPUs exclusively (not due to fangirlism, just that at every point I've needed a new GPU, they objectively won on my scoring criteria) since I got my first Geforce 256 Annihilator card after moving off my trusty S3Virge + 3Dfx Voodoo 2 SLI combo (that thing shredded in Quake 2 and Unreal Tournament back then), and as far as I can remember during these 22 years I've not had significant issues with the NVIDIA drivers. Other than getting Twinhead to work in XFree86 on my early Gentoo machines, but that was then and the drivers were rather immature. But since Xinerama became a thing I've not really had any issues with the NV drivers, Windows or Linux, in fact it's one of the few hardware/driver combos that hasn't given me any grief as of late, and their Linux drivers have always had the best performance of any other consumer GPUs, at least until RDNA2, haven't really looked since then. I've had more issues with Intel's iGPU drivers randomly stopping to render for an application in Win10.

Every ssr implementation is different, lumi could be using some new and rarely used though not so complex feature for ssr, that breaks on nvidia. AAA games have far less bugs caused by some obscure feature on specific hardware because they can test on everything. The lumi and canvas devs, which do this in spare time, cannot test on everything. This does sound like defending nvidias mistakes, becuase the nvidia linux drivers were a pain until a while ago.

Sure new games often get game specific optimizations later that fix game specific issues and performance. But this is mostly only the case for AAA games that push the envelope and use the latest and greatest features that have less operating hours than the more mature features like SSR.

Canvas, lumi, and minecraft dont get optimizations and bug fixes from nvidia, they have to live with whatever bugs the driver has. If it does something the nvidia driver breaks on, then it is broken. If the same thing happens to a AAA game, then nvidia will rush to fix it becuase it impacts their sales.

I have a pretty good idea about OpenGL, graphics and drivers in general.

Then why dont you understand that ssr isnt a "feature", it is a collection of glsl functions, and operations, to change that pixel to the reflection. Every game has a slightly different method of this. The driver has to just mess up one function, and the whole shader can break, though other games dont use that specific feature.

cmdremily commented 3 years ago

Can you make a normal superflat world, dig 2 blocks down, and check if the fps drops. If the fps does drop, please send video with alt + f3, then a video with the canvas shader profiler on.

Superflat behaves normally, as shown in the second (or was it third?) video.

Also try with lumi no shadows, and with no sky or cloud reflections enabled.

Sky and cloud reflections have been disabled the whole time, you can see this in the recordings and the pipeline config I sent you earlier.

THen try on Linux, with mesa using software rendering with llvm pipe. Then try with Nvidia non free drivers, and then finally with noveue.

I don't have a working Linux install at the moment but I disconnected the NVIDIA GPU and ran only with the Intel® UHD Graphics 630 in my 8700K at around 460p windowed (all it can do without turning into a slideshow) and I still see the same big proportional FPS drop digging down with SSR on, and not with it off. Both on Lumi Lite and Lumi 2X. Totally different hardware, totally different manufacturer and driver, same issue. See this recording for proof.

I forgot to include the shader profiler in the video above, but eyeballing the numbers when testing now I don't see any notable change when the FPS drops which is surprising. Also the frame sub times it prints only add up to around 2ms, which is a far cry from the 33ms frame times for 30 FPS that I'm getting. So I don't really trust the profile output in this case. As a sanity check to make sure it's not CPU bound on world updates, when I switch to Canvas Basic, I get 450+ FPS with my iGPU in the same spot, same view so that's not the case here (which lines up to the sum of the frame times I'm getting from the profiler, around 2 ms, it's as if Lumi's time wasn't included in the profiler.)

This is the ONLY way to rule out the driver and hardware, if you cant do that, then dont assume it is not the driver.

It's not a driver issue as it also occurs in a similar manner with totally different hardware and drivers. As I said, you need proof to blame a third party library with a much larger user base and orders of magnitude more run-hours on it.

Every ssr implementation is different, lumi could be using some new and rarely used though not so complex feature for ssr, that breaks on nvidia. AAA games have far less bugs caused by some obscure feature on specific hardware because they can test on everything. The lumi and canvas devs, which do this in spare time, cannot test on everything. This does sound like defending nvidias mistakes, becuase the nvidia linux drivers were a pain until a while ago.

It seems to me like you're feeling attacked and that you have to defend yourself? I'm on your side dude... I did the testing and problem isolation for you, I spent the effort to do screen recordings, and nailing down which exact toggle makes it behave poorly. I could have just walked away and said screw it and used OptiFabric.

Canvas, lumi, and minecraft dont get optimizations and bug fixes from nvidia, they have to live with whatever bugs the driver has. If it does something the nvidia driver breaks on, then it is broken. If the same thing happens to a AAA game, then nvidia will rush to fix it becuase it impacts their sales.

Exactly, that includes working around broken drivers or alienate a large fraction of your users, steam survey says 77% of gamers use NVIDIA. That's if they're proven broken at all, which we've successfully proven they're not.

Then why dont you understand that ssr isnt a "feature", it is a collection of glsl functions, and operations, to change that pixel to the reflection. Every game has a slightly different method of this. The driver has to just mess up one function, and the whole shader can break, though other games dont use that specific feature.

You're deflecting the argument onto minutia instead of discussing the merits. Your users don't care how it's implemented, to them it's a feature of Lumi. Call it what you want.

Look, real talk, I know many Linux folks hate NVIDIA's guts, Torvalds famously gave them the finger on camera and they messed up the whole Wayland EGL/GBM thing, and the allergic reaction some people get when they see the massive binary blob that taints the kernel. But mindlessly blaming the NVIDIA drivers out of spite and without proof, especially on Windows which is a different environment where these claimed Linux related issues are not a thing, is not a professional thing to do.

This is my honest, well intended advice for you, hard earned after doing the same mistakes in my own past: It's always a good habit to assume your own code is broken before blaming others. That way you don't end up looking the fool if/when you're wrong. I know it can feel like you've done your due diligence, you've thought of everything, you've read the specs, you've written your unit tests, you've been super careful, code compiles cleanly, you've tested manually and it works flawlessly on your hardware... but it can still be wrong, software engineering is hard and we make mistakes, that's just how it is. Being humble about it allows us to learn and move forward; otherwise we end up repeating the same mistakes.

I believe I've done as much as I can to convince you that there's a problem with Lumi, if you still want to blame NVIDIA, you can do so and I'll go use OptiFabric instead, no skin off my nose. However, if you want my help in fixing this performance issue, I'm willing to do that, but I need you to drop the blame game and work with me.

cmdremily commented 3 years ago

I take the sudden silence as you're not interested in my help. That's fine, I'll clear up the files to reduce my quota use. Best of luck with your project!

sharpenedblade commented 3 years ago

Please provide the requested information about the shader profiler, and people here are doing this in their free time, and have many more important things to do than making a vidoe look good. Please reopen this because it isnt fixed, you dont close an issue because of inactivity. Other people on windows, and me on macos and linux dont notice this, so I have no idea what is going on, there are to many things that can be different on your system. Try with only canvas, fapi, and lumi. Also why does you opengl version say 3.2, a 3090 should have up to 4.5. Can you try on a fresh win install on the same hardware, you could have changed driver settings

cmdremily commented 3 years ago

I switched to using Iris and other shader packs that don't have this issue and I don't have the free time to reinstall OSes and mess around with and break my daily driver machine. Answering your question on the shader profile: I said in an earlier message that the output was nonsensical. It seems to only have included the base time spent in canvas and not the time in Lumi because the times didn't add up.

I felt like you were trying to discourage me by telling me to do all these excessive steps like reinstall my computer to Linux and trying all the different drivers, risk breaking my daily driver setup etc that are unreasonable to expect from a user. In addition it seemed like you were more interested in blaming nvidia than considering there might be a problem with the software so I figured there was no way this was ever going to get fixed; Hence I found another shader pack and closed the bug, consider it closed as "WAI". In the same way that your time is valuable, so is mine, and I don't have any more time for this.

If you want to try to fix it, feel free to re-open but I'm done here.

sharpenedblade commented 3 years ago

While it might be nonsensical to you, it can make sence to the people who made the shader. Also as other people on 30xx nvidia cards dont report this, it must be something on your install of minecraft or win 10

cmdremily commented 3 years ago

Sure, let's say it's my windows install. Bug closed, WAI.