We should double-check that the placeholder struct symbol table entries don't take any space in the heap. They aren't intended to. If you don't have time to do it, please just file a ticket and I'll

Reviewers: dev-osl_imageworks.com, osl-dev_googlegroups.com, Description: Add a new opcode that computes sin and cos together Please review this at

Dude, use the C++ sincos() function to compute the sines and cosines! You may as well make the underlying implementation faster in the same way. Other than that,

You may This is a GNU extension, it isn't part of any standard to my knowledge. Can you think of a cross platform way of detecting it? http://codereview.appspot.com/205045/show

I would put in fmath.h: #ifndef __GNUC__ ... define it in terms of sin and cos... #endif -- Larry Gritz l...@...

Its more complicated than that. The symbol doesn't show up by default. You need to do: #define _GNU_SOURCE #include <math.h> And of course, its hard to know where math.h (or cmath) is first included

Of course, please substitute whatever compiler or version checks *correctly* discern whether sincos is available. -- Larry Gritz l...@...

1. At the top of fmath.h, before #include <cmath>: #ifndef __MATH_H__ #define _GNU_SOURCE #endif 2. In fmath.h, define sincos #if !defined(_GNU_SOURCE) || !defined(__GNUC__) ||

I found an alternative that gets around having to use _GNU_SOURCE (which might have other weird side effects). http://codereview.appspot.com/205045/show

using portable sincos instead of calls to sin and cos http://codereview.appspot.com/205045/show

Here is the patch to fmath.h: Index: src/include/fmath.h =================================================================== --- src/include/fmath.h (revision 1392) +++ src/include/fmath.h (working

Solaris provides sincos as part of math.h. Given that OSL is now an open-source project, probably at some point it'll need to grow a configure based solution to find functions. If configure was

Reviewers: , Description: We've done extensive analysis showing that for typical shading batches we see in the wild, our method of having an array of true/false runflags is very wasteful, and despite

Incidentally, how much slower do we render by keeping both the runflags and indices in place? Only 2%. So this makes me think that quite soon into changing the individual shadeops, we'll break even

LGTM http://codereview.appspot.com/206045/show

LGTM2 http://codereview.appspot.com/206045/diff/1/4 File src/liboslexec/exec.cpp (right): http://codereview.appspot.com/206045/diff/1/4#newcode583 src/liboslexec/exec.cpp:583: #if 1 Should this be

No, it's 2% slower with it '#if 0'. I'm not going to commit in this state, I just wanted to show everybody how I'd verified that I'm maintaining the index list correctly and the general scheme of

gcc documentation suggests that it can (macro TARGET_HAS_SINCOS) - but our version doesn't seem to do it automatically. In theory its true that it would be nice to just let the compiler take care of

On 2010/02/08 19:54:50, ckulla wrote: Any comments on this? http://codereview.appspot.com/205043/show

LGTM http://codereview.appspot.com/205043/show