Blender 4.2 - EEVEE-Next Feedback

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:


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).


Them the obvious question has to be: why Blender doesn’t use multi-threaded shader compilation?
That’s probably something for Vulkan right?


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.


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.


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.


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.


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.


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.


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 :slightly_smiling_face: …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.


@fclem this looks like a huge blocker, can anything be done about this?

1 Like

Today the shadow flicker has gone :smiley: smooth as a Persian cat… but also all the hard shadows :grin:
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 :slight_smile:


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.


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 :slight_smile: But HW raytracing still need a fallback for hardware that doesn’t have HWRT support.


I don’t know much about this but what always seemed to me that makes Unreal/Unity faster is the fact that one can’t edit the objects (at run/render time (I know that someone will say it can edit them :smile:)) and the other is the LODs simplifications… am I close? :slight_smile:

1 Like

We need AMD/NVIDIA hw raytracing, this is THE most wanted feature that forces everyone to export to Unreal to render fast.

I imagine this comes more from engines like Unreal being GPU driven, and using things like meshlets (see GPU Driven Rendering Overview - Vulkan Guide, I imagine not all of this can be applied to Blender since it is not a game engine).

but now everyone has a HW RT capable card in its 3rd (!) generation already.

While this number of people grows, you’d be surprised how people with a 1050-era card or using iGPUs dominate polls if you were to run them :).


I have a non-RTX GPU, yet I use raytracing in UE5. On top of that, even with everything maxed out I get a much better performance than what I have in EEVEE-Next right now.

1 Like

Some NVIDIA GPUs without RT cores have a fall back in the driver to perform the tracing of rays via the general purpose GPU cores. (I believe it’s 6GB or higher VRAM GPUs from the GTX 10 series and newer)

But there are still a lot of devices that don’t have a fall back that people might be using (E.G. RX 5000 series GPUs from AMD)

Or early versions of drivers that don’t have hardware ray tracing support, or a software fall back (I believe the NVK driver on Linux doesn’t support the ray tracing APIs for Vulkan via hardware or software)