delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2018/05/08/03:36:50

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
MIME-Version: 1.0
User-Agent: GWP-Draft
X-Originator: 78.11.203.93
X-FactoryStamp: H---
Date: Tue, 08 May 2018 09:35:10 +0200
X-Draft-Variant: reply
X-Draft-Parentmailid: 33c880d0ed835098af781371
X-Draft-Contenttype: text/html
Subject: =?UTF-8?Q?Re=3A_Odp=3A_Re=3A_=5Bgeda-user=5D_Opengl_PCB_and_mainline_PCB_-_pcb-rnd_aspects?=
From: "michalwd1979 (michalwd1979 AT o2 DOT pl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: =?UTF-8?Q?geda-user=40delorie=2Ecom?= <geda-user AT delorie DOT com>
Message-ID: <cac61ceaf8b24ceba0af8b0be3ab56d3@grupawp.pl>
In-Reply-To: <<alpine.DEB.2.00.1805080424590.8169@igor2priv>>
References: <ca+qhd=-z1tvzehozmmi+8eduqnwmaeeeodg=uk3p6mb9tj57dq AT mail DOT gmail DOT com> <647dca2ad89a4415ad980da6e5cdc701 AT grupawp DOT pl> <cajzxidbrzvoaivzxdhdcehdmubu-a5c8ueaeud6q-r0prvibya AT mail DOT gmail DOT com> <d44c1d9475c440a09121d3247c43b1d1 AT grupawp DOT pl> <alpine DOT deb DOT 2 DOT 00 DOT 1804301857010 DOT 19825 AT igor2priv> <7da892c189bd49838d6ce6eb2c2628e4 AT grupawp DOT pl> <alpine DOT deb DOT 2 DOT 00 DOT 1805042003061 DOT 19825 AT igor2priv> <b84c48bc6c46413e809346a1a0baad2c AT grupawp DOT pl> <cam2rghspcci+g9vxjvtjwtilbj9ebegskaz8spcn=l5jz-zqtg AT mail DOT gmail DOT com> <7e30777e38284644814271a68f2c2119 AT grupawp DOT pl> <alpine DOT DEB DOT 2 DOT 00 DOT 1805080424590 DOT 8169 AT igor2priv>
X-WP-MailID: 2568d5780e7196862760cf2002ae628d
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 0000010 [MQP0]
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

--2KPJUYRELGREHTBQUEREVnhgwp
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Hello Igor,   Dnia 8 maja 2018 04:48 michalwd1979 &lt;gedau AT igor2 DOT repo DOT hu&g=
t; napisa=C5=82(a):  2. load the single layer version (4096.lht); do not zo=
om or pan, leave it  as it is after load, and run benchmark() a few times -=
 we need to average  the value of multiple runs, they show some variation h=
ere (I got values  between 50.5 and 53.9 for this file)   For me it is betw=
een 23.5 and 21.5, averaging at ~22.6. What is interesting, running benchma=
rk on this file does not cause 100% load on cpu, what suggest that the limi=
ting factor is GPU or GPU bus speed. Here I have PCIE x1 socket so it might=
 be the case.     3. within the same pcb-rnd session, please load the multi=
-layer version  (4096_lay.lht), again leave it as it is and run benchmark()=
 a few times (I  got values (I got values between 49.5 and 54)   Here it is=
 from 21.5 to 22.7 with 22.1 average. Very similar to single layer version.=
=C2=A0     This tests one specific rendering feature of pcb-rnd that is dif=
ferent  compared to geda/pcb&#39;s gl rendering. If we get about the same v=
alues, we  know it&#39;s not our &#34;new&#34; layer compositing code. If w=
e see the multi-layer  version being much slower, we know we need to implem=
ent the same  optimization in the gl HID that we have in the software rende=
r HIDs.   One more notice: With my board loaded even moving a cursor causes=
 instant 100% cpu load for a few seconds, with benchmark() it is the same. =
Mainline or opengl pcb never causes high cpu usage even with furious pannin=
g or rotating. While sometimes the movement is not super smooth, GUI is alw=
ays very responsive. This is not the case with pcb-rnd, here I have to wait=
 for a menu to open after for example cursor movement. Also turning ON/OFF =
&#34;subcircuits&#34; layer makes a huge difference - maybe we are looking =
in the wrong place??  Best Regards,  Michael Widlok=0D

--2KPJUYRELGREHTBQUEREVnhgwp
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<div>Hello Igor, <br></div><div class=3D"nh_extra"><p>Dnia 8 maja 2018 04:4=
8 michalwd1979 &lt;gedau AT igor2 DOT repo DOT hu&gt; napisa=C5=82(a):<br></p><blockqu=
ote class=3D"nh_quote" style=3D"border-left: 2px solid #999; padding-left: =
8px; margin: 0;"><div id=3D"gwp59fd49e5"><div>2. load the single layer vers=
ion (4096.lht); do not zoom or pan, leave it<br></div><div>as it is after l=
oad, and run benchmark() a few times - we need to average<br></div><div>the=
 value of multiple runs, they show some variation here (I got values<br></d=
iv><div>between 50.5 and 53.9 for this file)<br></div></div></blockquote></=
div><div><br></div><div>For me it is between 23.5 and 21.5, averaging at ~2=
2.6. What is interesting, running benchmark on this file does not cause 100=
% load on cpu, what suggest that the limiting factor is GPU or GPU bus spee=
d. Here I have PCIE x1 socket so it might be the case. <br></div><div><br><=
/div><div class=3D"nh_extra"><blockquote class=3D"nh_quote" style=3D"border=
-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id=3D"gwp59fd49e=
5"><div><br></div><div>3. within the same pcb-rnd session, please load the =
multi-layer version<br></div><div>(4096_lay.lht), again leave it as it is a=
nd run benchmark() a few times (I<br></div><div>got values (I got values be=
tween 49.5 and 54)<br></div></div></blockquote></div><div><br></div><div>He=
re it is from 21.5 to 22.7 with 22.1 average. Very similar to single layer =
version.&nbsp; <br></div><div><br></div><div class=3D"nh_extra"><blockquote=
 class=3D"nh_quote" style=3D"border-left: 2px solid #999; padding-left: 8px=
; margin: 0;"><div id=3D"gwp59fd49e5"><div><br></div><div>This tests one sp=
ecific rendering feature of pcb-rnd that is different<br></div><div>compare=
d to geda/pcb's gl rendering. If we get about the same values, we<br></div>=
<div>know it's not our "new" layer compositing code. If we see the multi-la=
yer<br></div><div>version being much slower, we know we need to implement t=
he same<br></div><div>optimization in the gl HID that we have in the softwa=
re render HIDs.<br></div></div></blockquote></div><div><br></div><div>One m=
ore notice: With my board loaded even moving a cursor causes instant 100% c=
pu load for a few seconds, with benchmark() it is the same. Mainline or ope=
ngl pcb never causes high cpu usage even with furious panning or rotating. =
While sometimes the movement is not super smooth, GUI is always very respon=
sive. This is not the case with pcb-rnd, here I have to wait for a menu to =
open after for example cursor movement. Also turning ON/OFF "subcircuits" l=
ayer makes a huge difference - maybe we are looking in the wrong place??<br=
></div><div>Best Regards,<br></div><div>Michael Widlok<br></div><div><br></=
div>
--2KPJUYRELGREHTBQUEREVnhgwp--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019