Mail Archives: geda-user/2018/05/06/04:40:05
--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 >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 "exponentially" 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'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 < gedau AT igor2 DOT repo DOT hu >=
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'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 >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's opengl branch (recently mainline pcb become similar in re=
ndering speed). Today I'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'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; Vendor: X.Org (0x1002)<br></div><div> Device:=
AMD CEDAR (DRM 2.49.0 / 4.9.76-gentoo-r1-mw, LLVM 5.0.1) (0x68fa)<br></div=
><div> Version: 17.3.8<br></div><div> A=
ccelerated: yes<br></div><div> Video memory: 1024MB<br></=
div><div> Unified memory: no<br></div><div> &n=
bsp; Preferred profile: core (0x1)<br></div><div> Max cor=
e profile version: 3.3<br></div><div> Max compat profile =
version: 3.0<br></div><div> Max GLES1 profile version: 1.=
1<br></div><div> 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 <<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu">gedau=
@igor2.repo.hu</a>> 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... <br></div><di=
v><br></div><div>I am not sure if the problem is my >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--
- Raw text -