Commit Graph

7 Commits

Author SHA1 Message Date
c18712e868 Cycles: change __device and similar qualifiers to ccl_device in kernel code.
This to avoids build conflicts with libc++ on FreeBSD, these __ prefixed values
are reserved for compilers. I apologize to anyone who has patches or branches
and has to go through the pain of merging this change, it may be easiest to do
these same replacements in your code and then apply/merge the patch.

Ref T37477.
2013-11-18 08:48:15 +01:00
Brecht Van Lommel
e25ad0778f Fix #36545: crash with branched path tracing, correlated multi-jittered
sampling and subsurface scattering.
2013-08-23 23:04:50 +00:00
Brecht Van Lommel
b9ce231060 Cycles: relicense GNU GPL source code to Apache version 2.0.
More information in this post:
http://code.blender.org/

Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
Brecht Van Lommel
16204bd647 Cycles: prepare to make CUDA 5.0 the official version we use
* Add CUDA compiler version detection to cmake/scons/runtime
* Remove noinline in kernel_shader.h and reenable --use_fast_math if CUDA 5.x
  is used, these were workarounds for CUDA 4.2 bugs
* Change max number of registers to 32 for sm 2.x (based on performance tests
  from Martijn Berger and confirmed here), and also for NVidia OpenCL.

Overall it seems that with these changes and the latest CUDA 5.0 download, that
performance is as good as or better than the 2.67b release with the scenes and
graphics cards I tested.
2013-06-19 17:54:23 +00:00
Brecht Van Lommel
484d765bd4 Cycles: attempt to fix internal compile error with some visual studio builds 2013-06-18 13:19:16 +00:00
Brecht Van Lommel
37f92119e4 Fix #35665: more CUDA issues with recent kernel changes, tested on sm_20, sm_21
and sm_30 cards, so hopefully it should all work now.

Also includes some warnings fixes related to nvcc compiler arguments, should make
no difference otherwise.
2013-06-11 21:58:48 +00:00
Brecht Van Lommel
b20a7e01d0 Cycles: experimental correlated multi-jittered sampling pattern that can be used
instead of sobol. So far one doesn't seem to be consistently better or worse than
the other for the same number of samples but more testing is needed.

The random number generator itself is slower than sobol for most number of samples,
except 16, 64, 256, .. because they can be computed faster. This can probably be
optimized, but we can do that when/if this actually turns out to be useful.

Paper this implementation is based on:
http://graphics.pixar.com/library/MultiJitteredSampling/

Also includes some refactoring of RNG code, fixing a Sobol correlation issue with
the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a
simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00