<div dir="ltr"><div><div><div>Hi Brecht,<br><br></div>Thx for the explanation. Also in some scenes like the Barcelona scene the actual slowdown when using OSL is greater then a factor of 5. when testing with 2.67b.<br></div>
I will try to figure out actual cost for each of the pieces in the chain. Since people like using lot and lots of textures I think if we can do something to decrease this gap we might make osl shading more appealing.<br><br>
</div><div>Also do you know how this is handled in any other implementation of OSL. I cannot imagine they would not run into this.<br><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sun, Jul 7, 2013 at 12:15 PM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OIIO is a lot more overhead even when using bilinear filtering, look<br>
at TextureSystemImpl::texture_lookup and accum_sample_bilinear. Plus<br>
it has to track texture coordinate derivatives this texture lookup in<br>
OSL. Might be interesting to run a profiler anyway, shows you<br>
immediately which functions are slow, can always be something<br>
unexpected.<br>
<br>
The more advanced texture filtering is nice if you take few AA<br>
samples. If you take many the simple SVM filtering will converge to<br>
the right results anyway so the extra cost isn't really worth it.<br>
Though for bilinear I guess a lot of the overhead comes from other<br>
features the texture lookup call provides, checking all the different<br>
options.<br>
<div><div class="h5"><br>
On Sun, Jul 7, 2013 at 11:39 AM, Martijn Berger<br>
<<a href="mailto:martijn.berger@gmail.com">martijn.berger@gmail.com</a>> wrote:<br>
> I did some quick tests to empirically test the hypothesis that osl<br>
> performance is made much worse by texture filtering or translation of<br>
> structures.<br>
><br>
> First texture filtering:<br>
><br>
> I made a scene with a plane, a camera and an environment of a solid color:<br>
><br>
> I added a texture and measured:<br>
><br>
> svm: OSL: modified OSL:<br>
><br>
> 0:12:40 0:27:72 0:26:60<br>
> 0:12:40 0:27:90 0:26:75<br>
> 0:12:40 0:28:03 0:26:53<br>
><br>
> modified OSL is a one line change to force bi-linear texture interpolation:<br>
><br>
> intern/cycles/kernel/osl/osl_services.cpp: ~ line 772 add:<br>
> options.interpmode = TextureOpt::InterpBilinear;<br>
><br>
> I am getting what looks like a measurable significant result but no where<br>
> near what we need to explain performance gap.<br>
><br>
> Diffuse:<br>
><br>
> svm: OSL:<br>
> 0:09:10 0:11:25<br>
> 0:09:10 0:11:17<br>
> 0:09:08 0:11:17<br>
><br>
> noise texture<br>
><br>
> svm: OSL:<br>
> 0:17:02 0:23:18<br>
> 0:16:97 0:23:00<br>
> 0:16:98 0:22:96<br>
><br>
> both of the above are in line with each other both would indicate a<br>
> performance loss of about 25 % on using OSL for trivial shaders due to<br>
> translation of data, OSL initialization etc.<br>
><br>
> To me it seems that image textures are getting a huge hit and that the<br>
> SmartBicubic filter is not the main problem.<br>
><br>
> Hope this info helps. I am continuing the dig to find the root cause.<br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</blockquote></div><br></div>