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.
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:
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 
âŚOne of those cases that to improve we need to temporarily make it worse for sure.
Itâs currently re-compiling with long pauses, even when only changing the transfer mode on a color mix shader.
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 
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 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 
)) and the other is the LODs simplifications⌠am I close?
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.
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)