We have reached the first milestone!!
Adapting the new codegen to the old EEVEE codebase was more work that I originaly anticipated.
A core design shift was to make the codegen render engine agnostic. Meaning there should be no special behavior depending on the render engine that runs it. At first glance it does not look like a major issue for Blender because EEVEE is the only engine to use the codegen. But this became important with the recent decision to keep EEVEE-next and the original EEVEE implementation side by side. Also this makes other engine implementation easier.
Moreover, this delegate the geometry support to the engine itself, making the support for other geometry types easier.
Technically, the new codegen now only produces functions strings that are then used by the render engine however it wants. The strings are now shader stage agnostic, meaning they can be used inside vertex shaders (i.e: true procedural displacement support for EEVEE-next).
Porting to the old codebase was also a test for that and allowed to polish the design, furthering the separation between the engine and the codegen.
I cleaned up some of the most tricky stuff we were doing to support displacement as bump mapping. The choice between fine bump or fast bump (2.80 blocky style) is now the responsibility of the engine and may become a performance option for EEVEE-next. This is also important for upscalling which I am aiming to support in EEVEE-next.
The Shader-to-RGB node is also now supported and engine agnostic. The engine can choose to implement it or not. The only change in behavior for the original EEVEE implementation is that now any shader using a Shader-to-RGB node will not have SSR or SSS on any of their BSDF node. This change mimics the behavior of what EEVEE-next is expected to be. I am still trying to find a way to keep the old behavior but it seems complicated.
When working on supporting the current SSS implementation, I stumbled accross what I can described as a bad choice from past self. Some of you might know that the SSS radius socket default values are used to pre-compute the SSS and that the socket input is only used as a scaling factor. Alas, the scaling factor makes no sense at all as a parameter. What should have been from the beginning is to use the input as a mean radius. This makes more senses and is more compatible with what you would expect from cycles. You would have to tweak the default values for the average SSS coloring and then the input would have just make it closer to what cycles outputs. I did not provide any version patching for now but this can be done easily.
Testing is highly encouraged. Any regressions not stated in the commit message should be reported to the bug tracker.
I will now focus on porting EEVEE-next first bits.