Global size depends on memory usage which might change during rendering.
Havent seen it happen but seems possible that this could cause the global
size to be different than what was used for allocating buffers.
The issue was caused by recent change in inline policy.
There is some sort of memory corruption happening here, ASAN suggests
it's stack overflow issue. Not quite sure why it is happening tho and
was not able to solve anything here yet in the past hours.
Committing fix which works with a big TODO note.
The issue is visible on AVX2 machine when rendering cycles_reports_test.
This is an auto-generated list, crossing gl-deprecated.h, glew.h and the
Blender code. It allows Blender to build with core profile.
WITH_OPENGL_LEGACY=ON: nothing changes
WITH_OPENGL_LEGACY=OFF and WITH_GL_PROFILE_CORE=OFF:
It stubs deprecated legacy calls.
WITH_OPENGL_LEGACY=OFF and WITH_GL_PROFILE_CORE=ON:
It stubs deprecated legacy calls thus allowing Blender to build with
core profile only.
Technically you only want to use WITH_OPENGL_LEGACY=OFF when
WITH_GL_PROFILE_CORE=ON. But it doesn't hurt to have it working for both
scenarios.
Reviewed by: merwin
Differential Revision: https://developer.blender.org/D2610
Callers now have to use Gawain's PRIM enum to specify geometric primitives.
This makes the API more bullet-proof (at least less vulnerable) since GLenum covers waaay more than GL_POINTS, GL_LINES, etc.
Also prepares us for Vulkan.
Callers now have to use Gawain's COMP enum to specify vertex attributes.
This makes the API more bullet-proof (at least less vulnerable) since GLenum covers waaay more than component types.
Also prepares us for Vulkan.
Quads are not part of modern GL or Vulkan, so we should avoid them. XXX makes coders think "hmm how could I draw this without using quads?"
Quads will be removed during the transition to core profile.
Part of T49043
This seems to happen on Windows only, happened to Thomas and Nathan already.
Similar patch Thomas was showing, but i do not see it committted. So comitting
now in order to get more developers and users happy.
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
The state mask wasnt applied before comparison giving false results. It
shouldnt really happen that a ray state contains any flags that need to
be masked away, but if it does happen its better to not get stuck.
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
This avoids write access happening in non-atomic manner in
Shader::tag_update which modifies the global managers. Even
for 1 byte data types it's quite dangerous.
The issue is coming from the fact that float3 is actually 16 bytes aligned
data type and the "padding" was not initialized. This caused memcmp() to
access non-initialized memory.
