Flywheel is not supported

[weegeeluigi]

What happened?

I've posted a large bug report on the create github already found here. Basically the moment shaders are enabled, there is a severe and unplayable FPS hit with the create mod running. I'm not sure where the fault lies so I'm opening something here as well. Getting close to the area with create entities completely pulverizes FPS and shows a large bottleneck as the GPU usages drops like a lead weight and 3D clocks don't get activated. I use complementary v4.4 (v4.3 has the same issue and I used that since world creation). Walking away from the create contraptions will slowly make the issue go away. With the same seed in a new world, just a small amount of create entities already substantially hit the FPS. I'm not sure if it's a system issue with just me, if this is expected with create and shaders (turning shadows off with small amounts of create entities helps in the test world, but in my real world it makes no difference at all). I'm attaching the screenshots and profiler zip here that I logged there as well as quoting what I wrote in the create github bug report:

The moment shaders are enabled, performance takes an unplayable hit resulting in an obvious bottleneck that is preventing GPU usage from increasing. The shaders I use are complementary v4.4, but I've tried a bunch of others and all result in the same problem. I've tried swapping to GravalVM and Open J9 to see if it's a Hotspot issue but nothing changed (in fact J9 made the performance plummet even more, down to literally a handful of frames). Originally I thought this world is just pushing the limits of contraptions and shaders, but upon creating a new test world with the same seed, dropping barely anything in it, the problems start to show themselves and the FPS drop is already significant.

I have 2 kelp farm based furnage engines. a windmill, and a bunch of automated belt lines for crushing, washing, blasting, mixing and pressing. Based on some of the nutty things I've seen people build, I'm not even convinced this is "a lot". My included screenshots will show the base (in the screenshots, the large, long building is empty). I have included screenshots with the RTSS overlay showing the issue both in the "real" in use world, and the test world, made with the same seed, to show the perf without create objects in it, and with, and what contraptions I have in the world. You'll have to pardon the need to zoom in to see anything since I play at 5120x1440 so the shots are "interesting".

When I start to walk away from the area, the screenshots will show the FPS bounce back up and eliminating the small hit printscreening does, I go back up to 70FPS and higher with shaders fully on blast once I've walked far enough away and am not looking towards the direction of the create setups. In the test world, standing still I can get up to 110+ FPS in the spot I took the screenshot in, but dropping just the schematic of the iron farm I use and the schematic of my furnace engine kelp farm setup already drops the FPS considerably, and the furnace engine setup isn't even running. Also moving close to the iron farm and walking already shows the clock speeds and usage starting to show the dropping behavior just with this stuff in it, standing still will bring it back up but moving immediately drops it. The FPS in this shot is already below 50.

Despite having the nvidia panel set to always go to max perf, and I even have nvidia inspector Multi display power saver running telling the system to forcefully activate 3D usage with X% usage, 15% to be exact to test, although I start to wonder if the driver is overriding this, there is something holding clocking back big time as the clocks stay locked at 1350mhz in the issue, despite the usage being reported at or above the 20% mark, and as I back away from the area they slowly start to crank up. Forcing the clocks locked at 2100mhz maybe add an FPS or two but the low clocks aren't the perf problem, they are just an interesting symptom of the bottleneck.

This is with build Creators-of-Create/Create#548 and Iris and sodium, and sodium's respective add-ons lithium, indium and phosphor, are all latest. I have gone back to the first working and least bug free of the early 1.18.2 builds and same thing happens with those. The log has nothing in it being spammed to indicate an issue so instead of I have launched the built in profiler and attached it here. Note, I have tested the idea that Iris and complementary's shadowing is the problem, but despite turning off real-time shadows, block and entity shadows fully off, no difference is made. Something is just really turning off Iris somewhere. Maybe my world is asking too much, maybe my system just has an issue. This funky FPS problem has left me scratching my head for I cannot pinpoint whose at fault, even if I make a test world and start blowing away contraptions the issue only really goes away fully once everything is gone.

Screenshots

Relevant log output

Link to profiled run

https://github.com/Fabricators-of-Create/Create/files/8647319/IrisCreatePerformance.zip

Minecraft Version

1.18.2

Iris Version

1.2.4

Sodium Version

sodium-fabric-mc1.18.2-0.4.1+build.15

Operating System

Windows 10

What is your GPU?

2080TI

Java Version

Java 17

Additional context

No response

[coderbot16]

Create through Flywheel uses a highly-optimized rendering engine normally, but when Iris is enabled it has to use a slower fallback because this optimized rendering engine is not currently compatible with how Iris rendering works. On top of this, Iris also has to render the Create content twice using this slower fallback path with most shader packs to implement dynamic shadows.

It is possible to make it compatible, but this is quite difficult to implement and will require quite a sizable amount of preparatory work in Iris to be feasible.

[Mirsario]

Installing this mod completely or almost completely fixes this:
https://www.curseforge.com/minecraft/mc-mods/iris-flywheel-compat

[KevinCCucumber]

Would this integration be possible as a standard?

[iTrooz]

Could a member of the repository comment on the negative effects of this mod (https://www.curseforge.com/minecraft/mc-mods/iris-flywheel-compat) ?

Since this is not done by default, I assume that this has some downsides

[IMS212]

The negative effect is that it isn't supported by either team, and almost always breaks on a Create or Iris update. It's a brute force method that relies on both mods not changing at all.

[weegeeluigi]

Could a member of the repository comment on the negative effects of this mod (https://www.curseforge.com/minecraft/mc-mods/iris-flywheel-compat) ?

Since this is not done by default, I assume that this has some downsides

OP here, funny enough I never noticed this was pinned and forgot I even made this issue. I've used it, for the most part it works "fine". There are some glitches but it depends on the other mods you have installed and some shaders get merged improperly (the mod attempts to merge flywheel shader code with your actual shaders which can lead to bugs). The biggest bugs happen when you use PBR, regardless of implementation. Each update also breaks it, and given the difficult nature of what it tries to do by brute forcing shader code merging, it's not frequently updated either. It was just updated today, but the author doesn't post much so you don't really know what they are up to. If the mod gives you issues and breaks just stop using it. It's nothing against the dev, it's just a hard problem to solve and this mod is really a hacked workaround, what we need is a native backend to flywheel that is compatible with Iris.

The next releases of flyhweel (and sodium and iris) will begin to pave the way for a native solution to making things compatible. Someone will still need to go in and make the backend compatibility layers, but slowly it's getting there.