| 02:20.09 | Maloeran | And the truck is even worse, Erik. It's filled with cracks, and the overlapping triangles are visible as we of course can't use the triangle orientation |
| 02:20.39 | Maloeran | Must I get this to work with the truck or is there hope of getting proper geometry? |
| 02:21.37 | *** join/#brlcad dtidrow (n=dtidrow@69.255.182.248) |
| 02:44.21 | ``Erik | hehehe |
| 02:44.29 | ``Erik | did I just view the fixed image? |
| 02:44.35 | ``Erik | <-- curious what the unfixed image looks like |
| 02:45.54 | Maloeran | Probably the fixed one, yes :) |
| 02:46.09 | Maloeran | The other one was such a mess, but I didn't spot the error immediately |
| 02:47.51 | Maloeran | Or http://www.rayforce.net/blend01.png for the engine. I need to raise the eye-candy factor a bit |
| 02:48.31 | ``Erik | oh neat, they even modelled the throttle body ports |
| 02:48.56 | Maloeran | Yes, I'm discovering new parts of this truck with transparency |
| 02:51.36 | Maloeran | Transparency makes rays go through these many inner sectors with > 100 triangles, kind of slow |
| 02:52.04 | ``Erik | yeah, but that's a needed capability for the practical application |
| 02:52.26 | Maloeran | Of course. In fact, I'm more complaining about the model than the capability |
| 02:53.01 | ``Erik | <-- thinks that model is probably pretty representative of the common data set... |
| 02:53.04 | ``Erik | 'cept a bunch smaller |
| 02:53.04 | ``Erik | heh |
| 02:53.40 | Maloeran | There are non-axis aligned tiny tubes made of ~500 long thin triangles everywhere in the engine |
| 02:54.00 | Maloeran | So tiny, yet so much geometry. In comparison, the haul/frame is all chunky |
| 02:54.13 | ``Erik | hm, tesselation of the pipe segments? |
| 02:54.42 | Maloeran | Yes, and these tubes have inner geometry, some kind of weird inner bolts... or narrowing passages |
| 02:56.45 | ``Erik | 'inner bolts'? hrmmm, you dispose of a good amount of data in your format |
| 02:57.07 | ``Erik | some of those should be hollow (filled with air, actually, which I don't know if you carried out) |
| 02:57.25 | ``Erik | and some of those should be filled with metal or fluids |
| 02:57.34 | ``Erik | (wires and hydraulic lines) |
| 02:57.49 | Maloeran | I see. Yes, these little tubes are amazingly detailled |
| 02:58.59 | ``Erik | intersection with those also feed into other algorithms with great effect *shrug* so they matter :) |
| 02:59.07 | Maloeran | So basically, these innocent looking tubes hurt performance badly at the moment |
| 02:59.13 | Maloeran | Right :) |
| 02:59.33 | Maloeran | I'm not really complaining as long as we compare with ADRT on the same data set |
| 02:59.50 | ``Erik | yeah, I need to get to that, heh |
| 03:00.56 | Maloeran | No rush, so many optimisations and ideas left to explore.. |
| 03:24.40 | brlcad | ah, i bet they're pipes .. which are actually hollow tubes .. so you're probably seeing the outer cylinder and the inner one twisting through paths |
| 03:24.57 | brlcad | in fact, in the image you show.. those are indeed pipes |
| 03:25.57 | brlcad | in implicit form, that's just one extra radius to store for the entire path, so the extra detail comes practically for free |
| 03:26.31 | dtidrow | brlcad: was MJ in today? |
| 03:26.49 | brlcad | dtidrow: I don't know, I wasn't |
| 03:27.07 | brlcad | and I don't see MJ daily.. usually only once a month |
| 03:27.07 | dtidrow | tried calling, but she must have been out at the time |
| 03:27.16 | dtidrow | I'll send her an email |
| 04:05.45 | *** join/#brlcad dtidrow (n=dtidrow@69.255.182.248) |
| 05:24.17 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 05:36.03 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 06:11.52 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 06:43.49 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 07:04.26 | *** join/#brlcad clock_ (i=clock@84-72-62-211.dclient.hispeed.ch) |
| 07:59.46 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 08:10.33 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 09:20.19 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) |
| 10:16.35 | *** join/#brlcad CIA-5 (i=cia@cia.navi.cx) |
| 14:29.17 | Maloeran | Hey Erik, can you ask Lee sometimes if he still want Voxel support in the raytracer? He wasn't sure the last time we met in Baltimore |
| 14:32.05 | Maloeran | Would just be nice to know to update the schedule |
| 14:32.36 | ``Erik | if I see him today, sure... his office door was closed when I got my coffee |
| 14:32.46 | ``Erik | is the transparency stuff committed? |
| 14:33.23 | Maloeran | It isn't, I got a bunch of optimisation and SSE paths to do first |
| 14:33.42 | Maloeran | Feel free to test what's in CVS, just to make sure it actually runs this time |
| 14:34.41 | ``Erik | I just ran it on a quad opteron fbsd, around 40 fps |
| 14:35.14 | ``Erik | osX crashed on bad memory related to a semaphore |
| 14:35.27 | Maloeran | Gah! Where? |
| 14:35.32 | ``Erik | <-- dorking with brlcad at the moment |
| 14:35.45 | Maloeran | Okay. |
| 14:43.31 | ``Erik | http://paste.lisp.org/display/32142 |
| 14:45.16 | Maloeran | Thanks |
| 14:49.47 | Maloeran | Fixed |
| 15:01.16 | Maloeran | Done. The current transparency demo uses portable scalar pipelines, so it's slow |
| 15:03.40 | ``Erik | 12-14 on the quad opteron |
| 15:03.55 | Maloeran | Thought so :) |
| 15:04.01 | Maloeran | No SSE, no volume tracing, etc. |
| 15:04.29 | ``Erik | still impressive *shrug* |
| 15:04.53 | Maloeran | I'm mostly glad that it finally runs flawlessly over there... ... right? :) |
| 15:08.22 | ``Erik | now I get: http://paste.lisp.org/display/32145 |
| 15:08.32 | ``Erik | it was able to prep |
| 15:08.42 | ``Erik | and threw a few frames up... still yellow |
| 15:10.34 | Maloeran | Thanks |
| 15:11.05 | Maloeran | As for the "still yellow" part... Hackish solution would be to put +1 somewhere when on big endian, real solution would be to query SDL on the format of pixels |
| 15:11.15 | Maloeran | Which I never bothered to do |
| 15:12.17 | Maloeran | How long does the prep take on the quad opteron? |
| 15:12.42 | Maloeran | I'm just wondering if threading is of much help, depites all the locking |
| 15:16.05 | ``Erik | running it now... |
| 15:16.06 | Maloeran | Second bug is understood, now wondering how did I make such a stupid mistake and the best way to reorganize the code |
| 15:16.41 | ``Erik | on the 8 core linux opteron, 4 threads runs ~10-12 fps, 8 runs ~18-20 (holding in the initial view) |
| 15:16.57 | Maloeran | Sounds fine. What about the prep time? |
| 15:17.27 | ``Erik | running... |
| 15:17.28 | Maloeran | SSE and volume tracing should double the frame rate or so, for now |
| 15:18.14 | ``Erik | <-- doing 4 threads on the 4 core fbsd, 8 threads on the 8 core linux, will then recompile with 1 thread (or should it be 0?) and get the 'serial' #'s |
| 15:18.25 | ``Erik | woops, the linux one crashed |
| 15:18.25 | Maloeran | 1 thread |
| 15:18.40 | Maloeran | If you want truly serial, comment out RF_THREADING from config.h |
| 15:18.49 | Maloeran | Same place? It would make sense |
| 15:20.02 | ``Erik | http://paste.lisp.org/display/32148 |
| 15:20.33 | Maloeran | 169 seconds you say? :) |
| 15:22.32 | ``Erik | RF/config.h ? |
| 15:22.42 | Maloeran | To disable threading, yes |
| 15:23.09 | Maloeran | Setting the count of threads to 1 in rfdemo.c would have been somewhat similar |
| 15:23.23 | ``Erik | now I got a gdb hit on the linux box... and don't quite grok why it'd fail. |
| 15:23.29 | Maloeran | The prep is 12 seconds on this laptop no matter the amount of threads |
| 15:24.03 | ``Erik | Preparation time : 9.943 seconds |
| 15:25.38 | Maloeran | Is that astronomical prep time constant with many threads? |
| 15:25.46 | ``Erik | http://paste.lisp.org/display/32149 |
| 15:25.47 | Maloeran | It's... rather peculiar |
| 15:26.40 | ``Erik | lemme try it with two threads |
| 15:26.43 | Maloeran | Okay, seems I got a couple things to fix still |
| 15:28.15 | ``Erik | two threads gave me 53.403s on the fbsd/quad |
| 15:28.33 | Maloeran | Ah, messy |
| 15:28.45 | Maloeran | On the laptop : Serial is 10 seconds, threaded is 12 seconds |
| 15:28.59 | Maloeran | Could the synchronisation be killing performance that much? |
| 15:29.03 | ``Erik | how many cores? |
| 15:29.06 | Maloeran | One |
| 15:29.29 | ``Erik | so chances are you almost never get a block on lock |
| 15:29.55 | ``Erik | since you don't do system calls, as long as your critical sections are faster to compute than your scheduled quanta |
| 15:29.58 | Maloeran | Oh it does, but it doesn't have to flush and reload cache lines constantly because another processor wrote there |
| 15:30.24 | ``Erik | *shrug* |
| 15:30.34 | Maloeran | I really wouldn't have thought it could be dramatically *slower* with threads |
| 15:31.43 | Maloeran | Unless there's some glitch I'm missing, because that's not consistent with my understanding of cache synchronisation |
| 15:31.48 | Maloeran | It shouldn't be _that_ bad |
| 15:33.21 | Maloeran | Is it the same thing on Linux? I just want to make sure because that's one OS I know well |
| 15:33.30 | ``Erik | http://paste.lisp.org/display/32149#1 <-- crash on the mac |
| 15:33.40 | ``Erik | linux crashes |
| 15:34.20 | Maloeran | Okay, thanks. I'll fix this mess to begin with |
| 15:35.13 | ``Erik | but... not... consistantly... |
| 15:35.14 | ``Erik | hrm |
| 15:38.40 | ``Erik | hrmph, 8 threads to 12.117, 4 took 10.907, 2 took 9.555, 1 took 10.600 |
| 15:38.50 | ``Erik | that's one sample each, so *shrug* heh |
| 15:39.00 | Maloeran | Okay, that makes more sense |
| 15:39.08 | ``Erik | on linux... the 8 and 4 had to be run several times due to crashing |
| 15:39.21 | Maloeran | Ahaha, right *shivers* |
| 15:45.31 | Maloeran | Is the non-scalability of pthreads on fbsd the same problem Justin encountered long ago? |
| 15:45.44 | Maloeran | He had to switch to some non-default library or something |
| 15:46.13 | ``Erik | um, he was initially using a green threading library |
| 15:46.35 | ``Erik | so it wasn't taking advantage of multiple cores... the libmap.conf is adjusted so all apps use the thr many-many library now |
| 15:48.34 | ``Erik | any news on the moving arrangemens, btw? |
| 15:49.53 | Maloeran | The last news were Survice asking me to fill some form with questions such as if I had ever been part of the Germany Nazi government, participated or organized genocide, etc. |
| 15:52.22 | Maloeran | I'm not seeing the prep bug, do you have a couple more minutes to stockpile backtraces to throw at me? |
| 15:53.25 | Maloeran | With all these bugs, I'm astonished I never encounter them |
| 15:55.21 | clock_ | With all these gay boys, I'm astonished I never encounter them |
| 16:04.51 | ``Erik | sleep(0); is an interesting device |
| 16:07.31 | ``Erik | what milestone alterations were ya looking for? |
| 16:08.08 | Maloeran | Not too sure, let's wait Lee's word on voxels |
| 16:08.59 | ``Erik | he's right here, he suspects the voxel requirement may go away |
| 16:09.22 | Maloeran | Oh, good then |
| 16:09.45 | ``Erik | ... |
| 16:09.46 | Maloeran | I'm sure spending more time than I would have thought on little bugs I can't reproduce |
| 16:10.57 | Maloeran | Distributed processing will wait until mere threading is solid |
| 16:17.43 | ``Erik | heh |
| 16:18.13 | ``Erik | now that you have firing all the way through, the segment construction should be fairly easy |
| 16:18.42 | Maloeran | Yes, there isn't much left to code there |
| 16:19.14 | ``Erik | regression test suite isn't done? having identical execution behavior in a deterministic command might help squash these bugs a lot faster |
| 16:19.36 | ``Erik | or mebbe it is done, hrm, regtest... |
| 16:20.13 | Maloeran | It's somewhat done, it runs pre-set tests, log and compare the results |
| 16:21.05 | Maloeran | It expects a reglogs/ directory with reference images, I don't think I uploaded tghat |
| 16:21.22 | Maloeran | that, even. Anyhow, it's probably not of much help for the bugs I'm currently looking for |
| 16:22.47 | ``Erik | have you put abuse on it with valgrind? |
| 16:23.11 | Maloeran | Yes, I haven't found anything but only tried twice ; it takes minutes to run |
| 16:25.57 | Maloeran | From my point of view, what remains to be done : Bug squishing, complete support for and test API features, distribute processing, dynamic geometry, optimisation |
| 16:27.52 | ``Erik | and buttoning up the regression suite, segment stuff, ... |
| 16:28.24 | Maloeran | Right, segment stuff is part of testing API features |
| 16:36.36 | Maloeran | Anyhow, I could guess dates, I'm just annoyed at having no idea how much more time hunting thread prep bugs will drain |
| 16:39.46 | Maloeran | I have the impression it's mostly memory allocation/freeing that hurts performance, it's a global mutex |
| 16:40.02 | Maloeran | I should allocate and manage blocks per-thread |
| 16:41.13 | Maloeran | Which would spare the hypertransport bandwidth too, if using Numa to allocate memory in the right banks |
| 17:06.38 | *** join/#brlcad docelic (i=docelic@ri01-128.dialin.iskon.hr) |
| 17:59.40 | Maloeran | Ever used helgrind, Erik? Is it worth downgrading to glibc 2.3, in order to be able to use valgrind 2.2, to be able to use helgrind? |
| 19:12.27 | ``Erik | 'helgrind'? |
| 19:12.34 | ``Erik | <-- hasn't even used valgrind, heh |
| 19:22.09 | ``Erik | heh, I love when twats brag about putting a 'big' drive in their windows box... |
| 19:22.10 | ``Erik | $ df -k | awk '{print $2}' | grep '^[0-9]*$' | xargs | sed 's/ /+/g;s,.*,(&)/(1024*1024*1024),' | bc -l | cut -b -5 |
| 19:22.10 | ``Erik | 17.15 |
| 19:24.42 | Maloeran | bc: command not found :( |
| 19:25.35 | Maloeran | I spent a hour getting a box up to running helgrind, the race condition checker of valgrind |
| 19:25.56 | Maloeran | And it's worthless, it detects thousands of false-positive because it can't follow the thread logic |
| 19:28.01 | ``Erik | how the fuck dn't you have bc? it's as basic and fundamental as grep or ls |
| 19:29.51 | Maloeran | Eh I know, the laptop is a bit minimalist |
| 19:34.36 | ``Erik | I should get my ultra5 working an ddrop solaris on it and give you an account, heh |
| 19:34.38 | ``Erik | a real unix. |
| 19:49.16 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) |
| 19:51.17 | ``Erik | (if your lappie is something debian based, you could always try "apt-get install bc") |
| 20:12.48 | Maloeran | Cool Erik, I wouldn't mind another test platform |
| 20:13.12 | Maloeran | I have accounts on the servers and desktops of friends, and it's all Linux |
| 20:16.51 | CIA-5 | BRL-CAD: 03mjgillich * 10brlcad/include/raytrace.h: Changed smooth_bot to bot_smooth inorder to match other bot commands and functions. |
| 20:21.21 | CIA-5 | BRL-CAD: 03mjgillich * 10brlcad/src/tclscripts/helplib.tcl: Changed smooth_bot to bot_smooth inorder to match other bot commands and functions. |
| 20:25.46 | CIA-5 | BRL-CAD: 03mjgillich * 10brlcad/src/mged/ (chgmodel.c cmd.c): Changed smooth_bot to bot_smooth inorder to match other bot commands and functions. |
| 20:31.50 | CIA-5 | BRL-CAD: 03mjgillich * 10brlcad/src/librt/ (g_bot.c wdb_obj.c): Changed smooth_bot to bot_smooth inorder to match other bot commands and functions. |
| 20:35.09 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/librt/bool.c: |
| 20:35.09 | CIA-5 | BRL-CAD: the comments around the conditional were entirely unintentional.. from the |
| 20:35.12 | CIA-5 | BRL-CAD: rt_g.debug to RT_G_DEBUG change that was made in 2001. it's just taken this |
| 20:35.14 | CIA-5 | BRL-CAD: long before someone actually tried to shoot a bundle of rays with librt (or at |
| 20:35.15 | CIA-5 | BRL-CAD: least this long for someone to complain about the verbose blather) |
| 20:39.19 | Maloeran | Ah, nice one :) |
| 20:59.09 | ``Erik | my u5 is really gutted at the moment... needs disk, memory, and a cpu... |
| 20:59.33 | ``Erik | <-- thinking it might be cheaper to buy one and use his current one for parts |
| 21:00.56 | ``Erik | heh |
| 21:00.58 | ``Erik | http://cgi.ebay.com/SGI-Octane-Dual-195-R10k-Irix-6-5-22_W0QQitemZ250057622638QQihZ015QQcategoryZ11223QQssPageNameZWDVWQQrdZ1QQcmdZViewItem |
| 21:01.00 | ``Erik | there ya go :) |
| 21:16.12 | ``Erik | http://cgi.ebay.com/Sun-Microsystems-E450-Server-Quad-400MHz_W0QQitemZ320058948288QQihZ011QQcategoryZ51239QQssPageNameZWDVWQQrdZ1QQcmdZViewItem |
| 21:16.13 | ``Erik | swank |
| 22:35.38 | dtidrow_work | netsplit :-( |
| 22:37.06 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 22:37.52 | dtidrow_work | wb |
| 22:40.47 | brlcad | heh |
| 22:40.57 | brlcad | network funkyness |
| 22:41.26 | brlcad | ah, heh.. WALLOP christel: Hi all! One of our main rotation servers just dropped off the face of the planet. Hundreds of trained little monkeys are looking to get it back online. Affected users approximately 3500. Thank you for flying |
| 22:41.30 | brlcad | <PROTECTED> |
| 22:45.44 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) [NETSPLIT VICTIM] |
| 22:45.48 | dtidrow_work | lol |
| 22:46.42 | *** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) |
| 22:46.42 | *** join/#brlcad dtidrow (n=dtidrow@69.255.182.248) [NETSPLIT VICTIM] |
| 22:46.42 | *** mode/#brlcad [+o brlcad] by irc.freenode.net |
| 22:46.43 | *** join/#brlcad tofu (n=sean@bz.bzflag.bz) |
| 22:46.51 | *** join/#brlcad b0ef (n=b0ef@084202024060.customer.alfanett.no) [NETSPLIT VICTIM] |
| 22:48.22 | tofu | eep |
| 22:48.44 | *** mode/#brlcad [+o brlcad] by ChanServ |
| 22:54.05 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 23:12.08 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/tclscripts/ (helpcomm.tcl mged/help.tcl): |
| 23:12.08 | CIA-5 | BRL-CAD: fix an mged bug in the various help commands so that they actually work with |
| 23:12.09 | CIA-5 | BRL-CAD: more than one command listed (as their own help messages implied they were |
| 23:12.09 | CIA-5 | BRL-CAD: capable of). affects help, helplib, and helpdevel which now take zero, one, or |
| 23:12.09 | CIA-5 | BRL-CAD: more command names. |
| 23:18.53 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/NEWS: |
| 23:18.53 | CIA-5 | BRL-CAD: mged help command now shows help for all args listed. this fixes a bug with the |
| 23:18.53 | CIA-5 | BRL-CAD: 'help' command where issuing something like 'helpdevel aip hist' would report |
| 23:18.53 | CIA-5 | BRL-CAD: the non-existance of the 'aip hist' command. now correctly returns the help for |
| 23:18.53 | CIA-5 | BRL-CAD: all listed individually as was documented. this issue was reported by an |
| 23:18.54 | CIA-5 | BRL-CAD: analyst at arl. |
| 23:51.25 | ``Erik | damn, gettin' your ass smacked down there :D |
