2011-04-27 11:58:34 +00:00
|
|
|
/*
|
2013-08-18 14:16:15 +00:00
|
|
|
* Copyright 2011-2013 Blender Foundation
|
2011-04-27 11:58:34 +00:00
|
|
|
*
|
2013-08-18 14:16:15 +00:00
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
2011-04-27 11:58:34 +00:00
|
|
|
*
|
2013-08-18 14:16:15 +00:00
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
2011-04-27 11:58:34 +00:00
|
|
|
*
|
2013-08-18 14:16:15 +00:00
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
2014-12-25 01:50:24 +00:00
|
|
|
* limitations under the License.
|
2011-04-27 11:58:34 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __KERNEL_COMPAT_CPU_H__
|
|
|
|
#define __KERNEL_COMPAT_CPU_H__
|
|
|
|
|
|
|
|
#define __KERNEL_CPU__
|
|
|
|
|
2015-02-12 12:51:02 +00:00
|
|
|
/* Release kernel has too much false-positive maybe-uninitialized warnings,
|
2015-02-02 16:13:41 +00:00
|
|
|
* which makes it possible to miss actual warnings.
|
|
|
|
*/
|
2015-10-25 19:48:28 +00:00
|
|
|
#if (defined(__GNUC__) && !defined(__clang__)) && defined(NDEBUG)
|
2015-02-02 16:13:41 +00:00
|
|
|
# pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
|
2015-06-13 14:17:55 +00:00
|
|
|
# pragma GCC diagnostic ignored "-Wuninitialized"
|
2015-02-02 16:13:41 +00:00
|
|
|
#endif
|
|
|
|
|
2015-05-09 14:22:16 +00:00
|
|
|
/* Selective nodes compilation. */
|
|
|
|
#ifndef __NODES_MAX_GROUP__
|
|
|
|
# define __NODES_MAX_GROUP__ NODE_GROUP_LEVEL_MAX
|
|
|
|
#endif
|
|
|
|
#ifndef __NODES_FEATURES__
|
|
|
|
# define __NODES_FEATURES__ NODE_FEATURE_ALL
|
|
|
|
#endif
|
|
|
|
|
Cycles: Make all #include statements relative to cycles source directory
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
2017-03-28 18:39:14 +00:00
|
|
|
#include "util/util_debug.h"
|
|
|
|
#include "util/util_math.h"
|
|
|
|
#include "util/util_simd.h"
|
|
|
|
#include "util/util_half.h"
|
|
|
|
#include "util/util_types.h"
|
|
|
|
#include "util/util_texture.h"
|
2011-04-27 11:58:34 +00:00
|
|
|
|
Cycles: OpenCL kernel split
This commit contains all the work related on the AMD megakernel split work
which was mainly done by Varun Sundar, George Kyriazis and Lenny Wang, plus
some help from Sergey Sharybin, Martijn Berger, Thomas Dinges and likely
someone else which we're forgetting to mention.
Currently only AMD cards are enabled for the new split kernel, but it is
possible to force split opencl kernel to be used by setting the following
environment variable: CYCLES_OPENCL_SPLIT_KERNEL_TEST=1.
Not all the features are supported yet, and that being said no motion blur,
camera blur, SSS and volumetrics for now. Also transparent shadows are
disabled on AMD device because of some compiler bug.
This kernel is also only implements regular path tracing and supporting
branched one will take a bit. Branched path tracing is exposed to the
interface still, which is a bit misleading and will be hidden there soon.
More feature will be enabled once they're ported to the split kernel and
tested.
Neither regular CPU nor CUDA has any difference, they're generating the
same exact code, which means no regressions/improvements there.
Based on the research paper:
https://research.nvidia.com/sites/default/files/publications/laine2013hpg_paper.pdf
Here's the documentation:
https://docs.google.com/document/d/1LuXW-CV-sVJkQaEGZlMJ86jZ8FmoPfecaMdR-oiWbUY/edit
Design discussion of the patch:
https://developer.blender.org/T44197
Differential Revision: https://developer.blender.org/D1200
2015-05-09 14:34:30 +00:00
|
|
|
#define ccl_addr_space
|
|
|
|
|
2017-02-14 11:20:48 +00:00
|
|
|
#define ccl_local_id(d) 0
|
|
|
|
#define ccl_global_id(d) (kg->global_id[d])
|
|
|
|
|
|
|
|
#define ccl_local_size(d) 1
|
|
|
|
#define ccl_global_size(d) (kg->global_size[d])
|
|
|
|
|
|
|
|
#define ccl_group_id(d) ccl_global_id(d)
|
|
|
|
#define ccl_num_groups(d) ccl_global_size(d)
|
|
|
|
|
2014-11-07 08:35:45 +00:00
|
|
|
/* On x86_64, versions of glibc < 2.16 have an issue where expf is
|
|
|
|
* much slower than the double version. This was fixed in glibc 2.16.
|
2014-10-06 07:43:23 +00:00
|
|
|
*/
|
2014-11-07 08:35:45 +00:00
|
|
|
#if !defined(__KERNEL_GPU__) && defined(__x86_64__) && defined(__x86_64__) && \
|
|
|
|
defined(__GNU_LIBRARY__) && defined(__GLIBC__ ) && defined(__GLIBC_MINOR__) && \
|
|
|
|
(__GLIBC__ <= 2 && __GLIBC_MINOR__ < 16)
|
2014-10-07 22:02:46 +00:00
|
|
|
# define expf(x) ((float)exp((double)(x)))
|
2014-10-06 07:43:23 +00:00
|
|
|
#endif
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
CCL_NAMESPACE_BEGIN
|
|
|
|
|
|
|
|
/* Assertions inside the kernel only work for the CPU device, so we wrap it in
|
2012-06-09 17:22:52 +00:00
|
|
|
* a macro which is empty for other devices */
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
#define kernel_assert(cond) assert(cond)
|
|
|
|
|
|
|
|
/* Texture types to be compatible with CUDA textures. These are really just
|
2012-06-09 17:22:52 +00:00
|
|
|
* simple arrays and after inlining fetch hopefully revert to being a simple
|
|
|
|
* pointer lookup. */
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
template<typename T> struct texture {
|
2014-02-04 15:04:07 +00:00
|
|
|
ccl_always_inline T fetch(int index)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
|
|
|
kernel_assert(index >= 0 && index < width);
|
|
|
|
return data[index];
|
|
|
|
}
|
|
|
|
|
2016-10-12 11:03:15 +00:00
|
|
|
#ifdef __KERNEL_AVX__
|
|
|
|
/* Reads 256 bytes but indexes in blocks of 128 bytes to maintain
|
|
|
|
* compatibility with existing indicies and data structures.
|
|
|
|
*/
|
|
|
|
ccl_always_inline avxf fetch_avxf(const int index)
|
|
|
|
{
|
|
|
|
kernel_assert(index >= 0 && (index+1) < width);
|
2017-03-23 11:41:33 +00:00
|
|
|
ssef *ssef_data = (ssef*)data;
|
|
|
|
ssef *ssef_node_data = &ssef_data[index];
|
|
|
|
return _mm256_loadu_ps((float *)ssef_node_data);
|
2016-10-12 11:03:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2014-12-25 09:11:37 +00:00
|
|
|
#ifdef __KERNEL_SSE2__
|
2014-06-13 19:13:18 +00:00
|
|
|
ccl_always_inline ssef fetch_ssef(int index)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
|
|
|
kernel_assert(index >= 0 && index < width);
|
2014-06-13 19:13:18 +00:00
|
|
|
return ((ssef*)data)[index];
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
|
|
|
|
2014-06-13 19:13:18 +00:00
|
|
|
ccl_always_inline ssei fetch_ssei(int index)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
|
|
|
kernel_assert(index >= 0 && index < width);
|
2014-06-13 19:13:18 +00:00
|
|
|
return ((ssei*)data)[index];
|
2012-06-09 17:22:52 +00:00
|
|
|
}
|
2014-12-25 09:11:37 +00:00
|
|
|
#endif
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
T *data;
|
|
|
|
int width;
|
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T> struct texture_image {
|
2015-02-01 20:40:01 +00:00
|
|
|
#define SET_CUBIC_SPLINE_WEIGHTS(u, t) \
|
2015-02-01 21:04:47 +00:00
|
|
|
{ \
|
|
|
|
u[0] = (((-1.0f/6.0f)* t + 0.5f) * t - 0.5f) * t + (1.0f/6.0f); \
|
|
|
|
u[1] = (( 0.5f * t - 1.0f) * t ) * t + (2.0f/3.0f); \
|
|
|
|
u[2] = (( -0.5f * t + 0.5f) * t + 0.5f) * t + (1.0f/6.0f); \
|
|
|
|
u[3] = (1.0f / 6.0f) * t * t * t; \
|
|
|
|
} (void)0
|
2015-02-01 20:40:01 +00:00
|
|
|
|
2014-02-04 15:04:07 +00:00
|
|
|
ccl_always_inline float4 read(float4 r)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2014-02-04 15:04:07 +00:00
|
|
|
ccl_always_inline float4 read(uchar4 r)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
|
|
|
float f = 1.0f/255.0f;
|
|
|
|
return make_float4(r.x*f, r.y*f, r.z*f, r.w*f);
|
|
|
|
}
|
|
|
|
|
2016-05-12 12:51:42 +00:00
|
|
|
ccl_always_inline float4 read(uchar r)
|
|
|
|
{
|
|
|
|
float f = r*(1.0f/255.0f);
|
2016-09-03 21:06:12 +00:00
|
|
|
return make_float4(f, f, f, 1.0f);
|
2016-05-12 12:51:42 +00:00
|
|
|
}
|
|
|
|
|
2016-05-09 10:51:42 +00:00
|
|
|
ccl_always_inline float4 read(float r)
|
|
|
|
{
|
|
|
|
/* TODO(dingto): Optimize this, so interpolation
|
|
|
|
* happens on float instead of float4 */
|
|
|
|
return make_float4(r, r, r, 1.0f);
|
|
|
|
}
|
|
|
|
|
2016-06-19 15:31:16 +00:00
|
|
|
ccl_always_inline float4 read(half4 r)
|
|
|
|
{
|
|
|
|
return half4_to_float4(r);
|
|
|
|
}
|
|
|
|
|
|
|
|
ccl_always_inline float4 read(half r)
|
|
|
|
{
|
|
|
|
float f = half_to_float(r);
|
|
|
|
return make_float4(f, f, f, 1.0f);
|
|
|
|
}
|
|
|
|
|
2014-02-04 15:04:07 +00:00
|
|
|
ccl_always_inline int wrap_periodic(int x, int width)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
|
|
|
x %= width;
|
|
|
|
if(x < 0)
|
|
|
|
x += width;
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
2014-02-04 15:04:07 +00:00
|
|
|
ccl_always_inline int wrap_clamp(int x, int width)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
|
|
|
return clamp(x, 0, width-1);
|
|
|
|
}
|
|
|
|
|
2014-02-04 15:04:07 +00:00
|
|
|
ccl_always_inline float frac(float x, int *ix)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
2013-06-07 16:06:17 +00:00
|
|
|
int i = float_to_int(x) - ((x < 0.0f)? 1: 0);
|
2011-04-27 11:58:34 +00:00
|
|
|
*ix = i;
|
|
|
|
return x - (float)i;
|
|
|
|
}
|
|
|
|
|
2015-07-21 19:58:19 +00:00
|
|
|
ccl_always_inline float4 interp(float x, float y)
|
2011-04-27 11:58:34 +00:00
|
|
|
{
|
2014-05-04 20:57:33 +00:00
|
|
|
if(UNLIKELY(!data))
|
2011-04-27 11:58:34 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
|
|
|
|
|
|
|
int ix, iy, nix, niy;
|
2014-03-29 12:03:48 +00:00
|
|
|
|
2014-03-07 22:16:09 +00:00
|
|
|
if(interpolation == INTERPOLATION_CLOSEST) {
|
2014-05-06 04:07:04 +00:00
|
|
|
frac(x*(float)width, &ix);
|
|
|
|
frac(y*(float)height, &iy);
|
2015-07-28 12:36:08 +00:00
|
|
|
switch(extension) {
|
|
|
|
case EXTENSION_REPEAT:
|
|
|
|
ix = wrap_periodic(ix, width);
|
|
|
|
iy = wrap_periodic(iy, height);
|
|
|
|
break;
|
|
|
|
case EXTENSION_CLIP:
|
2015-10-08 14:08:28 +00:00
|
|
|
if(x < 0.0f || y < 0.0f || x > 1.0f || y > 1.0f) {
|
2015-07-28 12:36:08 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
|
|
|
}
|
2017-05-24 15:23:54 +00:00
|
|
|
ATTR_FALLTHROUGH;
|
2015-07-28 12:36:08 +00:00
|
|
|
case EXTENSION_EXTEND:
|
|
|
|
ix = wrap_clamp(ix, width);
|
|
|
|
iy = wrap_clamp(iy, height);
|
|
|
|
break;
|
2016-02-10 14:09:45 +00:00
|
|
|
default:
|
|
|
|
kernel_assert(0);
|
2016-04-16 22:51:29 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
2014-03-13 19:08:10 +00:00
|
|
|
}
|
2014-03-07 22:16:09 +00:00
|
|
|
return read(data[ix + iy*width]);
|
|
|
|
}
|
2015-02-01 20:40:01 +00:00
|
|
|
else if(interpolation == INTERPOLATION_LINEAR) {
|
2014-05-06 04:07:04 +00:00
|
|
|
float tx = frac(x*(float)width - 0.5f, &ix);
|
|
|
|
float ty = frac(y*(float)height - 0.5f, &iy);
|
2014-03-13 19:08:10 +00:00
|
|
|
|
2015-07-28 12:36:08 +00:00
|
|
|
switch(extension) {
|
|
|
|
case EXTENSION_REPEAT:
|
|
|
|
ix = wrap_periodic(ix, width);
|
|
|
|
iy = wrap_periodic(iy, height);
|
|
|
|
|
|
|
|
nix = wrap_periodic(ix+1, width);
|
|
|
|
niy = wrap_periodic(iy+1, height);
|
|
|
|
break;
|
|
|
|
case EXTENSION_CLIP:
|
2015-10-08 14:08:28 +00:00
|
|
|
if(x < 0.0f || y < 0.0f || x > 1.0f || y > 1.0f) {
|
2015-07-28 12:36:08 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
|
|
|
}
|
2017-05-24 15:23:54 +00:00
|
|
|
ATTR_FALLTHROUGH;
|
2015-07-28 12:36:08 +00:00
|
|
|
case EXTENSION_EXTEND:
|
2015-09-03 12:14:35 +00:00
|
|
|
nix = wrap_clamp(ix+1, width);
|
|
|
|
niy = wrap_clamp(iy+1, height);
|
|
|
|
|
2015-07-28 12:36:08 +00:00
|
|
|
ix = wrap_clamp(ix, width);
|
|
|
|
iy = wrap_clamp(iy, height);
|
|
|
|
break;
|
2016-02-10 14:09:45 +00:00
|
|
|
default:
|
|
|
|
kernel_assert(0);
|
2016-04-16 22:51:29 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
2014-03-13 19:08:10 +00:00
|
|
|
}
|
2014-03-29 12:03:48 +00:00
|
|
|
|
2014-03-07 22:16:09 +00:00
|
|
|
float4 r = (1.0f - ty)*(1.0f - tx)*read(data[ix + iy*width]);
|
|
|
|
r += (1.0f - ty)*tx*read(data[nix + iy*width]);
|
|
|
|
r += ty*(1.0f - tx)*read(data[ix + niy*width]);
|
|
|
|
r += ty*tx*read(data[nix + niy*width]);
|
2014-03-29 12:03:48 +00:00
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
2015-02-01 20:40:01 +00:00
|
|
|
else {
|
2015-07-28 12:36:08 +00:00
|
|
|
/* Bicubic b-spline interpolation. */
|
2015-09-03 12:14:35 +00:00
|
|
|
float tx = frac(x*(float)width - 0.5f, &ix);
|
|
|
|
float ty = frac(y*(float)height - 0.5f, &iy);
|
2015-02-01 20:40:01 +00:00
|
|
|
int pix, piy, nnix, nniy;
|
2015-07-28 12:36:08 +00:00
|
|
|
switch(extension) {
|
|
|
|
case EXTENSION_REPEAT:
|
|
|
|
ix = wrap_periodic(ix, width);
|
|
|
|
iy = wrap_periodic(iy, height);
|
|
|
|
|
|
|
|
pix = wrap_periodic(ix-1, width);
|
|
|
|
piy = wrap_periodic(iy-1, height);
|
|
|
|
|
|
|
|
nix = wrap_periodic(ix+1, width);
|
|
|
|
niy = wrap_periodic(iy+1, height);
|
|
|
|
|
|
|
|
nnix = wrap_periodic(ix+2, width);
|
|
|
|
nniy = wrap_periodic(iy+2, height);
|
|
|
|
break;
|
|
|
|
case EXTENSION_CLIP:
|
2015-10-08 14:08:28 +00:00
|
|
|
if(x < 0.0f || y < 0.0f || x > 1.0f || y > 1.0f) {
|
2015-07-28 12:36:08 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
|
|
|
}
|
2017-05-24 15:23:54 +00:00
|
|
|
ATTR_FALLTHROUGH;
|
2015-07-28 12:36:08 +00:00
|
|
|
case EXTENSION_EXTEND:
|
2015-09-03 12:14:35 +00:00
|
|
|
pix = wrap_clamp(ix-1, width);
|
|
|
|
piy = wrap_clamp(iy-1, height);
|
2015-07-28 12:36:08 +00:00
|
|
|
|
2015-09-03 12:14:35 +00:00
|
|
|
nix = wrap_clamp(ix+1, width);
|
|
|
|
niy = wrap_clamp(iy+1, height);
|
2015-07-28 12:36:08 +00:00
|
|
|
|
2015-09-03 12:14:35 +00:00
|
|
|
nnix = wrap_clamp(ix+2, width);
|
|
|
|
nniy = wrap_clamp(iy+2, height);
|
2015-07-28 12:36:08 +00:00
|
|
|
|
2015-09-03 12:14:35 +00:00
|
|
|
ix = wrap_clamp(ix, width);
|
|
|
|
iy = wrap_clamp(iy, height);
|
2015-07-28 12:36:08 +00:00
|
|
|
break;
|
2016-02-10 14:09:45 +00:00
|
|
|
default:
|
|
|
|
kernel_assert(0);
|
2016-04-16 22:51:29 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
2015-02-01 20:40:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const int xc[4] = {pix, ix, nix, nnix};
|
|
|
|
const int yc[4] = {width * piy,
|
|
|
|
width * iy,
|
|
|
|
width * niy,
|
|
|
|
width * nniy};
|
2015-02-02 12:34:34 +00:00
|
|
|
float u[4], v[4];
|
2015-02-01 20:40:01 +00:00
|
|
|
/* Some helper macro to keep code reasonable size,
|
|
|
|
* let compiler to inline all the matrix multiplications.
|
|
|
|
*/
|
|
|
|
#define DATA(x, y) (read(data[xc[x] + yc[y]]))
|
|
|
|
#define TERM(col) \
|
|
|
|
(v[col] * (u[0] * DATA(0, col) + \
|
|
|
|
u[1] * DATA(1, col) + \
|
|
|
|
u[2] * DATA(2, col) + \
|
|
|
|
u[3] * DATA(3, col)))
|
|
|
|
|
|
|
|
SET_CUBIC_SPLINE_WEIGHTS(u, tx);
|
|
|
|
SET_CUBIC_SPLINE_WEIGHTS(v, ty);
|
|
|
|
|
|
|
|
/* Actual interpolation. */
|
|
|
|
return TERM(0) + TERM(1) + TERM(2) + TERM(3);
|
|
|
|
|
|
|
|
#undef TERM
|
|
|
|
#undef DATA
|
|
|
|
}
|
2014-03-29 12:03:48 +00:00
|
|
|
}
|
|
|
|
|
2015-07-21 19:58:19 +00:00
|
|
|
ccl_always_inline float4 interp_3d(float x, float y, float z)
|
2014-10-22 13:23:45 +00:00
|
|
|
{
|
2015-07-21 19:58:19 +00:00
|
|
|
return interp_3d_ex(x, y, z, interpolation);
|
2014-10-22 13:23:45 +00:00
|
|
|
}
|
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
ccl_always_inline float4 interp_3d_ex_closest(float x, float y, float z)
|
2014-03-29 12:03:48 +00:00
|
|
|
{
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
int ix, iy, iz;
|
|
|
|
frac(x*(float)width, &ix);
|
|
|
|
frac(y*(float)height, &iy);
|
|
|
|
frac(z*(float)depth, &iz);
|
|
|
|
|
|
|
|
switch(extension) {
|
|
|
|
case EXTENSION_REPEAT:
|
|
|
|
ix = wrap_periodic(ix, width);
|
|
|
|
iy = wrap_periodic(iy, height);
|
|
|
|
iz = wrap_periodic(iz, depth);
|
|
|
|
break;
|
|
|
|
case EXTENSION_CLIP:
|
|
|
|
if(x < 0.0f || y < 0.0f || z < 0.0f ||
|
|
|
|
x > 1.0f || y > 1.0f || z > 1.0f)
|
|
|
|
{
|
2016-04-16 22:51:29 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
}
|
2017-05-24 15:23:54 +00:00
|
|
|
ATTR_FALLTHROUGH;
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
case EXTENSION_EXTEND:
|
|
|
|
ix = wrap_clamp(ix, width);
|
|
|
|
iy = wrap_clamp(iy, height);
|
|
|
|
iz = wrap_clamp(iz, depth);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
kernel_assert(0);
|
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
2014-03-29 12:03:48 +00:00
|
|
|
}
|
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
return read(data[ix + iy*width + iz*width*height]);
|
|
|
|
}
|
2015-09-03 12:14:35 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
ccl_always_inline float4 interp_3d_ex_linear(float x, float y, float z)
|
|
|
|
{
|
|
|
|
int ix, iy, iz;
|
|
|
|
int nix, niy, niz;
|
2017-04-10 08:59:31 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
float tx = frac(x*(float)width - 0.5f, &ix);
|
|
|
|
float ty = frac(y*(float)height - 0.5f, &iy);
|
|
|
|
float tz = frac(z*(float)depth - 0.5f, &iz);
|
|
|
|
|
|
|
|
switch(extension) {
|
|
|
|
case EXTENSION_REPEAT:
|
|
|
|
ix = wrap_periodic(ix, width);
|
|
|
|
iy = wrap_periodic(iy, height);
|
|
|
|
iz = wrap_periodic(iz, depth);
|
|
|
|
|
|
|
|
nix = wrap_periodic(ix+1, width);
|
|
|
|
niy = wrap_periodic(iy+1, height);
|
|
|
|
niz = wrap_periodic(iz+1, depth);
|
|
|
|
break;
|
|
|
|
case EXTENSION_CLIP:
|
|
|
|
if(x < 0.0f || y < 0.0f || z < 0.0f ||
|
|
|
|
x > 1.0f || y > 1.0f || z > 1.0f)
|
|
|
|
{
|
2016-04-16 22:51:29 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
}
|
2017-05-24 15:23:54 +00:00
|
|
|
ATTR_FALLTHROUGH;
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
case EXTENSION_EXTEND:
|
|
|
|
nix = wrap_clamp(ix+1, width);
|
|
|
|
niy = wrap_clamp(iy+1, height);
|
|
|
|
niz = wrap_clamp(iz+1, depth);
|
|
|
|
|
|
|
|
ix = wrap_clamp(ix, width);
|
|
|
|
iy = wrap_clamp(iy, height);
|
|
|
|
iz = wrap_clamp(iz, depth);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
kernel_assert(0);
|
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
2014-03-07 22:16:09 +00:00
|
|
|
}
|
2015-07-28 12:36:08 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
float4 r;
|
2015-07-28 12:36:08 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
r = (1.0f - tz)*(1.0f - ty)*(1.0f - tx)*read(data[ix + iy*width + iz*width*height]);
|
|
|
|
r += (1.0f - tz)*(1.0f - ty)*tx*read(data[nix + iy*width + iz*width*height]);
|
|
|
|
r += (1.0f - tz)*ty*(1.0f - tx)*read(data[ix + niy*width + iz*width*height]);
|
|
|
|
r += (1.0f - tz)*ty*tx*read(data[nix + niy*width + iz*width*height]);
|
2015-07-28 12:36:08 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
r += tz*(1.0f - ty)*(1.0f - tx)*read(data[ix + iy*width + niz*width*height]);
|
|
|
|
r += tz*(1.0f - ty)*tx*read(data[nix + iy*width + niz*width*height]);
|
|
|
|
r += tz*ty*(1.0f - tx)*read(data[ix + niy*width + niz*width*height]);
|
|
|
|
r += tz*ty*tx*read(data[nix + niy*width + niz*width*height]);
|
2015-07-28 12:36:08 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
return r;
|
|
|
|
}
|
2015-07-28 12:36:08 +00:00
|
|
|
|
2017-04-10 12:42:17 +00:00
|
|
|
/* TODO(sergey): For some unspeakable reason both GCC-6 and Clang-3.9 are
|
|
|
|
* causing stack overflow issue in this function unless it is inlined.
|
|
|
|
*
|
|
|
|
* Only happens for AVX2 kernel and global __KERNEL_SSE__ vectorization
|
|
|
|
* enabled.
|
|
|
|
*/
|
|
|
|
#ifdef __GNUC__
|
|
|
|
ccl_always_inline
|
|
|
|
#else
|
|
|
|
ccl_never_inline
|
|
|
|
#endif
|
|
|
|
float4 interp_3d_ex_tricubic(float x, float y, float z)
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
{
|
|
|
|
int ix, iy, iz;
|
|
|
|
int nix, niy, niz;
|
|
|
|
/* Tricubic b-spline interpolation. */
|
|
|
|
const float tx = frac(x*(float)width - 0.5f, &ix);
|
|
|
|
const float ty = frac(y*(float)height - 0.5f, &iy);
|
|
|
|
const float tz = frac(z*(float)depth - 0.5f, &iz);
|
|
|
|
int pix, piy, piz, nnix, nniy, nniz;
|
|
|
|
|
|
|
|
switch(extension) {
|
|
|
|
case EXTENSION_REPEAT:
|
|
|
|
ix = wrap_periodic(ix, width);
|
|
|
|
iy = wrap_periodic(iy, height);
|
|
|
|
iz = wrap_periodic(iz, depth);
|
|
|
|
|
|
|
|
pix = wrap_periodic(ix-1, width);
|
|
|
|
piy = wrap_periodic(iy-1, height);
|
|
|
|
piz = wrap_periodic(iz-1, depth);
|
|
|
|
|
|
|
|
nix = wrap_periodic(ix+1, width);
|
|
|
|
niy = wrap_periodic(iy+1, height);
|
|
|
|
niz = wrap_periodic(iz+1, depth);
|
|
|
|
|
|
|
|
nnix = wrap_periodic(ix+2, width);
|
|
|
|
nniy = wrap_periodic(iy+2, height);
|
|
|
|
nniz = wrap_periodic(iz+2, depth);
|
|
|
|
break;
|
|
|
|
case EXTENSION_CLIP:
|
|
|
|
if(x < 0.0f || y < 0.0f || z < 0.0f ||
|
|
|
|
x > 1.0f || y > 1.0f || z > 1.0f)
|
|
|
|
{
|
2016-04-16 22:51:29 +00:00
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
}
|
2017-05-24 15:23:54 +00:00
|
|
|
ATTR_FALLTHROUGH;
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
case EXTENSION_EXTEND:
|
|
|
|
pix = wrap_clamp(ix-1, width);
|
|
|
|
piy = wrap_clamp(iy-1, height);
|
|
|
|
piz = wrap_clamp(iz-1, depth);
|
|
|
|
|
|
|
|
nix = wrap_clamp(ix+1, width);
|
|
|
|
niy = wrap_clamp(iy+1, height);
|
|
|
|
niz = wrap_clamp(iz+1, depth);
|
|
|
|
|
|
|
|
nnix = wrap_clamp(ix+2, width);
|
|
|
|
nniy = wrap_clamp(iy+2, height);
|
|
|
|
nniz = wrap_clamp(iz+2, depth);
|
|
|
|
|
|
|
|
ix = wrap_clamp(ix, width);
|
|
|
|
iy = wrap_clamp(iy, height);
|
|
|
|
iz = wrap_clamp(iz, depth);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
kernel_assert(0);
|
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
|
|
|
}
|
2014-10-22 11:43:33 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
const int xc[4] = {pix, ix, nix, nnix};
|
|
|
|
const int yc[4] = {width * piy,
|
2017-04-10 08:59:31 +00:00
|
|
|
width * iy,
|
|
|
|
width * niy,
|
|
|
|
width * nniy};
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
const int zc[4] = {width * height * piz,
|
2017-04-10 08:59:31 +00:00
|
|
|
width * height * iz,
|
|
|
|
width * height * niz,
|
|
|
|
width * height * nniz};
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
float u[4], v[4], w[4];
|
|
|
|
|
|
|
|
/* Some helper macro to keep code reasonable size,
|
|
|
|
* let compiler to inline all the matrix multiplications.
|
|
|
|
*/
|
2014-10-22 11:43:33 +00:00
|
|
|
#define DATA(x, y, z) (read(data[xc[x] + yc[y] + zc[z]]))
|
|
|
|
#define COL_TERM(col, row) \
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
(v[col] * (u[0] * DATA(0, col, row) + \
|
2017-04-10 08:59:31 +00:00
|
|
|
u[1] * DATA(1, col, row) + \
|
|
|
|
u[2] * DATA(2, col, row) + \
|
|
|
|
u[3] * DATA(3, col, row)))
|
2014-10-22 11:43:33 +00:00
|
|
|
#define ROW_TERM(row) \
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
(w[row] * (COL_TERM(0, row) + \
|
2017-04-10 08:59:31 +00:00
|
|
|
COL_TERM(1, row) + \
|
|
|
|
COL_TERM(2, row) + \
|
|
|
|
COL_TERM(3, row)))
|
2014-10-22 11:43:33 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
SET_CUBIC_SPLINE_WEIGHTS(u, tx);
|
|
|
|
SET_CUBIC_SPLINE_WEIGHTS(v, ty);
|
|
|
|
SET_CUBIC_SPLINE_WEIGHTS(w, tz);
|
2014-10-22 11:43:33 +00:00
|
|
|
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
/* Actual interpolation. */
|
|
|
|
return ROW_TERM(0) + ROW_TERM(1) + ROW_TERM(2) + ROW_TERM(3);
|
2014-10-22 11:43:33 +00:00
|
|
|
|
|
|
|
#undef COL_TERM
|
|
|
|
#undef ROW_TERM
|
|
|
|
#undef DATA
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ccl_always_inline float4 interp_3d_ex(float x, float y, float z,
|
|
|
|
int interpolation = INTERPOLATION_LINEAR)
|
|
|
|
{
|
|
|
|
if(UNLIKELY(!data))
|
|
|
|
return make_float4(0.0f, 0.0f, 0.0f, 0.0f);
|
|
|
|
|
2017-04-10 08:59:31 +00:00
|
|
|
switch(interpolation) {
|
[Cycles/msvc] Get cycles_kernel compile time under control.
Ever since we merged the extra texture types (half etc) and spit kernel the compile time for cycles_kernel has been going out of control.
It's currently sitting at a cool 1295.762 seconds with our standard compiler (2013/x64/release)
I'm not entirely sure why msvc gets upset with it, but the inlining of matrix near the bottom of the tri-cubic 3d interpolator is the source of the issue, this patch excludes it from being inlined.
This patch bring it back down to a manageable 186 seconds. (7x faster!!)
with the attached bzzt.blend that @sergey kindly provided i got the following results with builds with identical hashes
58:51.73 buildbot
58:04.23 Patched
it's really close, the slight speedup could be explained by the switch instead of having multiple if's (switches do generate more optimal code than a chain of if/else/if/else statements) but in all honesty it might just have been pure luck (dev box,very polluted, bad for benchmarks) regardless, this patch doesn't seem to slow down anything with my limited testing.
{F532336}
{F532337}
Reviewers: brecht, lukasstockner97, juicyfruit, dingto, sergey
Reviewed By: brecht, dingto, sergey
Subscribers: InsigMathK, sergey
Tags: #cycles
Differential Revision: https://developer.blender.org/D2595
2017-04-07 16:25:54 +00:00
|
|
|
case INTERPOLATION_CLOSEST:
|
|
|
|
return interp_3d_ex_closest(x, y, z);
|
|
|
|
case INTERPOLATION_LINEAR:
|
|
|
|
return interp_3d_ex_linear(x, y, z);
|
|
|
|
default:
|
|
|
|
return interp_3d_ex_tricubic(x, y, z);
|
2014-10-22 11:43:33 +00:00
|
|
|
}
|
2011-04-27 11:58:34 +00:00
|
|
|
}
|
|
|
|
|
2014-05-04 20:57:33 +00:00
|
|
|
ccl_always_inline void dimensions_set(int width_, int height_, int depth_)
|
|
|
|
{
|
|
|
|
width = width_;
|
|
|
|
height = height_;
|
|
|
|
depth = depth_;
|
|
|
|
}
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
T *data;
|
2014-03-29 12:03:48 +00:00
|
|
|
int interpolation;
|
2015-07-28 11:51:10 +00:00
|
|
|
ExtensionType extension;
|
2014-03-29 12:03:48 +00:00
|
|
|
int width, height, depth;
|
2015-02-01 20:40:01 +00:00
|
|
|
#undef SET_CUBIC_SPLINE_WEIGHTS
|
2011-04-27 11:58:34 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
typedef texture<float4> texture_float4;
|
2012-01-20 17:49:17 +00:00
|
|
|
typedef texture<float2> texture_float2;
|
2011-04-27 11:58:34 +00:00
|
|
|
typedef texture<float> texture_float;
|
|
|
|
typedef texture<uint> texture_uint;
|
|
|
|
typedef texture<int> texture_int;
|
|
|
|
typedef texture<uint4> texture_uint4;
|
2012-05-13 12:32:44 +00:00
|
|
|
typedef texture<uchar4> texture_uchar4;
|
2016-08-14 18:21:08 +00:00
|
|
|
typedef texture<uchar> texture_uchar;
|
2016-05-09 10:51:42 +00:00
|
|
|
typedef texture_image<float> texture_image_float;
|
2016-05-12 12:51:42 +00:00
|
|
|
typedef texture_image<uchar> texture_image_uchar;
|
2016-06-19 15:31:16 +00:00
|
|
|
typedef texture_image<half> texture_image_half;
|
2011-04-27 11:58:34 +00:00
|
|
|
typedef texture_image<float4> texture_image_float4;
|
|
|
|
typedef texture_image<uchar4> texture_image_uchar4;
|
2016-06-19 15:31:16 +00:00
|
|
|
typedef texture_image<half4> texture_image_half4;
|
2011-04-27 11:58:34 +00:00
|
|
|
|
|
|
|
/* Macros to handle different memory storage on different devices */
|
|
|
|
|
|
|
|
#define kernel_tex_fetch(tex, index) (kg->tex.fetch(index))
|
2016-10-12 11:03:15 +00:00
|
|
|
#define kernel_tex_fetch_avxf(tex, index) (kg->tex.fetch_avxf(index))
|
2014-06-13 19:13:18 +00:00
|
|
|
#define kernel_tex_fetch_ssef(tex, index) (kg->tex.fetch_ssef(index))
|
|
|
|
#define kernel_tex_fetch_ssei(tex, index) (kg->tex.fetch_ssei(index))
|
2013-04-01 20:26:43 +00:00
|
|
|
#define kernel_tex_lookup(tex, t, offset, size) (kg->tex.lookup(t, offset, size))
|
2016-05-09 10:51:42 +00:00
|
|
|
|
2016-05-20 14:46:49 +00:00
|
|
|
#define kernel_tex_image_interp(tex,x,y) kernel_tex_image_interp_impl(kg,tex,x,y)
|
|
|
|
#define kernel_tex_image_interp_3d(tex, x, y, z) kernel_tex_image_interp_3d_impl(kg,tex,x,y,z)
|
|
|
|
#define kernel_tex_image_interp_3d_ex(tex, x, y, z, interpolation) kernel_tex_image_interp_3d_ex_impl(kg,tex, x, y, z, interpolation)
|
2014-03-29 12:03:48 +00:00
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
#define kernel_data (kg->__data)
|
|
|
|
|
2014-12-16 15:27:44 +00:00
|
|
|
#ifdef __KERNEL_SSE2__
|
|
|
|
typedef vector3<sseb> sse3b;
|
|
|
|
typedef vector3<ssef> sse3f;
|
|
|
|
typedef vector3<ssei> sse3i;
|
2015-02-10 19:20:34 +00:00
|
|
|
|
|
|
|
ccl_device_inline void print_sse3b(const char *label, sse3b& a)
|
|
|
|
{
|
|
|
|
print_sseb(label, a.x);
|
|
|
|
print_sseb(label, a.y);
|
|
|
|
print_sseb(label, a.z);
|
|
|
|
}
|
|
|
|
|
|
|
|
ccl_device_inline void print_sse3f(const char *label, sse3f& a)
|
|
|
|
{
|
|
|
|
print_ssef(label, a.x);
|
|
|
|
print_ssef(label, a.y);
|
|
|
|
print_ssef(label, a.z);
|
|
|
|
}
|
|
|
|
|
|
|
|
ccl_device_inline void print_sse3i(const char *label, sse3i& a)
|
|
|
|
{
|
|
|
|
print_ssei(label, a.x);
|
|
|
|
print_ssei(label, a.y);
|
|
|
|
print_ssei(label, a.z);
|
|
|
|
}
|
|
|
|
|
2014-12-16 15:27:44 +00:00
|
|
|
#endif
|
|
|
|
|
2011-04-27 11:58:34 +00:00
|
|
|
CCL_NAMESPACE_END
|
|
|
|
|
|
|
|
#endif /* __KERNEL_COMPAT_CPU_H__ */
|
|
|
|
|