<div dir="ltr"><div><div><div><div>Memory bandwidth and divergence <i>should </i>be the main factors limiting the performance of the cycles GPU code. GPUs work by executing the same instruction across multiple threads - all of the instructions in a warp must be following the same code path. Whenever threads in the same warp follow different paths, the GPU must repeat the instructions for each path, suppressing commitment of results for the pipelines that are not on the current path for each repeat.<br>
<br></div><div>Memory locality is another significant factor: when all of the threads in a warp fetch consecutive values, the GPU can coalesce the loads into one big, efficient load from memory. If threads in a warp are fetching from disjoint memory locations, the GPU needs more cycles to gather all of the loaded values using multiple memory accesses.<br>
</div><br></div>In summary, there will be moments when the GPU is massively parallel, moments when some of the threads are doing work, and pathological moments where few or even only one thread in a warp is taking a given code path.<br>
<br></div><div>One GPU thread is nowhere near as fast as one CPU thread. GPUs are clocked a lot slower than CPUs, and CPUs are optimized for very low latencies. GPUs sacrifice latency to get maximum bandwidth. GPUs rely on parallelism to beat CPUs.<br>
</div><div><br></div>CUDA makes it appear that the CPU is doing a lot of work because it uses a polling spin-loop to wait for completion of a kernel execution, to reduce the latency of waiting for kernel completion as much as possible. It is possible to configure CUDA not to do this (likely using an IRQ for notification), and I tried it, CPU usage dropped a lot, but as expected, kernel completion latency increased. I also spent a <i>lot</i> of time (at least a week) experimenting with overlapping and asynchronous memory transfers, and my finding was, memory copies to and from GPU are definitely not the bottleneck.<br>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 30, 2014 at 2:12 PM, GeKo <span dir="ltr">&lt;<a href="mailto:geko.pua@gmail.com" target="_blank">geko.pua@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I was reading about the hierarchy of memory on Cuda and It has quiet a lot of level. Probably the ray casting is executed mainly on the main memory (some requierement of the algorithm), so the bottleneck could be on the memory access but It is only a supposition.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-29 19:37 GMT+01:00 Мукаев Виктор <span dir="ltr">&lt;<a href="mailto:vitos1g@gmail.com" target="_blank">vitos1g@gmail.com</a>&gt;</span>:<div><div class="h5">
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I heard that 6xx series each cuda core was 3 times less powerfull compare to 5xx series cores. Though they were much better in terms of power consuption, which was main feature of 6xx series(no links, just words, so can&#39;t be sure)  So i think CUDA cores nowadays isn&#39;t right value for measuring performance, ti&#39;s important, but not the main. We should stick to total transistors count per GPU :)<br>


Message: 5<br><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Fri, 28 Mar 2014 23:50:22 +0100<br>
From: GeKo &lt;<a href="mailto:geko.pua@gmail.com" target="_blank">geko.pua@gmail.com</a>&gt;<br>
Subject: Re: [Bf-cycles] Bottleneck of gpu render<br>
To: <a href="mailto:bf-cycles@blender.org" target="_blank">bf-cycles@blender.org</a><br>
Message-ID:<br>
        &lt;<a href="mailto:CAK8Fe3GDNztWkaQoJUGJEO4Kg3vH2cUDCbOYENqQ0Eq9ZDHZ6g@mail.gmail.com" target="_blank">CAK8Fe3GDNztWkaQoJUGJEO4Kg3vH2cUDCbOYENqQ0Eq9ZDHZ6g@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<div><div><br>
<br>
But i really mean about the way that cycles process de model. I dont have<br>
any knowledge about raytracing render, but i am shocked about how the new<br>
hardware know improve so much rhe rendering, even when they have 5 time<br>
more cores.<br>
On 28 Mar 2014 23:11, &quot;Brecht Van Lommel&quot; &lt;<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>&gt;<br>
wrote:<br>
<br>
&gt; There are various possibilities:<br>
&gt;<br>
&gt; * Memory and texture memory read/write bottlenecks<br>
&gt; * Different Mhz for cores<br>
&gt; * Different GPU architecture<br>
&gt; * Not all cores occupied due to divergence or mismatched batch sizes<br>
&gt; * CPU Overhead<br>
&gt;<br>
&gt; There&#39;s too many interacting parts to be sure without closely<br>
&gt; investigating.<br>
&gt;<br>
&gt; Brecht.<br>
&gt;<br>
&gt; On Fri, Mar 28, 2014 at 9:30 PM, GeKo &lt;<a href="mailto:geko.pua@gmail.com" target="_blank">geko.pua@gmail.com</a>&gt; wrote:<br>
&gt; &gt; Short question, Why the execution time don&#39;t decrease &quot;linearly&quot;<br>
&gt; according<br>
&gt; &gt; to the number of cuda cores?<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Bf-cycles mailing list<br>
&gt; &gt; <a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
&gt; &gt; <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt; &gt;<br>
&gt; _______________________________________________<br>
&gt; Bf-cycles mailing list<br>
&gt; <a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
&gt; <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
&gt;<br></div></div>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://lists.blender.org/pipermail/bf-cycles/attachments/20140328/b1414405/attachment-0001.htm" target="_blank">http://lists.blender.org/pipermail/bf-cycles/attachments/20140328/b1414405/attachment-0001.htm</a><br>



</blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">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></blockquote></div></div></div><br></div>
<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>
<br></blockquote></div><br></div>