Incorrect Behaviour With Return Statement In Middle Of Shader

[Daniel Dresser]

After stripping this one down to a simple case, and staring at it for a while, it really looks to me like this is some sort of bug in OSL.  I guess it's related to optimizing out parts of a shader with a return statement in a conditional.  I'm currently running OSL 1.9.6 - apologies for the old version, maybe this is fixed already, but I didn't spot anything that looked relevant in the changelog, so I figured I would ask.

My test shader is this:

test.osl

"""

shader test ( float mask = 0, output color out = 0 )

{

    if( mask <= 0 )

    {

        out = color( 1, 0, 0);

        return;

    }

    out = color( 0,1,0);

}

"""

And I'm running with this:

> oslc test.osl

> testshade -o out out.exr --print --param mask 0.0 test

In OSL 1.9.6, this outputs:

"""

Output out to out.exr

Pixel (0, 0):

  out : 0 0 0

"""

I would expect it to output 1 0 0.  Or 0 1 0 if mask was greater.  But there shouldn't be any way this code would output 0 0 0.  It seems to give the expected results if the value of mask isn't a constant that can be optimized out.

Easy enough to work around by avoiding return statements inside conditionals, but it would be nice to get some confirmation I'm not going insane.

-Daniel Dresser

[Olivier Paquet]

Le mercredi 18 mars 2020 21:41:45 UTC-4, Daniel Dresser a écrit :

After stripping this one down to a simple case, and staring at it for a while, it really looks to me like this is some sort of bug in OSL.  I guess it's related to optimizing out parts of a shader with a return statement in a conditional.  I'm currently running OSL 1.9.6 - apologies for the old version, maybe this is fixed already, but I didn't spot anything that looked relevant in the changelog, so I figured I would ask.

Looks like it has been fixed, the output is as you expect in 1.10.9. I remember running into a variation of this about 2 years ago.

This looks like it may be the relevant fix: https://github.com/imageworks/OpenShadingLanguage/commit/5ee8f866e25c11efc4ad5fb1a876471915867e31

Olivier

[Daniel Dresser]

Ah, cool.  That totally makes sense.  I'd also tested in Arnold, and it's not 100% clear what version of OSL they're using, but that's a recent enough fix that it makes sense that they haven't gotten it yet.

I probably should have just gotten a more recent version installed myself, but anyway, thanks a lot for clearing this up :)

[Larry Gritz]

Thanks, Olivier. I'm going to assume it is indeed fixed unless somebody reports that they can still repro on a recent stable release.

As far as detecting versions...

In a shader, you can

    printf ("oslc version = %d\n", OSL_VERSION);

    int version = 0;

    getattriubute("osl:version", version);

    printf ("OSL runtime version = %d\n", version);

This is 10000*major + 100*minor + patch. So, for example 1.9.6 would be 10906.

--

Larry Gritz

l...@larrygritz.com

[Thiago Ize]

The problem is that Arnold sometimes builds OSL from a commit that is somewhere between versions X and X+1. For instance, we need a fix that was committed yesterday, but don't want to wait until the first of the month for an "official" OSL version bump, so while we report X+1, we're really on X+0.62342...

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/A02C383E-B2A9-4483-9A49-98C7A43108C5%40larrygritz.com.

[Declan Russell]

Just FYI so you don't get mislead. Arnold will tell you its on 1.11.0 because we're somewhere on master. However I can confirm we don't have that fix yet though.

[Larry Gritz]

For people in these situations, I have started tagging spots on master that I think are good places to sync, and I do bump version numbers when I do this. They aren't officially supported releases, but only in the sense that a *real* release is guaranteed not to break API or ABI compatibility with prior releases in their X.Y.* family, whereas these developer snapshots in master do not make any such promises (and thus are named "X.Y.Z-dev").

I try to do this if I really do something that breaks compatibility, or sometimes when I add something new and exciting. But I'm also very happy to do a tag and bump master's version patch number. Just send me an email, "product ABC needs to do a release next week, can you make a tag so we have unique version number?" and I'm happy to do it.

In fact, this will be even less bottlenecked on me once the TSC gets into swing and commit/merge privileges are distributed to more people.

-- lg

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/osl-dev/01409e45-682e-4922-8540-28c10672ae8f%40googlegroups.com.

--

Larry Gritz

l...@larrygritz.com