This is mainly to address old issue when one need to have SDL library installed
in order to use our official builds. Some hip distros already installs SDL,
but it's not quite the same across all the variety of the distros.
We also now switching to SDL-2.0, most of the distros have it in repositories
already, so it shouldn't be huge deal to install it if needed.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D878
in practice often we want to breakpoint here (instead of flooding output)
but its confusing the option does nothing in release builds.
Devs can comment out locally.
Two fixes here (only the second one is strictly needed to fix the issue,
but both make the system better).
First is introduction of a random generator array for use with threaded
systems where each thread needs to access its own number generator.
The random texture now uses this so it should not be influenced by other
random generator reseedings of the main random generator like it did
before.
Second, I reshuffled the texture code to resample the upper bits of the
random number first. According to Numerical Recipes, this is where the
most variance can be found, so by sampling those we avoid correlation
issues. Also, multiplying here is not ideal because if a pair of bits
are zero, then the whole result will also be zero.
Overall this is much more random (tm) than before, however result will
also be brighter, since we now have less black spots. Tweaking the
brightness/contrast should somewhat fix that, generally having the same
result as before is not possible anyway if we are to really fix this.
Also, seems like exposing procedural depth might be nice here since it
influences the precision of the texture lookup.
Issue was caused by the launcher not dealing with slashes in the way
windows expects them to be handled -- last slash of the path considered
an escape character for the following qoute.
This is definitely to be ported to the 2.72 release.
This commit makes it possible to use Glog library for the debug logging.
For now only possible when using CMake and in order to use the logging
the WITH_CYCLES_LOGGING configuration variable is to be enabled.
When this option is not enabled or when using Scons there's no difference
in Cycles behavior at all, when using logging and no output to the console
impact is gonna to be minimal.
This is done in order to make it possible to have debug logging persistent
in code (without need to add it when troubleshooting some bug and removing
it afterwards).
For now actual logging is not placed yet, only all the functions needed for
the logging are written and so.
- Forgot to handle command line arguments
- Because of the fact we need to be able to
use stdout and stderr we need to use regular
console application for the wrapper.
- Because of using regular application for the
wrapper we need to check forparent PID in the
isStartedFromCommandPrompt().
I really hope it's not gonna to become any more
complicated.
Main idea of this change is to make a small executable which
will set OMP_WAIT_POLICY environment variable and then will
launch blender itself.
This is a teporary solution for the time being we'll have a
more clear solution to high CPU usage with OpenMP when building
with MSVC.
Reviewers: campbellbarton, juicyfruit
Reviewed By: juicyfruit
Differential Revision: https://developer.blender.org/D717
Couple of issues:
- Debian systems doesn't use site-packages but uses
dist-packages instead.
- Requetss from ubuntu repository depends on urlllib3
and chardet, which also implies six. copy those libs
as well.
I know it's all rather annoying, but no that much
choise is in here..
This solves missing requests package reported on the systems where it's
located in dist-packages rather than in site-packages.
To do this there's now a helper macros which handles both requests and
numpy now and could be used for more packages in the future.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D686
This is needed because render threads would do some allocations like
part buffer allocation and so. This is likely harmless with the lock
free allocator (not on Windows tho), but when using guarded allocator
we need to be sure access to the list of MemHead is safe.
Current temporary data of Blender suffers one major issue - default 'temp' dir on Windows is never
automatically cleaned up, and can end being quite big when used by Blender, especially when we have
to store per-process data (using getpid() in file names).
To address this, this patch:
* Divides tempdir paths in two, one for 'base' temp dir (the same as previous unique tempdir path),
the other is a mkdtemp-generated sub-dir, specific to each Blender instance.
* Only uses base tempdir when we need some shallow persistance accross Blender sessions - and we always
reuse the same filename (quit.blend...) or generate small file (crash reports...).
* Uses temp sub-dir for heavy files like pointcache or renderEXRs (Save Buffer option).
* Erases temp sub-dir on quit or crash.
To get this working it also adds a working 'recursive delete' to BLI_delete() under Windows.
Note that, as in current code, the 'recover render result' hack-feature that was possible
with SaveBuffer option is still removed. A real renderresult cache feature will be added
soon, though.
Reviewers: campbellbarton, brecht, sergey
Reviewed By: campbellbarton, sergey
CC: sergey
Differential Revision: https://developer.blender.org/D531
Needed to make the blender link libraries a global property
now that tests are parallel to source directory.
Current sort order for blender link libraries doesn't work
for tests that start with few defined symbols. Doubling the
lib list works, but a TODO to find a better way (probably
using CMake's own mechanism for tracking dependencies).
There is not much sense to have a whole BLI file just to check SSE2 on CPUs...
So idea is to rename it to more generic "BLI_system", and add to it more system-related
utils, like e.g. an include helper for getpid(), which allows to hide unix/windows
internals from rest of the code...
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D439
