The order was wrong from the semantic point of view, caused
by some legacy workarounds in Libmv. Didn't realize it's was
not how things were expected to be used.
Currently the tests don't run on windows for the following reasons
1) render_graph_finalize has an linking issue due missing a bunch of libraries (not sure why this is not an issue for linux)
2) This one is more interesting, in test/python/cmakelists.txt ${TEST_BLENDER_EXE_BARE} and ${TEST_BLENDER_EXE} are flat out wrong, but for some reason this doesn't matter for most tests, cause ctest will actually go out and look for the executable and fix the path for you *BUT* only for the command, if you use them in any of the parameters it'll happily pass on the wrong path.
3) on linux you can just run a .py file, windows is not as awesome and needs to be told to run it with pyton.
4) had to use the NAME/COMMAND long form of add_test otherwise $<TARGET_FILE:blender> doesn't get expanded, why? beats me.
5) missing idiff.exe for msvc2015/x64 in the libs folder.
This patch addresses 1-4 , but given I have no working Linux build environment, I'm unsure if it'll break anything there
5 has been fixed in rBL61751
Reviewers: juicyfruit, brecht, sergey
Reviewed By: sergey
Subscribers: Blendify
Tags: #cycles, #automated_testing
Differential Revision: https://developer.blender.org/D2367
This is also an important mathematical operation that can be folded
if it is known that one argument is a certain constant. For colors
the operation is provided as a Gamma node.
The SVM Gamma node needs a small fix to make it follow the 0 ^ 0 == 1
rule, same as the Power node, or the Gamma node itself in OSL mode.
Reviewers: #cycles
Differential Revision: https://developer.blender.org/D2263
The if branches were reordered when the original patch was
committed, which broke the implicit non-NULL guarantee on link.
To prevent re-occurrence, add a couple of unit tests.
Using unit tests is a wrong way to control static behavior of the
application. They should only be used for checking dynamic behavior,
all the rest is easily controllable at compile time.
Doing tests at ocmpile time are actually more robust approach since
we don't have strict policy of runnign unit tests before accepting
any change.
Proper alignment control is coming shortly.
This reverts commit 7c3a06c34918567e6b0ab67bded60725ff63073b.
As a result of other folding simplifications it may happen that
two type conversion nodes end up directly connected. In some
cases it may be possible to then remove both. A realistic case
might be an optimized out Mix RGB node used to blend vectors.
It seems it's safe to optimize when B is a float3 type
(color, vector), and A is float3 or float.
Reviewers: #cycles, sergey
Reviewed By: #cycles, sergey
Subscribers: sergey
Differential Revision: https://developer.blender.org/D2134
Code coverage of different combinations of secondary conditions
is obviously not complete because there are so many of them, but
all main rules should be there.
The reason for CORRECT vs INVALID is that both words have the same
number of characters so calls line up, but look quite different.
Reviewers: #cycles, sergey
Reviewed By: #cycles, sergey
Subscribers: dingto, sergey, brecht
Differential Revision: https://developer.blender.org/D2130
This commit adds some easy to use way to check whether the graph
was properly optimized. The idea is based on using mock glog sync
which keeps track on all messages and expects specific log message
to appear in the logging.
This means each optimization step should report that it optimized
something (specifying what exactly was optimized) and what was used
for optimization.
There's also some ease-ish way to define shader networks which we
might want to make a bit more global and available for all tests
in the future.
For now only RGBToBW node is covered as an example, really hope
to get help from active guys in the community to finish covering
all existing optimization cases. Ready to fix any possible issues
with builder when needed tho :)
When the Moon is full it was possible to have a dead-lock in task
scheduler's exit() method.
Similar problem was fixed in Blender's task scheduler 3 years ago
in bae2a2c.
This is an initial move to have unittests to at least cover
utility functions, which then could be extended further to
test such areas as shader optimization and such.
Currently only based on initial "infrastructure" layout and
writing tests needed to test the no-boost patch.
Note: This patch starts to use "<dir>/<header>.h" notation
for the include statements which i just got used to do in
other projects. Something what would be cool to use globally
in the code eventually.
Reviewers: dingto, juicyfruit, lukasstockner97, brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D1770
