Back
[13:27:12] <CIA-2> EMC: 03jepler 07v2.4_branch * rb8d45acd5fdd 10/src/emc/usr_intf/stepconf/stepconf.py: Fix period, maxvel calculations in axis test
[14:21:57] <micges_work1> hi all
[14:22:15] <micges_work1> anone saw something like this?:
http://www.pastebin.ca/1830014
[14:43:23] <jepler> looks like debian has a bug about the i915 message. I assume that's what you're asking about?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467319
[14:45:04] <micges_work1> yes
[14:45:21] <micges_work1> another bug in mesa that hangs emc :/
[14:45:43] <SWPadnos> it's probably not in the mesa driver
[14:46:11] <SWPadnos> though it could be something weird with the way the PCI bridge is being used
[14:46:58] <jepler> there is "mesa" the implementation of OpenGL and "mesa" the interface card.
[14:47:09] <SWPadnos> heh, true enough
[14:47:18] <SWPadnos> time for more coffee
[14:47:45] <jepler> micges_work1: is that 8.04?
[14:47:50] <micges_work1> on that pc there are many other bug of mesa opengl
[14:48:01] <micges_work1> yes
[14:48:31] <jepler> looks like ubuntu hasn't packaged the version of libgl1-mesa-dri that fixed 467319
[14:48:34] <jepler> for 8.04
[14:48:54] <jepler> you could always do whatever it is to turn off direct rendering / hardware opengl and accept the performance hit
[14:50:16] <cradek> install libgl1-mesa-swx11
[14:50:25] <micges_work1> heh can't do that, with hw acceleration there is 0,7 fps in Axis preview on our programs :)
[14:51:02] <jepler> it seems this is the change that fixes it:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_0_branch&id=709f24adbb21419881f0d857c8454814f85c2757
[14:51:45] <cradek> wow those must be big programs
[14:52:10] <micges_work1> yes they are
[14:52:18] <micges_work1> 30-40h of work
[14:52:20] <jepler> you should run smaller programs instead
[14:52:25] <skunkworks_> heh
[14:54:10] <micges_work1> jepler: thanks for links
[14:54:12] <micges_work1> bbl
[14:54:24] <jepler> * jepler is the king of google
[15:22:14] <seb_kuzminsky> * seb_kuzminsky is glad it's that *other* mesa that's at fault this time
[15:22:37] <SWPadnos> I hear there's another HAL too :)
[15:23:02] <seb_kuzminsky> naming a hardware abstraction layer "HAL" is like naming a library "LIB"
[15:23:44] <SWPadnos> heh
[15:26:47] <seb_kuzminsky> bbl
[15:31:01] <skunkworks_> jmkasunich: package recieved! thanks again.
[15:31:22] <cradek> he must like you better
[15:31:29] <skunkworks_> I am closer
[15:31:30] <skunkworks_> ;)
[15:31:37] <cradek> true
[15:31:39] <jepler> skunkworks_: what's for christmas?
[15:31:54] <skunkworks_> bunch of opto22 modules
[15:34:14] <aystarik> jepler, I've just posted a patch to somewhat optimize code loading into AXIS, could you please review it?
[15:39:07] <jepler> your editor changed a bunch of whitespace. Trailing whitespace is bad, but removing it AND changing other things in the same commit makes it much harder to review the functional changes.
[15:39:45] <jepler> likewise getting rid of these very old emc1-compatiblity defines should be a separate commit; I don't think it has any effect on loading speed
[15:39:48] <jepler> -#define active_settings interp_new.active_settings
[15:39:50] <jepler> - interp_new.error_text(err, savedError, LINELEN);
[15:39:50] <jepler> + interp.error_text(err, savedError, LINELEN);
[15:40:10] <jepler> this is also a different matter, should be a different commit:
[15:40:11] <jepler> - STRAIGHT_FEED(12345, P1.X,P1.Y, _pos_z, _pos_a, _pos_b, _pos_c, _pos_u, _pos_v, _pos_w);
[15:40:14] <jepler> + STRAIGHT_FEED(line_number, P1.X,P1.Y, _pos_z, _pos_a, _pos_b, _pos_c, _pos_u, _pos_v, _pos_w);
[15:40:16] <aystarik> I can create a series if you like
[15:40:52] <cradek> looks like some changes at the end are just whitespace? that might be a mistake your editor made.
[15:41:02] <jepler> so let me see if I understand the actual changes that are increasing performance. first, you avoid doing extra math when there is no rotation. second, you decrease the number of "next_line" calls.
[15:41:37] <cradek> for the former it sure seems possible that would speed it up some
[15:41:38] <aystarik> no, number of calls to next_line is the same,
[15:42:11] <aystarik> I just do not allocate stats object if line did not change
[15:42:30] <jepler> ah
[15:42:54] <jepler> I see that now
[15:43:24] <jepler> any performance measurements?
[15:43:48] <aystarik> no, still did not figure out how to do that in python
[15:44:24] <jepler> one very simple but inaccurate way is: time axis-remote --reload
[15:44:50] <aystarik> nurbs line select started to work though
[15:46:34] <aystarik> aystarik@thinkpad:~/cnc/emc/emc2-dev$ time axis-remote --reload
[15:46:34] <aystarik> X server insecure (must use xauth-style authorization); command ignored
[15:46:46] <aystarik> did not work, I guess
[15:46:48] <jepler> oh, you have a broken ubuntu. maybe they'll fix that bug in the next 4 years sometime.
[15:48:33] <jepler> this is odd behavior. Loading a part program with about 40000 G1 moves over multiple trials gave the following timings: 28s; 16s; 12s; 10s; 9s; 9s; 9s; 10s; 9s
[15:48:38] <jepler> I wonder why the first loads were slower
[15:50:49] <cradek> I recommend testing rotation if you mess with it... load up systems.ngc, offset and rotate some of the systems, run to see if the preview matches.
[15:56:38] <jepler> my version of aystarik's changes take a second off the load time of this file, 9s to 8s
[15:58:01] <jepler> overhead is about 1.6s
[15:58:05] <aystarik> ~10% -- noticable
[15:59:10] <aystarik> re: first time vs. second time -- may be python optimizes code paths?
[16:01:00] <jepler> here's what I did timings with:
http://emergent.unpy.net/files/sandbox/my-version-of-aystarik-speedups.mbox
[16:03:18] <aystarik> jepler, you did not change maybe_new_line(void) to call interp.line()
[16:03:52] <cradek> also if you change anything with line numbers, make sure click-select still works right with a program using cutter comp
[16:09:00] <jepler> bbiab
[17:51:48] <aystarik> sent the patch as a series of independent changes.
[20:02:50] <jepler> hm, I bet the axis preview is wrong when you use cutter comp and set the tool radius using G10
[20:03:42] <CIA-2> EMC: 03jepler 07v2.4_branch * r0de098a4d455 10/src/emc/usr_intf/axis/scripts/axis.py: fix a memory leak
[20:07:45] <aystarik> guys, NURBS does not work in master?
[20:08:03] <aystarik> butterfly.ngc does not run...
[20:09:39] <cradek> last I tried, it sort of worked
[20:09:58] <cradek> but yeah, it's sure not right
[20:10:15] <aystarik> now it stops at F600
[20:10:31] <cradek> mostly we put the code in so we wouldn't lose it - in case someone wanted to work on finishing it. In hindsight I'm not sure if that was a good idea or not.
[20:30:33] <jepler> phew. I just about panicked there. I was trying to run 2.4, but sim/axis wouldn't go to "machine on". I eventually found that I had two TRUNK milltasks still running under valgrind; dunno exactly how I got in that state, but it sure made emc unhappy.
[20:32:14] <jepler> incidentally, butterfly.ngc at the tip of v2.4_branch gives me similar behavior: it gets stuck showing line 6 (G1 Z-5 F100) as the current line, but having moved a small distance on the curve from G5.x
[20:33:02] <jepler> it did work less poorly than this at some point, but I don't recall when...
[20:46:54] <aystarik> jepler, do you like series I've sent?
[21:00:25] <jepler> Auto-merging src/emc/usr_intf/stepconf/stepconf.py
[21:00:25] <jepler> Resolved 'src/emc/usr_intf/axis/scripts/axis.py' using previous resolution.
[21:00:28] <jepler> ooh, that's cool
[21:04:18] <CIA-2> EMC: 03jepler 07master * rff4f97372f11 10/src/po/fr.po: French translation update
[21:04:19] <CIA-2> EMC: 03jepler 07master * rb8d45acd5fdd 10/src/emc/usr_intf/stepconf/stepconf.py: Fix period, maxvel calculations in axis test
[21:04:20] <CIA-2> EMC: 03jepler 07master * r1e3c57753a29 10/src/emc/rs274ngc/gcodemodule.cc: avoid unneeded work when sequence_number is unchanged
[21:04:21] <CIA-2> EMC: 03jepler 07master * rdd20c323367b 10/lib/python/rs274/interpret.py: avoid extra work when there's no rotation
[21:04:22] <CIA-2> EMC: 03jepler 07master * rf28154ab0686 10/src/emc/rs274ngc/gcodemodule.cc: simplify maybe_new_line with default argument
[21:04:23] <CIA-2> EMC: 03jepler 07master * re7de306526bb 10/src/emc/rs274ngc/gcodemodule.cc: get rid of some emc1-compatibility defines
[21:04:24] <CIA-2> EMC: 03jepler 07master * r75ce038f1f11 10/src/emc/rs274ngc/gcodemodule.cc: get rid of unused variable
[21:04:25] <CIA-2> EMC: 03jepler 07master * rf80f1c2f6882 10/src/emc/rs274ngc/gcodemodule.cc: get rid of unneeded declarations
[21:04:29] <CIA-2> EMC: 03jepler 07master * r898a1e15127c 10/src/emc/rs274ngc/gcodemodule.cc: add static qualifiers where appropriate
[21:04:30] <CIA-2> EMC: 03jepler 07master * r0de098a4d455 10/src/emc/usr_intf/axis/scripts/axis.py: fix a memory leak
[21:04:31] <CIA-2> EMC: 03jepler 07master * r9cad9886b6e0 10/src/emc/usr_intf/axis/scripts/axis.py: fix a memory leak
[21:04:31] <CIA-2> EMC: 03jepler 07master * rcab34489d40f 10/src/emc/usr_intf/stepconf/stepconf.py: Merge remote branch 'origin/v2.4_branch'
[21:06:52] <jepler> aystarik: yes, I like the idea of the speed up patches. I didn't look at all the other things in that file you attached to your message.
[21:07:30] <aystarik> that's fine. thanks!