Although the problem was exposed in 9457715d9a, the problem was in the
original code that was copied over. To have:
```
} else { /* EXPECTED_VALUE */
```
Without an BLI_assert(value == EXPECTED_VALUE); is asking for troubles.
Yet another reason to favour switch statements with:
```
default:
BLI_assert(!"value not implemented or supported");
```
Instead of chained if/else if/else /* expected_value */.
Move floats around when needed to accomodate vec3 arrays efficiently.
With this we use slightly less memory when possible. Basically vec3s are not
treated as vec4 unless we have no float to use for padding).
Reviewers: fclem, sergey
Differential Revision: https://developer.blender.org/D2800
This fixes the Principled shader in Eevee, among other nodes.
Basically before we were treating all the vec3 as vec4 as far as memory
goes. We now only do it when required (aka, when the vec3 is not
followed by a float).
We can be even smarter about that and move the floats around to provide
padding for the vec3s. However this is for a separate patch.
That said, there seems to be some strong consensus in corners of the
internet against using vec3 at all [1]. Basically even if we get all the
padding correct, we may still suffer from poor driver implementations in
some consumer graphic cards.
It's not hard to move to vec4, but I think we can avoid doing it as much
as possible. By the time 2.8 is out hopefully most drivers will be
implementing things correctly.
[1] - https://stackoverflow.com/questions/38172696
Use mesh batch cache for mesh selection.
Note that we could create the batches and free immediately
so they don't take up memory.
This resolves a problem where selection was limited
to immediate-mode buffer size.
We do have an history of those pieces of evil in our code, would be nice
to get fully rid of it, but at the very least let's not add more of them
in new code. :)
This should fixes the error message that a stall occured because of busy mipmap.
This happened on the minmax buffer generation and introduced a random 0.2ms latency.
I'm not sure of what was happening though.
For users that means you can tweak shaders in the nodetree and things
are way faster. This is a huge improvement, particularly in
systems that have no shader cache.
From the code perspective it means we are no longer re-compiling the
shader every time a value is tweaked in the UI. We are using uniforms
for those values.
It would be slow to add that many uniforms for all the shaders. So
instead we are using UBO (Uniform Buffer Objects).
This fixes the main issue of T51467. However GWN_shaderinterface_create() still
needs to be improvedi. When opening a .blend all shaders are compiled once, so
optimizing it will bring a measurable impact.
========================================================================
NOTE: This breaks update of Cycles material upon nodetree nodes
tweaking. It will be fixed separately by depsgraph, once tackling T51925
(Animated Eevee values slowdown).
The idea is to make Depsgraph update more granular. The XXX TODO in
rna_nodetree.c will be tackled at that time as well.
========================================================================
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D2739
Goal is to make them more modular, to allow more variants (variable
single-color, thickness, ...) to be added without having to
copy-and-change-one-line of whole chain of shaders.
This allow specialized shaders to redefine the closure interface to fit their needs.
For instance, Volumetric closure needs to pass more than one vec4 (absorption vec3, scattering vec3, anisotropy float).
This special case function enables rendering to a miplevel while using the miplevels above as texture input.
This is needed for some algorithm (i.e. creating a min-max depth pyramid texture).
