Shaderpack and Resourcepack compatibility? Optifine?
LiberteIV opened this issue · 17 comments
I'm on minecraft 1.19.1
Using seus shaderpack and patrix resourcepack.
I'm also using optifine to make seus shader work and for better performance, plus a sound physics mod for better sound.
To make this combination of mods work together i'm using the fabric launcher.
I placed the 1.19.x version in the mods folder where the other mods are, game crashed on startup.
Starting with fabric loader and ONLY vulkanmod does work, combining this with optifine crashes instantly.
Starting with optifine launcher and vulkanmod crashes instantly.
I could share the crashlog. Any future plans for compatibility, who must provide compatibility? You? Optifine creators? Both?
How are chances this combo might ever work in the future?
https://fabricmc.net/use/installer/
https://optifine.net/downloads
https://www.curseforge.com/minecraft/mc-mods/optifabric/files
https://www.curseforge.com/minecraft/mc-mods/sound-physics-remastered/files
https://github.com/xCollateral/VulkanMod
https://www.patreon.com/sonicether
https://www.patreon.com/patrix
Update:
This is what jellysquid3 had to say regarding Sodium Support for VulkanMod:
Yes, of course, Vulkan is going to have less overhead than OpenGL, but the slowness in Minecraft is due to a poor use of OpenGL. Sodium is proof of the fact that a decent OpenGL implementation can be significantly faster to a barebones Vulkan port, without needing to rewrite every line of rendering code in the game.
Sodium 0.5 already provides a GFX abstraction which it uses instead of OpenGL directly, so that if someone else wants to write a "Vulkan Minecraft" mod they can do it themselves, and implement the GFX API that Sodium needs. But we're not doing it ourselves, and we think either contributing to Zink (OpenGL-on-Vulkan driver that's usable for any application) or Sodium itself is a better option than trying to rewrite the entire game.
Interesting, i asked sodium for vulkan support, they said it's not planned. Which is sad because both mods greatly increase peformance, both together would fit perfectly.
... But xCollateral said, that it is planned to implement his own shaderpack format, so in future there will be shaders support.
That sounds very promising! Considering how effective vulkan is over opengl i don't understand why optifine and sodium/iris are not willing to support it, after all optifine and sodium are performance mods and that's exactly what vulkan is.
It is not worth doing this, I am 200% sure that the sp614x will not rewrite Optifine to Vulkan. Of cource you can try, but I > don't think you'll be able to convince him. Besides, now Optifine is a big bunch of unnecessary functions that slows down the > game and breaks compatibility, so it would be more logical to adapt Sodium instead.
Optifine supports fabric and forge and even can be installed as a launcher on it's own, why not also support 2 API's?
Sure opengl has been the standard for years now.. but that doesn't change anything about the fact that vulkan has way better performance and optifines is a performance mod, it would just be logical to merge?
First time hearing about new optifine functions that slow down the game, which functions are that, how big is that impact, if you don't mind me asking?
It sounds wired that a performance mod would implement uneccessary functions.
About adapting sodium, the performance from sodium compared to optifine is a noticable better, but optifine still does a good job there aswell.
Patrix does not support sodium, the resourcepack does work but it looks disgusting compared to using it with optifine.
Patrix is by far the most advanced and realistic looking resourcepack out there, losing that is a big minus.
On patrix site https://www.patreon.com/posts/free-1-19-32x-69530757 i read this:
For Optifine users, make sure these settings are set correctly, or else the textures/models will get messed up: "..."
For Fabric/Iris-based mods users, good luck I guess.
So he doesn't support it.
A bit sad that the big players provide no compatibility for their creations.
This is fabric+optifine+optifabric+seus+patrix
This is fabric+sodium+iris+seus+patrix
So it's optifine that needs to provide compatibility
Yes, at this point each mod that uses calls to OpenGL will crash with VulkanMod, Sodium too. In theory, it is possible to merge the graphics engine from Sodium with this mod (afaik VulkanMod uses vanilla Blaze3D, I could be wrong), but it is not the main priority or what someone plans to do at all.
sad that optifine shader isn't compatible
... But xCollateral said, that it is planned to implement his own shaderpack format, so in future there will be shaders support.
i will ask Optifine devs
It is not worth doing this, I am 200% sure that the sp614x will not rewrite Optifine to Vulkan. Of cource you can try, but I don't think you'll be able to convince him. Besides, now Optifine is a big bunch of unnecessary functions that slows down the game and breaks compatibility, so it would be more logical to adapt Sodium instead.
Optifine is incompatible with VulkanMod.
Thanks for the info i tought so.
May i ask why exactly is the incompatibility? Would Optifine need to be "reworked" to support VulkanAPI ?
I tested OpenGL and Vulkan now, result is a 400-600 FPS gain with Vulkan.
Using OpenGL is wasted performance, very sad that optifine shader isn't compatible.
So it's optifine that needs to provide compatibility and not your API mod, correct? Then i will ask Optifine devs.
Update: This is what jellysquid3 had to say regarding Sodium Support for VulkanMod:
Yes, of course, Vulkan is going to have less overhead than OpenGL, but the slowness in Minecraft is due to a poor use of OpenGL. Sodium is proof of the fact that a decent OpenGL implementation can be significantly faster to a barebones Vulkan port, without needing to rewrite every line of rendering code in the game.
Sodium 0.5 already provides a GFX abstraction which it uses instead of OpenGL directly, so that if someone else wants to write a "Vulkan Minecraft" mod they can do it themselves, and implement the GFX API that Sodium needs. But we're not doing it ourselves, and we think either contributing to Zink (OpenGL-on-Vulkan driver that's usable for any application) or Sodium itself is a better option than trying to rewrite the entire game.
Sadly, most mod creators will not do it IF the Vulkan mod is not used by huge chunk of players on Minecraft. I tried sodium, but Vulkan mod has better FPS stability on my RX 460 GPU than Sodium, & all combined performance mods
I might be able to give some insight into this as I have submitted PRs for this repo before.
At least with the Shaderpack/texture pack issue, I do concur that this mod is very badly in need of a viable ShaderPack loader/HotSwapping to allow tapping into some unused features (Instantaneous Shader Loading, PBR/POM Textures in tandem with RTX/RDNA Accelerated Ray/Path tracing Shaders, Compute/GPU driven Culling, Use multiple shaders at a time e.g.),
I don't know how to use OpenGL, but at least with Vulkan shaders cannot be loaded directly on their own and they must be attached and bound to a separate pipeline first before they can be used by the Renderer and integrated with the other 54 RenderLayers/Shaders.
The inverse is true when unloading shaders as the pipeline must be manually decoupled and unloaded directly before removing the shaders themselves without crashing the game or causing graphical seizures/bugs which is fiddly and tricky to do on the fly while the game is running/active rendering is taking place.
The first problem with this is that While Vanilla has a built in system that is somewhat similar (RenderLayers), RenderLayers are very limited in that only one can be rendered at a time (This is a headache when rendering VBOs as 5 are needed just to render a chunk and if the wrong one is used the game can crash) and are also hardcoded and cannot be disabled without manually removing them from the code. (Which is a major problem as modularity cannot be achieved which is needed for ShaderPack Hotswapping as RenderLayers cannot be added/removed at will)
Another problem is that while VulkanMod does have a builtin shader loading system that works very well, (is that loads Vulkan Compatible (SPIR-V) shaders and transforms them/RenderLayers into Pipelines that can be used with Vulkan,) the issue with this is that JSON files are needed to setup the Pipeline layout for each Shader pair (Fragment and Vertex Shaders) to ensure the pipeline has the correct layout to load the shaders properly.
In a hypothetical Shaderpack format, the ShaderPack author will need to setup the JSON files manually which is annoying and very easy to mess up which makes a Hypothetical ShaderPack format for this mod more complicated and less friendly and approachable than Other Shader Loaders(e.g. Optifine, GLSL Mod, Iris Mod e.g.), these JSON files are also too complex to be generated automatically and as the JSON system works so well there is not good alternative to it, which makes setting up a viable format possible but also a convoluted mess and a nuisance from the ShaderPack author's Perspective.
While I did think about trying to implement this in a PR, I decided that instead it my be better to fix the abysmal DrawCall issues with Chunk Rendering and to get the game in a more playable state first before moving to tackle the Shader Loader/Hotswapping. The reasoning being that simplifying Chunk rendering and RenderLayer mess in Vanilla may help to simplify implementing Shader HotSwapping anyway.
Other options are also possible (i.e. Sodium API, Iris mod), however as those mods/tools are predominantly designed/intended for OpenGL, I'm not 100% sure if they are designed or intended to be capable of handling the flexibility and modularity needed to handle Shader loading with this Mod, and doing so will require intensive modification/hacks that would, likely be more complicated than this mod is currently. (Prob 100% wrong about this as I can't use OpenGL).
The only other thing I might mention is that in theory porting ShaderPacks to Vulkan is surprisingly straightforward as OpenGL/Vulkan both use the same shader format (GLSL), and outside of changing the Uniform/binding layouts/syntax and dealing with the JSON layout file for loading/setting up the Pipeline Layout, little else needs to be changed as the actual shader code can be kept intact AFAIK. (Can also use HLSL so Bedrock shaders/DirectX Shaders if they exist may also work)
@vcmp Can you create a new issue with steps to reproduce this chunk loading bug?
bro optifine doesn't even run on fabric. you need to use iris to run your glsl shaders.
(ignore, am mostly/somewhat wrong about the below, and this isn't a bug (as is from a custom fork))
Please ignore what I said above as that bug is due to a fork/PR I did on my own when I was testing changes I made in an attempt to improve chunk rendering. This doesn't appear normally as the chunk rendering CompletableFutures used in vanilla code are either forcibly synchronised with the Chunk Loading or it isn't fast enough to make it appear.
The glitch occurs where the chunks render too quickly before the next chunk is loaded (due to CompletableFuture bugs), causing the wrong ChunkOffset PushConstants to be used in the BlockLayer Shaders (i.e. rendertype_cutout_mipped), which itself causes the Chunk Vertex Buffers to be translated to the wrong position after being multiplied with the MVP matrix in the shader.
In other words, this bug doesn't exist on the main repo or the current version of the mod, and is caused from stupid experiments I made messing with the chunk rendering code on my own, so you don't need to worry about dealing with it and therefore it doesn't need a new issue as it only exists in my current fork I'm testing with that I made a couple of months ago.
I also edited out the image and mention of the PR I'm working on as while it it technically related to this issue it doesn't however answer OP's question so I'll save that for the PR if I'm able to (mostly/hopefully) finish it.
bro optifine doesn't even run on fabric. you need to use iris to run your glsl shaders.
This is a port and not the original optioned. Also preferring this over Iris and sodium is just dumb because you‘ll loose frames.
I don't know how to use OpenGL and am mostly a noob with Vulkan, but afaik Iris/Optifine are designed and only intended to handle OpenGL Shaders, while technically OpenGL and Vulkan shaders are compatible as they use the same GLSL format (might even be possible to port Iris/Optifine/Bedrock shaders over to Vulkan), on the other hand the actual shader loading system used in OpenGL is completely different and fundamentally incompatible with the Pipeline Shader module system that Vulkan uses, despite the fact that technically the shader itself is exactly the same.
I am probably horribly biased towards this mod, but imo i currently think it has a lot of potential and its current performance is highly limited by the high CPU overhead and inefficiency of vanilla code, which I suspect could be greatly improved if many of these limitations are lifted. It is also the only Vulkan mod afaik that is actually stable and works properly as their have been many failed/broken attempts over the years.
atm I'm working on trying to setup a PR to experiment with how chunk rendering is handled to mitigate some of the performance bottlenecks/limitations, however that is mostly for fun as an excuse to mess around with the code and to get a better handle with Vulkan, so whether it actually gets finished and gets into a workable state is another matter.
afaik one of the more powerful unused Vulkan/OpenGL features available is Multi-Draw Indirect, which if possible would allow for the ability to render all chunks in game at the same time with a single draw call as well as supporting GPU-based Culling, which at least in theory would allow for the ability to improve rendering/frustum culling efficiency many times over and give insane performance gains, especially at large render distances.
However it is a pain to setup (all chunks must be combined into a single "UberChunk" which must be perfectly separated with the correct offsets to avoid turning the world into a paper shredder) and is completely untested so unless it can actually be used i'm not 100% sure if it actually works in that exact manner or if it will even make that much of a difference.