30 seconds of shader compilations on first run doesn’t sound too bad to me? Most games do a loooot longer.
It doesn’t sound bad that Eevee Next compiles a first run up to 10x slower than Eevee?
And that’s not a theoretical or funny number I’m just throwing out there for impact - I counted the seconds.
I just tried it with another scene (the one I’ve used above for many examples). Eevee was basically instant, under 2 seconds. Eevee Next was nearly 10 seconds.
Another test, just performed / first time load:
Eevee compile time: :41 seconds
Eevee Next compile time: 3:04
3 Likes
Few days ago I did some tests and in 1 minute on my PC (3600X/GTX1660) Blender (4.2) compiles ~116 simple shaders for the EEVEE-Next, while UE5 (5.4) compiles ~1100 complex shaders.
2 Likes
At the risk of sounding reductive, Eevee isn’t a game engine. This is an apples to orange comparison
1 Like
I have repeatedly tried telling this to the UPBGE guys who have bet their entire engine on the idea that it will become fast enough for realtime, but they keep insisting that it will get there, and their games will be playable on an average machine when they finish development.
On compiling, Vulkan should improve on this in theory, but we will still need a pretty decent GPU for complex stuff.
The shader cache is managed by the GPU driver. Based on my testing on Windows with a Nvidia GPU, the shader cache is shared between different Blender versions. This means that when you update to a new Blender version, you still have a semi-useful shader cache. I say semi-useful because some of the shaders may have changed due to code changes and need to be compiled again because their current form is not in the cache.
Due to development primarily focused on EEVEE-Next, it’s much more likely that a shader would of changed in EEVEE-Next and not EEVEE, and so you can reuse more/all shaders from the cache in EEVEE, but not in EEVEE-Next. Which would make EEVEE shader “compile times” shorter than they should be compared to EEVEE-Next that would still have significant parts re-compiled.
If you want to do this test properly, you will need to clear your GPU shader cache for Blender, test one render engine (EEVEE), probably close Blender, clear the GPU shader cache, and test the next one (EEVEE-Next). And I have done my own testing with this technique:
Testing
I ran a shader compile time test (with shader cache clears between runs) on a semi-complex scene I have and here are the compile times:
EEVEE: 65 seconds
EEVEE-Next: 106 seconds
The performance ratio is a lot different from your results. So I investigated further:
In these render engines, there are two “types” of shaders important for the thing I’m going to talk about. General shaders and Material shaders.
- General shaders are shaders that are going to be there in every scene and is entirely controlled by the developers at Blender. The shaders do not change between scenes. These should only need to be compiled once per Blender version (ignoring various factors that may end up removing these shaders from the shader cache).
- Material shaders are the shaders that are generated from the materials that we make in the shader editor. These change between scenes, and you will need to compile most material shaders you make.
Let’s figure out which type of shader is taking longer to compile in EEVEE-Next. The easy way is to open a simple scene with render settings that match my complex scene, but share very few to no material shaders. Wait for the shaders to compile and that will give us the “time to compile General shaders”. Then open up the complex scene and wait for the shaders to compile. This will give us the “time to compile Material shaders”.
And the results:
- EEVEE General Shaders: 2 second
- EEVEE-Next General Shaders: 27 seconds
- EEVEE Material Shaders: 65 seconds
- EEVEE-Next Material Shaders: 67 seconds
Note: Test data is imprecise due to single test runs and using a human controlled stop watch to measure the time.
Well, that’s some useful results. Material shader compile times are pretty close (as would be expected). It’s those “General Shaders” that make the most difference. And as mentioned earlier, you should only need to compile those General Shaders once per Blender version (once again ignoring the different ways it can get removed from the shader cache). So although it takes a lot longer to compile these “General Shaders” in EEVEE-Next, it’s only a one time cost meaning it’s not a major issue outside of the first run of EEVEE-Next from a clean/invalid shader cache.
This also explains the performance number differences between our two tests. Because only some parts of EEVEE-Next’s shader compilation take longer than EEVEE. Which results in non-linear “compile time scaling” depending on the ratio of types of shaders used in a scene.
If I recall correctly, when compiling shaders for Unreal Engine, multiple threads are used for shader compilation. Assuming Blender and Unreal Engine were requesting the compilation of the exact same shaders, then with the shader compilation scheduling system used in Unreal Engine, you would process all the shaders roughly 6x as fast as Blender on your computer. (The 6x number is just an estimate. I assumed no hyper-threading and perfect multi-core scaling).
On the topic of what was mentioned above, based on my observations with Blender on a Windows machine with a NVIDIA GPU, shader compilation seems to be single threaded. This means compiling many shaders takes longer than it theoretically could take if Blender scheduled multiple shaders to be compiled concurrently (similar to Unreal Engine and some games with shader compilation stages).
8 Likes
Them the obvious question has to be: why Blender doesn’t use multi-threaded shader compilation?
That’s probably something for Vulkan right?
3 Likes
It’s no rarity to have compilation times over 90 seconds right now - with scenes of about 50 to 100 materials and a medium amount of textures. But even small scenes with only 10 to 20 shaders take too long to show up in viewport. That’s not great for a modern 3D software. I’ve reached the point where I sometimes go straight into Cycles render preview cause it’s a lot faster. I never really cared about Eevee, but Eevee Next can get rid of these compilation times, I do.
3 Likes
OpenGL doesn’t allow multi-threaded shader compilation. Many driver level it only allows a single application to compile a single shader at a time and applications are not able to influence this. In order to support multi-threaded shader compilation we need to migrate to Vulkan.
11 Likes
Would it be possible to not update the viewport until the shader is fully compiled? It is very hard to make value judgement between before and after certain kind of shader graph changes since the object would show the intermediary shader calculation which makes it very hard to see the actual difference between the before and the after states.
3 Likes
So regarding compilation time,
On my daily dev machine (Linux + AMD + Mesa) I get same order of compilation time as legacy EEVEE.
But it seems that nvidia drivers have a harder time with our new shaders for some reason (~3x from what I read).
First cold start of EEVEE-Next also takes quite longer than I would like to (a few seconds without any feedback), we could display a black frame with a waiting message instead, but ideally it should be less than 3 seconds.
So I think we have no choice but to optimize it at least a little for the first release. I have created a task for listing all the ideas about this ticket.
14 Likes
About AMD cards… one can buy a 24Gb card by half the price of a 4090. I walways had AMD cpus since 2000 but because there’s this legacy mith/fact that Blender sucks on Radeon graphics I keep buying NVIDIA just to be on the safe side. How does Eevee-next performs in a Radeon and how it compares to an nvidia card?
Anybody can give an inside info on this?
All hardware should benefit from the mentioned optimizations. We do not do any hardware specific specifications yet, except for Apple GPU.
3 Likes
Using the tug boat demo scene, with the quality turned up really high in EEVEE-Next, I get these frame rates:
RX 7800 XT on Windows: 9.8fps
RTX 4090 on Windows: 17.2fps
Looking at performance comparisons of rasterized video games, this sort of performance gap is expected between these two GPUs. Which implies that that there’s no performance favoritism between these two GPU vendors in EEVEE-Next in this scene.
2 Likes
Thanks @Alaska!
On another subject (back to shadows):
On today build and on a new complete scene the shadows seem to do nothing but flicker… I see no shadow at all actually 
…One of those cases that to improve we need to temporarily make it worse for sure.
1 Like
It’s currently re-compiling with long pauses, even when only changing the transfer mode on a color mix shader.
2 Likes
Today the shadow flicker has gone 
smooth as a Persian cat… but also all the hard shadows 
But wait… not only on Eevee-next, but Eevee-Legacy also seems to show worse shadows now than in Blender 4.1 official… can it be a new setting to blur the shadows.
Edit (day 3-04):
Today the Eevee-Legacy shadows are OK again and the Eevee-Next are as yesterday.
If they actually show up this refresh speed would be perfect!
Edit (day 4-04):
Not sure if it’s related but when using an insane amount of particles in the shot I’m getting shadows flickering issues on Eevee-Legacy when using 4.2. When the particles get triggered all the shadows flicker by the entire scene even when the particles don’t occlude them at all. This happens only on Legacy as on Next, at least until yesterday, they keep flickering all the time 
2 Likes
We need AMD/NVIDIA hw raytracing, this is THE most wanted feature that forces everyone to export to Unreal to render fast.
Screen RT is nice, but now everyone has a HW RT capable card in its 3rd (!) generation already.
We need this badly.
3 Likes
Note that HWraytracing doesn’t provide performance, it is a visual quality improvement.
HW raytracing is only supported on Vulkan/Metal. So first step is to migrate to Vulkan But HW raytracing still need a fallback for hardware that doesn’t have HWRT support.
8 Likes