| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
separate some arrays.
Differential Revision: https://developer.blender.org/D2016
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
This reverts 72592cfb, needs more refactoring to do that cleanup.
|
|
Now I can start adding half float without adding even bigger mess to all these functions. ;)
|
|
|
|
Also make prefix consistent, so it starts with either TEX_NUM or TEX_START, followed by texture type and architecture.
|
|
|
|
|
|
Saves about 15% for the branched path kernel.
|
|
|
|
|
|
|
|
|
|
Volumes might be small, makes sense to use more precision here.
|
|
57% less for path and 48% less for branched path.
|
|
Some closures were missing from calculation, leading to an array
under-allocation, presumable causing memory corruption issues with
emission shaders on OpenCL and was causing issues with Volume 3D
textures with CUDA.
The issue was identified by Thomas Dinges, the patch is different
from the original D2006. See the brief discussion there. Current
approach is similar (or the same) as Brecht suggested.
|
|
In Cycle standalone, the xml import of uv's is done in a way that
a vertex could only have one unique uv coordinate. In practice it
is most of the time not the case.
Patch by Laurent Boiron, thanks!
|
|
This fixes a rare case where NaNs could exist inside Cycles.
When certain invalid meshes were passed in, Cycles would try too normalize
a zero length normal during its setup stage. While it does check against
division by zero, it still returns a zero length normal and passes it on to
the path tracing kernel. The kernel then operates under the assumption that
normals are valid, and in the case of such a zero length normal, would
eventually create NaNs that propagate through and result in black pixels.
Reviewers: #cycles
Subscribers: brecht, sergey
Projects: #cycles
Differential Revision: https://developer.blender.org/D2008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
At some point the idea was that we could have an optimization where we could
render multiple render layers without re-exporting the scene, by just updating
the layer bits. We are not doing this now and in practice with the available
render layer control like exclude layers it's not always possible anyway.
This makes it easier to support an arbitrary number of layers in the future
(hopefully this summer), and frees up some useful bits in the kernel.
Reviewed By: sergey, dingto
Differential Revision: https://developer.blender.org/D2020
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
Compile time per kernel increased alot after recent image commits, re-shuffle some code to fix this.
Patch by "LazyDodo".
Differential Revision: https://developer.blender.org/D2012
|
|
build.
|
|
Reviewers: dingto, sergey
Differential Revision: https://developer.blender.org/D2009
|
|
|
|
This adds support for CUDA Texture objects (also known as Bindless textures) for Kepler GPUs (Geforce 6xx and above).
This is used for all 2D/3D textures, data still uses arrays as before.
User benefits:
* No more limits of image textures on Kepler.
We had 5 float4 and 145 byte4 slots there before, now we have 1024 float4 and 1024 byte4.
This can be extended further if we need to (just change the define).
* Single channel textures slots (byte and float) are now supported on Kepler as well (1024 slots for each type).
ToDo / Issues:
* 3D textures don't work yet, at least don't show up during render. I have no idea whats wrong yet.
* Dynamically allocate bindless_mapping array?
I hope Fermi still works fine, but that should be tested on a Fermi card before pushing to master.
Part of my GSoC 2016.
Reviewers: sergey, #cycles, brecht
Subscribers: swerner, jtheninja, brecht, sergey
Differential Revision: https://developer.blender.org/D1999
|
|
|
|
Apparently the code path with malloc() was enabled for CUDA.
|
|
The idea of pole merge is to fade interocular distance after a certain
altitude to zero when altitude goes closer to a pole. This should prevent
annoyances looking up in the sky or down to the bottom.
Works for both panorama and perspective cameras when Spherical Stereo
is enabled.
Reviewers: dfelinto, brecht
Reviewed By: brecht
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D1998
|
|
This commit makes it so malloc() is only happening once per volume and
once per transparent shadow query (per thread), improving scalability of
the code to multiple CPU cores.
Hard to measure this with a low-bottom i7 here currently, but from quick
tests seems volume sampling gave about 3-5% speedup.
The idea is to store allocated memory in kernel globals, which are per
thread on CPU already.
Reviewers: dingto, juicyfruit, lukasstockner97, maiself, brecht
Reviewed By: brecht
Subscribers: Blendify, nutel
Differential Revision: https://developer.blender.org/D1996
|
|
|
|
|
|
|
|
|
|
|
|
|
