<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000099" bgcolor="#ffffff">
<div class="moz-cite-prefix"><font size="-1"><font face="Arial"><b>Speed
test results:</b><br>
Found forgot to save the 'Speed Test' blend file on the
Desktop PC with twin GTX 580, so just carried out all tests
again.<br>
<big><b><br>
</b><b><i>Pre Optimization Results:</i><br>
<br>
</b></big><b></b><b>Border render small square top right of
viewport complex scene:</b><br>
2 GTX 580 (20.69 seconds), GTX 580m (29.03 seconds)<br>
<br>
<b>Same border region moved to bottom left of viewport:</b><br>
2 GTX 580 (3.94 seconds), GTX 580m (15.05 seconds)<br>
<br>
**************************************************************************<br>
<i><big><b>Post Optimization Results:</b></big></i><br>
<b><br>
Border render small square top right of viewport complex
scene:</b><br>
2 GTX 580 (2.93 seconds), GTX 580m (12.28 seconds)<br>
<b><br>
</b><b>Same border region moved to bottom left of viewport:</b><br>
2 GTX 580 (2.95 seconds), GTX 580m (12.37 seconds)<br>
<br>
Think it is safe to say the results speak for themselves!<br>
<br>
Only one area you may want to take a quick look at, not
important, purely esthetical. Notice there is a 1 pixel gap
above the viewport render status bar (not noticeable when it
was semi-transparent), not sure if this is deliberate?<br>
<br>
Now the status bar is opaque due to optimized OpenGL draw
routines, would a slightly lighter shade of grey help blend
with the rest of the interface, guess a darker shade was
chosen due to its previous semi-transparency nature.
Alternatively, if use the region overlap T and N panels draw
routine, I notice when they are visible it has a small impact
on new border render performance, about 1 second slower.
Personally, speed is preferable to appearance and do not mind
an opaque bar.<br>
<br>
Thank you again.<br>
<br>
David</font></font><br>
<div class="moz-signature">--
<p style="font-size:small;"><a
href="http://www.3d-designs-davidblack.blogspot.com">3d-designs-davidblack.blogspot.com</a></p>
</div>
On 14/04/2013 22:54, David Black wrote:<br>
</div>
<blockquote cite="mid:516B2589.8090004@yahoo.co.uk" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><font size="-1"><font face="Arial">Wow
that was quick!! Thank you!<br>
<br>
Your solution sounds fantastic, asked about wireframe not
knowing you would be able to update just the render region.
With your method I can imagine at least a 400% speed
increase on the scene I tried.<font size="-1"> Understand
Open<font size="-1">GL will need to update the viewport <font
size="-1">when other changes are made.</font></font></font><br>
<br>
</font></font><font size="-1"><font face="Arial"><font
size="-1"><font face="Arial"><font size="-1">Greatly
looking forward to testing <font size="-1">commit</font>,
will provide a <font size="-1">GPU </font>speed <font
size="-1">comparison.</font><br>
<br>
</font></font></font>Thank you for your replies (Light
leaks plus this topic).<br>
<br>
David</font></font><br>
<div class="moz-signature">--
<p style="font-size:small;"><a moz-do-not-send="true"
href="http://www.3d-designs-davidblack.blogspot.com">3d-designs-davidblack.blogspot.com</a></p>
</div>
On 14/04/2013 22:42, Brecht Van Lommel wrote:<br>
</div>
<blockquote
cite="mid:CAKFUgC3fJmNCbk=TtbdhFh-txBP4EY_u-UkXrcEHVGcN-z9EtA@mail.gmail.com"
type="cite">
<pre wrap="">I've implemented this optimization and committed it to svn, the OpenGL
object drawing is skipped now while the render is refining. I didn't
benchmark it with GPU render yet, just tested on the CPU.
It still redraws the OpenGL objects while you're editing material and
render settings though, so it's probably not quite as fast as having
no border render. But there's no way around that really, until we have
a smarter system to detect which edited properties require a 3d view
redraw and which don't.
Brecht.
On Sun, Apr 14, 2013 at 10:01 PM, Brecht Van Lommel
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:brechtvanlommel@pandora.be"><brechtvanlommel@pandora.be></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I'm not sure drawing with wireframes is the right solution, this can
still be slow. Probably it's possible to only redraw the area inside
the render border and leave the area outside unchanged, which would be
even faster. I'll look into it, we already do partial redraws for
sculpt mode so it should be possible.
Brecht.
On Sun, Apr 14, 2013 at 7:08 PM, David Black <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:db4tech@yahoo.co.uk"><db4tech@yahoo.co.uk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Brecht,
Possible Faster Viewport Border Rendering Complex Scenes:
Nothing to do with my previously mentioned half resolution option for faster
Viewport rendering.
There may be a way to speed up viewport border rendering for complex scenes.
While preforming some tests, I noticed on complex scenes, where only a small
area of the viewport is selected for border rendering, there is a huge
render speed difference dependent on what is displayed in the rest of the
viewport presently not being rendered. Tested in camera view with 2 GTX
580’s and on a Laptop with a GTX580m.
Test Method:
Selected a small region (top right) of the viewport for border rendering on
a complex scene, moved the same region around different parts of the
viewport and noticed a huge render speed up when complex areas of the scene
not presently being rendered are moved outside of the viewport view.
It seems solid OpenGL drawing the rest of a complex scene while border
region is rendering is the culprit, could having the rest of the scene draw
in wireframe mode only, instead of solid, outside of the border render
region provide a faster viewport border render for everyone?
Results:
Border render small square top right of viewport complex scene:
2 GTX 580 16 seconds, GTX 580m 32 seconds
Same border region moved to bottom left of viewport:
2 GTX 580 5 seconds, GTX 580m 14 seconds
Thank you for your time,
David
--
3d-designs-davidblack.blogspot.com
_______________________________________________
Bf-cycles mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</body>
</html>