<div dir="ltr">That is weird, ptax reports stack for each of the functions here..<div><br></div><div>Anyway, got a quick implementation of stackless BVH traversal [1]. It&#39;s currently quite slower (like, 20%), but it totally lacks closest-child-traversal heuristic, so hopefully by bringing it back we can compensate for the speed. However, what&#39;s much more weird, memory usage difference is next to nothing here (it&#39;s less than 1% even with fully empty scene).</div><div><br></div><div>Would be nice if someone makes additional tests on a higher level cards, maybe there&#39;ll be a difference (i was testing 760 and c2075 so far).</div><div><br></div><div>[1] <a href="https://developer.blender.org/D2032">https://developer.blender.org/D2032</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 10:29 AM, Brecht Van Lommel <span dir="ltr">&lt;<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Windows 10, CUDA toolkit 7.5, GTX 960 (sm_52).<br>
<br>
For the stack ptxas output, it reports &quot;0 bytes stack frame&quot; for all<br>
functions expect the entry functions here. For the spills, if you add<br>
those up it seems to exceed the numbers in the entry function, so I<br>
guess it does not include all nested functions.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, May 25, 2016 at 9:17 AM, Sergey Sharybin &lt;<a href="mailto:sergey.vfx@gmail.com">sergey.vfx@gmail.com</a>&gt; wrote:<br>
&gt; Brecht, that&#39;s a real nice breakdown! Question tho, what OS and GPU you<br>
&gt; used? I&#39;ve been playing a bit last night with setting BVH stack stack to 4<br>
&gt; and didn&#39;t see measurable difference in neither GPU memory consumption nor<br>
&gt; in compiler output, which is rather weird.<br>
&gt;<br>
&gt; Side question: the stats of stack/spills reported by PTex about entry<br>
&gt; function, does it include all nested function calls or it&#39;s only a stats of<br>
&gt; kernel function itself?<br>
&gt;<br>
&gt; On Wed, May 25, 2016 at 12:29 AM, Brecht Van Lommel<br>
&gt; &lt;<a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Stackless BVH traversal could be nice (I probably won&#39;t work on that<br>
&gt;&gt; though). If FireRays is using it then it must work well on AMD cards.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve tried to make a breakdown of stack memory usage here. Seems BVH<br>
&gt;&gt; stacks account for about 10-14% of stack memory now:<br>
&gt;&gt; <a href="https://developer.blender.org/D2023#46333" rel="noreferrer" target="_blank">https://developer.blender.org/D2023#46333</a><br>
&gt;&gt;<br>
&gt;&gt; On Tue, May 24, 2016 at 12:46 PM, Sergey Sharybin &lt;<a href="mailto:sergey.vfx@gmail.com">sergey.vfx@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hi,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Brecht, nice work indeed! :)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Stefan, sharing the stack is an interesting idea indeed, but there are<br>
&gt;&gt; &gt; techniques of stack-less BVH traversal. If i read it correct, that&#39;s<br>
&gt;&gt; &gt; exactly<br>
&gt;&gt; &gt; what was implemented in FireRays. Shouldn&#39;t be that hard to experiment<br>
&gt;&gt; &gt; with<br>
&gt;&gt; &gt; both shared stack and stackless implementations. Let me know if you&#39;re<br>
&gt;&gt; &gt; up to<br>
&gt;&gt; &gt; that tests or if me or Brecht can look into this (so we don&#39;t do<br>
&gt;&gt; &gt; duplicated<br>
&gt;&gt; &gt; work).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Tue, May 24, 2016 at 12:32 PM, Stefan Werner &lt;<a href="mailto:swerner@smithmicro.com">swerner@smithmicro.com</a>&gt;<br>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Impressive! That goes beyond what I’ve done so far. One thing we may<br>
&gt;&gt; &gt;&gt; want<br>
&gt;&gt; &gt;&gt; to test is to share the BVH traversal stack, my suspicion is that nvcc<br>
&gt;&gt; &gt;&gt; for<br>
&gt;&gt; &gt;&gt; Maxwell also reserves memory for every possible instance of the<br>
&gt;&gt; &gt;&gt; traversal<br>
&gt;&gt; &gt;&gt; function (triangle, hair, motion, SSS, etc).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Next up in terms of breaking the memory barrier is using host memory<br>
&gt;&gt; &gt;&gt; when<br>
&gt;&gt; &gt;&gt; CUDA runs out of device memory, we’ve tested it extensively for 2D<br>
&gt;&gt; &gt;&gt; textures<br>
&gt;&gt; &gt;&gt; already in Poser. I’m working on a patch right now, it will just take a<br>
&gt;&gt; &gt;&gt; little time to make it work with 3d and bindless textures. When using<br>
&gt;&gt; &gt;&gt; host<br>
&gt;&gt; &gt;&gt; memory, I can throw GB’s worth of textures at an anemic GTX 460 (768MB<br>
&gt;&gt; &gt;&gt; VRAM).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; -Stefan<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On 5/22/16, 6:53 PM, &quot;<a href="mailto:bf-cycles-bounces@blender.org">bf-cycles-bounces@blender.org</a> on behalf of Brecht<br>
&gt;&gt; &gt;&gt; Van Lommel&quot; &lt;<a href="mailto:bf-cycles-bounces@blender.org">bf-cycles-bounces@blender.org</a> on behalf of<br>
&gt;&gt; &gt;&gt; <a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;I&#39;ve added some optimizations for reducing stack memory usage here:<br>
&gt;&gt; &gt;&gt; &gt;<a href="https://developer.blender.org/D2023" rel="noreferrer" target="_blank">https://developer.blender.org/D2023</a><br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;On Wed, May 18, 2016 at 2:27 PM, Stefan Werner<br>
&gt;&gt; &gt;&gt; &gt; &lt;<a href="mailto:swerner@smithmicro.com">swerner@smithmicro.com</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt;&gt; Don’t be too excited too early. The more I work with it, the more it<br>
&gt;&gt; &gt;&gt; &gt;&gt; looks<br>
&gt;&gt; &gt;&gt; &gt;&gt; like it’s just an elaborate workaround for compiler behavior. It<br>
&gt;&gt; &gt;&gt; &gt;&gt; appears<br>
&gt;&gt; &gt;&gt; &gt;&gt; that NVCC insists on inlining everything on Maxwell, ignoring any<br>
&gt;&gt; &gt;&gt; &gt;&gt; __noinline__ hints.  So far, there are no benefits whatsoever on<br>
&gt;&gt; &gt;&gt; &gt;&gt; Kepler,<br>
&gt;&gt; &gt;&gt; &gt;&gt; there NVCC appears to do the right thing out of the box.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; I submitted a bug report to Nvidia about the difference in stack<br>
&gt;&gt; &gt;&gt; &gt;&gt; usage<br>
&gt;&gt; &gt;&gt; &gt;&gt; between Kepler and Maxwell last year, and it was marked as resolved<br>
&gt;&gt; &gt;&gt; &gt;&gt; and<br>
&gt;&gt; &gt;&gt; &gt;&gt; to<br>
&gt;&gt; &gt;&gt; &gt;&gt; be shipped in the next CUDA update. So maybe I shouldn’t spend too<br>
&gt;&gt; &gt;&gt; &gt;&gt; much<br>
&gt;&gt; &gt;&gt; &gt;&gt; time<br>
&gt;&gt; &gt;&gt; &gt;&gt; with it until we see CUDA 8.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; -Stefan<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; From: &lt;<a href="mailto:bf-cycles-bounces@blender.org">bf-cycles-bounces@blender.org</a>&gt; on behalf of Thomas Dinges<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:blender@dingto.org">blender@dingto.org</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Reply-To: Discussion list to assist Cycles render engine developers<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Date: Tuesday, May 17, 2016 at 4:45 PM<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; To: Discussion list to assist Cycles render engine developers<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Subject: Re: [Bf-cycles] split kernel and CUDA<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; That sounds promising, feel free to submit a patch for this and we<br>
&gt;&gt; &gt;&gt; &gt;&gt; can<br>
&gt;&gt; &gt;&gt; &gt;&gt; check. :)<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Am 17.05.2016 um 16:40 schrieb Stefan Werner:<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; The patch is surprisingly clean. It removes some of the #ifdef<br>
&gt;&gt; &gt;&gt; &gt;&gt; __SPLIT_KERNEL__ blocks and unifies CPU, OpenCL and CUDA a bit more.<br>
&gt;&gt; &gt;&gt; &gt;&gt; I<br>
&gt;&gt; &gt;&gt; &gt;&gt; didn’t run a speed benchmark, and I wouldn’t even make speed the<br>
&gt;&gt; &gt;&gt; &gt;&gt; ultimate<br>
&gt;&gt; &gt;&gt; &gt;&gt; top priority: Right now, the problem we see in the field is that<br>
&gt;&gt; &gt;&gt; &gt;&gt; people<br>
&gt;&gt; &gt;&gt; &gt;&gt; are<br>
&gt;&gt; &gt;&gt; &gt;&gt; unable to use high-end gaming GPUs because the VRAM is so full of<br>
&gt;&gt; &gt;&gt; &gt;&gt; geometry<br>
&gt;&gt; &gt;&gt; &gt;&gt; and textures that the CUDA runtime doesn’t have room for kernel<br>
&gt;&gt; &gt;&gt; &gt;&gt; memory<br>
&gt;&gt; &gt;&gt; &gt;&gt; any<br>
&gt;&gt; &gt;&gt; &gt;&gt; more. On my 1664 core M4000 card, I see a simple kernel launch<br>
&gt;&gt; &gt;&gt; &gt;&gt; already<br>
&gt;&gt; &gt;&gt; &gt;&gt; taking ~1600MB of VRAM with almost empty scenes.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; It looks to me like the CUDA compiler reserves room for every stack<br>
&gt;&gt; &gt;&gt; &gt;&gt; instance<br>
&gt;&gt; &gt;&gt; &gt;&gt; of ShaderData (or other structs) in advance, and that sharing that<br>
&gt;&gt; &gt;&gt; &gt;&gt; memory<br>
&gt;&gt; &gt;&gt; &gt;&gt; instead of instantiating it separately is an easy way to reduce VRAM<br>
&gt;&gt; &gt;&gt; &gt;&gt; requirements without changing the code much.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; -Stefan<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; From: &lt;<a href="mailto:bf-cycles-bounces@blender.org">bf-cycles-bounces@blender.org</a>&gt; on behalf of Sergey Sharybin<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:sergey.vfx@gmail.com">sergey.vfx@gmail.com</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Reply-To: Discussion list to assist Cycles render engine developers<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Date: Tuesday, May 17, 2016 at 9:20 AM<br>
&gt;&gt; &gt;&gt; &gt;&gt; To: Discussion list to assist Cycles render engine developers<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:bf-cycles@blender.org">bf-cycles@blender.org</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Subject: Re: [Bf-cycles] split kernel and CUDA<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; hi,<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Lukas Stocker was doing experiments with CUDA split kernel. With the<br>
&gt;&gt; &gt;&gt; &gt;&gt; current<br>
&gt;&gt; &gt;&gt; &gt;&gt; design of the split it was taking more VRAM actually, AFAIR.<br>
&gt;&gt; &gt;&gt; &gt;&gt; Hopefully<br>
&gt;&gt; &gt;&gt; &gt;&gt; he&#39;ll<br>
&gt;&gt; &gt;&gt; &gt;&gt; read this mail and reply in more details.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Would be cool to have this front moving forward, but i fear we&#39;ll<br>
&gt;&gt; &gt;&gt; &gt;&gt; have<br>
&gt;&gt; &gt;&gt; &gt;&gt; to<br>
&gt;&gt; &gt;&gt; &gt;&gt; step back and reconsider some things about how split kernel works<br>
&gt;&gt; &gt;&gt; &gt;&gt; together<br>
&gt;&gt; &gt;&gt; &gt;&gt; with a regular one.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; There are interesting results on the stack memory! I can see number<br>
&gt;&gt; &gt;&gt; &gt;&gt; of<br>
&gt;&gt; &gt;&gt; &gt;&gt; spill<br>
&gt;&gt; &gt;&gt; &gt;&gt; loads go up tho, did you measure if it gives measurable render time<br>
&gt;&gt; &gt;&gt; &gt;&gt; slowdown? And how messy is the patch i wonder :)<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; On Tue, May 17, 2016 at 8:47 AM, Stefan Werner<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:swerner@smithmicro.com">swerner@smithmicro.com</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Hi,<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Has anyone experimented with building a split kernel for CUDA? It<br>
&gt;&gt; &gt;&gt; &gt;&gt; seems<br>
&gt;&gt; &gt;&gt; &gt;&gt; to<br>
&gt;&gt; &gt;&gt; &gt;&gt; me that this could lift some of the limitations on Nvidia hardware,<br>
&gt;&gt; &gt;&gt; &gt;&gt; such as<br>
&gt;&gt; &gt;&gt; &gt;&gt; the high memory requirements on cards with many CUDA cores or the<br>
&gt;&gt; &gt;&gt; &gt;&gt; driver<br>
&gt;&gt; &gt;&gt; &gt;&gt; time out. I just tried out what happens when I take the shared<br>
&gt;&gt; &gt;&gt; &gt;&gt; ShaderData<br>
&gt;&gt; &gt;&gt; &gt;&gt; (KernelGlobals.sd_input) from the split kernel into the CUDA kernel,<br>
&gt;&gt; &gt;&gt; &gt;&gt; as<br>
&gt;&gt; &gt;&gt; &gt;&gt; opposed to creating separate ShaderData structs on the stack, and it<br>
&gt;&gt; &gt;&gt; &gt;&gt; looks<br>
&gt;&gt; &gt;&gt; &gt;&gt; like it has an impact:<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; before:<br>
&gt;&gt; &gt;&gt; &gt;&gt; ptxas info    : Compiling entry function<br>
&gt;&gt; &gt;&gt; &gt;&gt; &#39;kernel_cuda_branched_path_trace&#39;<br>
&gt;&gt; &gt;&gt; &gt;&gt; for &#39;sm_50&#39;<br>
&gt;&gt; &gt;&gt; &gt;&gt; ptxas info    : Function properties for<br>
&gt;&gt; &gt;&gt; &gt;&gt; kernel_cuda_branched_path_trace<br>
&gt;&gt; &gt;&gt; &gt;&gt;     68416 bytes stack frame, 1188 bytes spill stores, 3532 bytes<br>
&gt;&gt; &gt;&gt; &gt;&gt; spill<br>
&gt;&gt; &gt;&gt; &gt;&gt; loads<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; after:<br>
&gt;&gt; &gt;&gt; &gt;&gt; ptxas info    : Compiling entry function<br>
&gt;&gt; &gt;&gt; &gt;&gt; &#39;kernel_cuda_branched_path_trace&#39;<br>
&gt;&gt; &gt;&gt; &gt;&gt; for &#39;sm_50&#39;<br>
&gt;&gt; &gt;&gt; &gt;&gt; ptxas info    : Function properties for<br>
&gt;&gt; &gt;&gt; &gt;&gt; kernel_cuda_branched_path_trace<br>
&gt;&gt; &gt;&gt; &gt;&gt;     58976 bytes stack frame, 1256 bytes spill stores, 3676 bytes<br>
&gt;&gt; &gt;&gt; &gt;&gt; spill<br>
&gt;&gt; &gt;&gt; &gt;&gt; loads<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; -Stefan<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; &gt;&gt; Bf-cycles mailing list<br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; --<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; With best regards, Sergey Sharybin<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Bf-cycles mailing list<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; &gt;&gt; Bf-cycles mailing list<br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;_______________________________________________<br>
&gt;&gt; &gt;&gt; &gt;Bf-cycles mailing list<br>
&gt;&gt; &gt;&gt; &gt;<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt;&gt; &gt;&gt; &gt;<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; Bf-cycles mailing list<br>
&gt;&gt; &gt;&gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt;&gt; &gt;&gt; <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; With best regards, Sergey Sharybin<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Bf-cycles mailing list<br>
&gt;&gt; &gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt;&gt; &gt; <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Bf-cycles mailing list<br>
&gt;&gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt;&gt; <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; With best regards, Sergey Sharybin<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bf-cycles mailing list<br>
&gt; <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
&gt; <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div></div>
</div>