Doing this in a fully 'clean' way is far from obvious, especially
unregister, you often end up leaving nasty 'orphanned' keymap items
referring to unregistered operators...
See gpu_shader.c for the main changes.
EXT_geometry_shader4 brought this feature to GL versions < 3.2, but now it's just cluttering up our code.
Soon all platforms will be on version 3.3 so we won't even have to check support at runtime!
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.
Single quads are drawn as a TRIANGLE_FAN, with 4 verts in the same order.
Multiple quads now use PRIM_QUADS_XXX and will need further work. Only 8 places still use this.
Part of T49043
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
We concatenate #defines and #extensions into these, and can count the max string lengths needed. 256 is enough to hold today's strings; we can adjust later if needed.
When WITH_LEGACY_OPENGL = OFF.
This is our final target for Blender 2.8, all previous versions will be dropped in the future. GLSL 3.3 is richer so we don't require as many extensions.
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
It's possible that cancellation occured between the creation of the reader
and the creation of the Blender object, in which case reader->object()
returns a NULL pointer.
BKE_libblock_free_us() was called on the object data, which decrements
its user count, after which the same function was called on the object,
which decrements the user count of the object data again. This double
decrement was too much.
Original code from @Severin with changes from @dfelinto & @hypersomniac.
This doesn't cause many functional changes
besides using new transform manipulators.
Submitted as D2604
