X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary="2XTGKHSAXJIUARAXDBQHQnhgwp"
MIME-Version: 1.0
User-Agent: GWP-Draft
X-Originator: 78.11.203.93
X-FactoryStamp: H---
Date: Sun, 06 May 2018 10:38:07 +0200
X-Draft-Variant: reply
X-Draft-Parentmailid: b7ab396c2196894e1433ff00
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: <b84c48bc6c46413e809346a1a0baad2c@grupawp.pl>
In-Reply-To: <<alpine.DEB.2.00.1805042003061.19825@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>
X-WP-MailID: 65e0201e76735181c49748e7e488501f
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 0000010 [IVMU]                               
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
Precedence: bulk

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

Hello Evan, Hello Igor,   The PC is lenovo T400 laptop with ATI Radeon HD 7=
350 card (card plugged to advanced dock PCIE x1 slot) + 2 screens. Graphics=
 chip uses CEDAR microcode, and r600 open source X driver.   According to l=
ogs everything related to DRM/DRI2/VDPAU is initialized properly.   Glxgear=
s runs at 60FPS (synced with screen refresh rate) and stays there even when=
 spread on both screens with unnoticeable CPU load - seems right.   Glxinfo=
 says:  direct rendering: Yes  server glx vendor string: SGI  server glx ve=
rsion string: 1.4  Extended renderer info (GLX_MESA_query_renderer):  =C2=
=A0=C2=A0=C2=A0 Vendor: X.Org (0x1002)  =C2=A0=C2=A0=C2=A0 Device: AMD CEDA=
R (DRM 2.49.0 / 4.9.76-gentoo-r1-mw, LLVM 5.0.1) (0x68fa)  =C2=A0=C2=A0=C2=
=A0 Version: 17.3.8  =C2=A0=C2=A0=C2=A0 Accelerated: yes  =C2=A0=C2=A0=C2=
=A0 Video memory: 1024MB  =C2=A0=C2=A0=C2=A0 Unified memory: no  =C2=A0=C2=
=A0=C2=A0 Preferred profile: core (0x1)  =C2=A0=C2=A0=C2=A0 Max core profil=
e version: 3.3  =C2=A0=C2=A0=C2=A0 Max compat profile version: 3.0  =C2=A0=
=C2=A0=C2=A0 Max GLES1 profile version: 1.1  =C2=A0=C2=A0=C2=A0 Max GLES[23=
] profile version: 3.0  OpenGL vendor string: X.Org  OpenGL renderer string=
: AMD CEDAR (DRM 2.49.0 / 4.9.76-gentoo-r1-mw, LLVM 5.0.1)  OpenGL core pro=
file version string: 3.3 (Core Profile) Mesa 17.3.8  OpenGL core profile sh=
ading language version string: 3.30  OpenGL core profile context flags: (no=
ne)  OpenGL core profile profile mask: core profile   In fact I was surpris=
ed that so old PC+graphics can work so well with transparent windows, movie=
s, gschem, FreeCAD or animated waveforms in matplotlib. It was also really =
fast with opengl pcb, it is possible to work with boards spread on both scr=
eens without any noticeable delays in rendering.    In pcb-rnd switching GU=
I to gtk2_gdk makes it a bit slower, but not much (thanks Igor for info abo=
ut GUI, I recompiled pcb-rnd and used --gui gtk2_gl/gdk). Turing grid on/of=
f also makes a difference, but still it takes &gt;10 seconds do move a curs=
or. Turing thin drawing mode ON (polygons thin draw was ON already) speeds =
it up drastically, but still it is slower then opengl version (without thin=
 draw). Now moving cursor takes ~1s or a bit more. I also noticed that the =
speed drops &#34;exponentially&#34; as the complexity of the board increase=
s, but it seems that this is the case with all pcb versions (for mainline o=
r opengl I don&#39;t have complex enough board to test it further).    I al=
so tried these tests on lenovo T400 with internal i965 graphics card and in=
tegrated screen - very similar results. The laptop is configured as before,=
 only graphics drivers are different. If You need some more info or want th=
e board I used for tests then please let me know.  Best Regards,  Michael W=
idlok    Dnia 4 maja 2018 20:27 michalwd1979 &lt;  gedau AT igor2 DOT repo DOT hu &gt;=
 napisa=C5=82(a):  Hello Michael,   On Fri, 4 May 2018, michalwd1979 (  mic=
halwd1979 AT o2 DOT pl ) [via   geda-user AT delorie DOT com ] wrote:   Hello Igor,   Tha=
nks for reply. The features of pcb-rnd are impressive and I really like  th=
e fast development of the branch. I remember back then when we talked  abou=
t opengl and I&#39;ve tried to merge some of the rendering code but my  pro=
gramming skills were good not enough, sorry... =C2=A0   I am not sure if th=
e problem is my &gt;10 years old PC, my hardly tuned gentoo,  wrong compile=
 options or just a bad luck, but I always had speed problems  with anything=
 but Peter&#39;s opengl branch (recently mainline pcb become  similar in re=
ndering speed). Today I&#39;ve tried fresh compiled pcb-rnd 1.2.8  with def=
ault:  ./configure --prefix=3D/usr/local --buildin-hid_gtk2_gl --disable-hi=
d_gtk2_gdk  make   Loading more complicated 4 layers board to pcb-rnd makes=
 working on it  impossible. Moving cursor takes about 15s with cpu load at =
100%, zooming  in/out is even slower. I know that my equipment is nothing c=
ompared to  current (even low-end) machines, but still - the same board in =
mainline or  opengl pcb moves/zooms in almost no time.  If You want me to p=
erform more test with different configure options or want  more data about =
rest of the system, then let me know. Maybe I have something  very wrong he=
re.    Thanks for reporting.   I think there can be two kind of reasons beh=
ind this:   1. opengl related issue; Ade, our opengl expert, will contact y=
ou about  this. Evan could help with gentoo, it might be some gentoo+opengl=
  installation problem.   2. non-opengl related; a few things you could try=
:   - turn off visible grid (drawing the dots may be slow if your window is=
  large)   - turn on thin drawing mode (to see if the problem is related to=
 polygon  rendering)   - please check how it works with software render (gd=
k); Note: with  pcb-rnd, you do not need to disable HIDs, you can let it de=
tect and  compile all HIDs it finds, as you can select your hid runtime. (Y=
ou can  even configure your HID preference: which HIDs should be tried in w=
hich  order if you didn&#39;t explicitly specify a HID to run).    Best reg=
ards,   Igor2=0D

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

Hello Evan, Hello Igor,<br><br>The PC is lenovo T400 laptop with ATI Radeon=
 HD 7350 card (card plugged to advanced dock PCIE x1 slot) + 2 screens. Gra=
phics chip uses CEDAR microcode, and r600 open source X driver. <br>Accordi=
ng to logs everything related to DRM/DRI2/VDPAU is initialized properly. <b=
r>Glxgears runs at 60FPS (synced with screen refresh rate) and stays there =
even when spread on both screens with unnoticeable CPU load - seems right.<=
br><br>Glxinfo says:<br><div>direct rendering: Yes<br></div><div>server glx=
 vendor string: SGI<br></div><div>server glx version string: 1.4<br></div><=
div>Extended renderer info (GLX_MESA_query_renderer):<br></div><div>&nbsp;&=
nbsp;&nbsp; Vendor: X.Org (0x1002)<br></div><div>&nbsp;&nbsp;&nbsp; Device:=
 AMD CEDAR (DRM 2.49.0 / 4.9.76-gentoo-r1-mw, LLVM 5.0.1) (0x68fa)<br></div=
><div>&nbsp;&nbsp;&nbsp; Version: 17.3.8<br></div><div>&nbsp;&nbsp;&nbsp; A=
ccelerated: yes<br></div><div>&nbsp;&nbsp;&nbsp; Video memory: 1024MB<br></=
div><div>&nbsp;&nbsp;&nbsp; Unified memory: no<br></div><div>&nbsp;&nbsp;&n=
bsp; Preferred profile: core (0x1)<br></div><div>&nbsp;&nbsp;&nbsp; Max cor=
e profile version: 3.3<br></div><div>&nbsp;&nbsp;&nbsp; Max compat profile =
version: 3.0<br></div><div>&nbsp;&nbsp;&nbsp; Max GLES1 profile version: 1.=
1<br></div><div>&nbsp;&nbsp;&nbsp; Max GLES[23] profile version: 3.0<br></d=
iv><div>OpenGL vendor string: X.Org<br></div><div>OpenGL renderer string: A=
MD CEDAR (DRM 2.49.0 / 4.9.76-gentoo-r1-mw, LLVM 5.0.1)<br></div><div>OpenG=
L core profile version string: 3.3 (Core Profile) Mesa 17.3.8<br></div><div=
>OpenGL core profile shading language version string: 3.30<br></div><div>Op=
enGL core profile context flags: (none)<br></div><div>OpenGL core profile p=
rofile mask: core profile<br></div><div><br></div><div>In fact I was surpri=
sed that so old PC+graphics can work so well with transparent windows, movi=
es, gschem, FreeCAD or animated waveforms in matplotlib. It was also really=
 fast with opengl pcb, it is possible to work with boards spread on both sc=
reens without any noticeable delays in rendering. <br></div><div><br></div>=
<div>In pcb-rnd switching GUI to gtk2_gdk makes it a bit slower, but not mu=
ch (thanks Igor for info about GUI, I recompiled pcb-rnd and used --gui gtk=
2_gl/gdk). Turing grid on/off also makes a difference, but still it takes &=
gt;10 seconds do move a cursor. Turing thin drawing mode ON (polygons thin =
draw was ON already) speeds it up drastically, but still it is slower then =
opengl version (without thin draw). Now moving cursor takes ~1s or a bit mo=
re. I also noticed that the speed drops "exponentially" as the complexity o=
f the board increases, but it seems that this is the case with all pcb vers=
ions (for mainline or opengl I don't have complex enough board to test it f=
urther). <br></div><div><br></div><div>I also tried these tests on lenovo T=
400 with internal i965 graphics card and integrated screen - very similar r=
esults. The laptop is configured as before, only graphics drivers are diffe=
rent. If You need some more info or want the board I used for tests then pl=
ease let me know.<br></div><div>Best Regards,<br></div><div>Michael Widlok<=
br></div><div><br></div><div><br></div><div class=3D"nh_extra"><p>Dnia 4 ma=
ja 2018 20:27 michalwd1979 &lt;<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu">gedau=
@igor2.repo.hu</a>&gt; napisa=C5=82(a):<br></p><blockquote class=3D"nh_quot=
e" style=3D"border-left: 2px solid #999; padding-left: 8px; margin: 0;"><di=
v id=3D"gwpe5321eea"><div>Hello Michael,<br></div><div><br></div><div>On Fr=
i, 4 May 2018, michalwd1979 (<a href=3D"mailto:michalwd1979 AT o2 DOT pl">michalwd=
1979 AT o2 DOT pl</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT del=
orie.com</a>] wrote:<br></div><div><br></div><blockquote is-minimized=3D"">=
<div>Hello Igor,<br></div><div><br></div><div>Thanks for reply. The feature=
s of pcb-rnd are impressive and I really like<br></div><div>the fast develo=
pment of the branch. I remember back then when we talked<br></div><div>abou=
t opengl and I've tried to merge some of the rendering code but my<br></div=
><div>programming skills were good not enough, sorry... &nbsp;<br></div><di=
v><br></div><div>I am not sure if the problem is my &gt;10 years old PC, my=
 hardly tuned gentoo,<br></div><div>wrong compile options or just a bad luc=
k, but I always had speed problems<br></div><div>with anything but Peter's =
opengl branch (recently mainline pcb become<br></div><div>similar in render=
ing speed). Today I've tried fresh compiled pcb-rnd 1.2.8<br></div><div>wit=
h default:<br></div><div>./configure --prefix=3D/usr/local --buildin-hid_gt=
k2_gl --disable-hid_gtk2_gdk<br></div><div>make<br></div><div><br></div><di=
v>Loading more complicated 4 layers board to pcb-rnd makes working on it<br=
></div><div>impossible. Moving cursor takes about 15s with cpu load at 100%=
, zooming<br></div><div>in/out is even slower. I know that my equipment is =
nothing compared to<br></div><div>current (even low-end) machines, but stil=
l - the same board in mainline or<br></div><div>opengl pcb moves/zooms in a=
lmost no time.<br></div><div>If You want me to perform more test with diffe=
rent configure options or want<br></div><div>more data about rest of the sy=
stem, then let me know. Maybe I have something<br></div><div>very wrong her=
e.<br></div><div><br></div></blockquote><div><br></div><div>Thanks for repo=
rting.<br></div><div><br></div><div>I think there can be two kind of reason=
s behind this:<br></div><div><br></div><div>1. opengl related issue; Ade, o=
ur opengl expert, will contact you about<br></div><div>this. Evan could hel=
p with gentoo, it might be some gentoo+opengl<br></div><div>installation pr=
oblem.<br></div><div><br></div><div>2. non-opengl related; a few things you=
 could try:<br></div><div><br></div><div>- turn off visible grid (drawing t=
he dots may be slow if your window is<br></div><div>large)<br></div><div><b=
r></div><div>- turn on thin drawing mode (to see if the problem is related =
to polygon<br></div><div>rendering)<br></div><div><br></div><div>- please c=
heck how it works with software render (gdk); Note: with<br></div><div>pcb-=
rnd, you do not need to disable HIDs, you can let it detect and<br></div><d=
iv>compile all HIDs it finds, as you can select your hid runtime. (You can<=
br></div><div>even configure your HID preference: which HIDs should be trie=
d in which<br></div><div>order if you didn't explicitly specify a HID to ru=
n).<br></div><div><br></div><div><br></div><div>Best regards,<br></div><div=
><br></div><div>Igor2<br></div></div></blockquote></div><div><br></div>
--2XTGKHSAXJIUARAXDBQHQnhgwp--