01:36.12 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
06:31.01 |
*** join/#brlcad clock_
(i=clock@84-72-93-222.dclient.hispeed.ch) |
08:12.46 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
11:11.29 |
*** join/#brlcad docelic
(i=docelic@ri01-134.dialin.iskon.hr) |
12:35.37 |
*** join/#brlcad docelic
(i=docelic@ri01-195.dialin.iskon.hr) |
13:15.52 |
*** join/#brlcad SWPadnos_
(n=Me@dsl245.esjtvtli.sover.net) |
13:40.02 |
Maloeran |
Erik, there's a pass of the model prep I have
no idea how to efficiently parallelize, your input could be nice if
you got some time today |
13:43.27 |
Maloeran |
Briefly. unlike other passes, I can't just
"lock" a finite volume of space as I can't easily know in advance
how far it will search through the neighbourhood ; the processing
required to safely parallelize doubles the amount of work of the
pass |
14:37.28 |
``Erik |
O.o |
14:54.45 |
Maloeran |
Any thoughts? Tell me if you would like to
know details, or me to shut up and solve that myself :) |
15:00.45 |
``Erik |
what exactly is the pass? |
15:01.11 |
``Erik |
there's not enough info there to say
anything... |
15:01.31 |
``Erik |
(this can be done via dcc or phone if you
don't wanna say in 'public') |
15:01.55 |
``Erik |
or I suppose you could describe the problem in
a file in the cvs repo |
15:03.30 |
``Erik |
hum |
15:04.51 |
Maloeran |
Eh thanks, will privmsg here do? |
15:05.13 |
``Erik |
<-- trying to get his thingie ok with
privmsg... freenode suck |
15:05.14 |
``Erik |
s |
15:05.50 |
``Erik |
bah |
15:05.57 |
Maloeran |
Efnet then |
15:06.03 |
``Erik |
yeah, much better |
15:44.32 |
*** join/#brlcad docelic
(i=docelic@ri01-136.dialin.iskon.hr) |
17:49.38 |
CIA-5 |
BRL-CAD: 03brlcad *
10brlcad/doc/README.Windows: details on building under
Windows |
18:20.56 |
Maloeran |
Commited, ``Erik |
18:21.22 |
Maloeran |
Feel free to report how much it dead-locks,
segfaults or bursts in flames :) |
18:23.07 |
Maloeran |
Otherwise, some figure on how much it scales
with the number of processors would be nice. There's a #define for
that in rfdemo.c |
18:24.02 |
``Erik |
heh |
18:24.36 |
``Erik |
I just ran the truck on a 4 core 2.0 ghz amd64
running fbsd62 and an 8 core 1.8ghz amd64 running linux26 |
18:24.41 |
``Erik |
they get about the same speed... |
18:24.43 |
``Erik |
lemme update |
18:27.29 |
``Erik |
now I get seggies |
18:27.44 |
``Erik |
the fbsd one first whined about RF/job.c 101,
then the next time went sig11 |
18:27.51 |
``Erik |
the linux one went sig11 after drawing a frame
or 2 |
18:28.11 |
Maloeran |
Ahah, okaayy |
18:29.17 |
Maloeran |
Line 101 is a failed sanity check, I'll look
into that. Thanks |
18:29.53 |
``Erik |
on linux |
18:29.54 |
``Erik |
#0 linkListAddPair (listhead0=0x2a95c1cbc0,
listhead1=0x2a959740b0, step0=0x2a95c1cb88, step1=0x2a95974080,
memblock=0x513bf0) at ../../../RF/prepmodel.c:717 |
18:29.54 |
``Erik |
717 if( ( linklist1->used ==
LINKS_PER_LIST ) ) { |
18:30.10 |
``Erik |
(gdb) bt |
18:30.10 |
``Erik |
#0 linkListAddPair (listhead0=0x2a95c1cbc0,
listhead1=0x2a959740b0, step0=0x2a95c1cb88, step1=0x2a95974080,
memblock=0x513bf0) at ../../../RF/prepmodel.c:717 |
18:30.10 |
``Erik |
#1 0x0000002a9585bcef in jobModelPrepStep
(engine=0x50aa20, job=Variable "job" is not available. |
18:30.10 |
``Erik |
) at ../../../RF/prepmodel.c:1721 |
18:30.10 |
``Erik |
#2 0x0000002a95852f03 in jobThreadWork
(thread=0x50ac28) at ../../../RF/job.c:188 |
18:30.47 |
Maloeran |
Thanks. |
18:31.15 |
``Erik |
fbsd is consistantly giving the job.c 101
error now |
18:31.33 |
Maloeran |
If you could output a graph cache with a
single thread, you could at least test the raytracing
itself |
18:34.35 |
``Erik |
rebuilding... |
18:36.27 |
``Erik |
got caches... rebuilding to be
threaded... |
18:37.23 |
Maloeran |
Forcing thread count to 1 now gives you a
"worker" thread and the main user thread |
18:37.39 |
Maloeran |
Before today, function calls would block until
the job was done |
18:37.47 |
``Erik |
now both machines now give the RF/jobs.c 101
error |
18:38.01 |
Maloeran |
Okay, seems I really got something to fix
there |
18:38.10 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
18:38.45 |
``Erik |
could be that you're looking for a job to
execute before one is put in the queue |
18:39.19 |
Maloeran |
Yes, it detects an empty task in the queue...
but I'm always adding jobs to the task before queuing the task,
within a mutex |
18:39.32 |
Maloeran |
So I don't quite see what's going on there
yet |
18:40.01 |
clock_ |
I tried to make some instruction videos with
mged and vnc2swf but mged doesn't run inside vnc |
18:45.56 |
``Erik |
I'm not so sure you do, mal... I see context
calls jobSystemInit(), which inits the queue and throws threads...
and the threads immediately lock and try to grab a job |
18:46.16 |
Maloeran |
That's fine |
18:46.35 |
``Erik |
but there's no chance to put anything in the
queue and the lock is not held by the originator |
18:46.45 |
Maloeran |
The line 101 is : We found a queued task not
yet initiated, but it has no job in it |
18:47.38 |
``Erik |
so something needs to lock the queue before
the threads are thrown... and hold it until a completed task is put
into the queue... |
18:47.46 |
``Erik |
completed as in fully defined |
18:47.56 |
``Erik |
no? |
18:48.11 |
Maloeran |
Threads are launched, they look for work,
don't find any, then wait for signals |
18:48.45 |
Maloeran |
jobTrace locks mutex, allocates a job, puts it
into task, queue task ( which sends signal ), unlock
mutex |
18:49.24 |
Maloeran |
The threads find the queued task just fine,
but they don't find any job in it, which is... curious |
18:51.09 |
``Erik |
hm, *shrug* |
18:58.35 |
``Erik |
right after the lock? |
18:58.37 |
``Erik |
(can't pm here) |
18:58.47 |
``Erik |
:373 ? |
18:59.26 |
Maloeran |
Fine, or in the mutex |
18:59.42 |
archivist |
just register your nick to pm |
19:00.16 |
archivist |
<PROTECTED> |
19:01.08 |
``Erik |
archivist: I registered it a long long time
ago, forgot the password, talked to an ircop, they said they would
delete it in the next hour, the next day it wasn't deleted, tried
talking to teh ircop again, they said it was gone, but every time I
tried to register, it said it was already registered... |
19:01.25 |
``Erik |
still job.c +101 |
19:05.35 |
archivist |
hehe screwed nickserv Last Seen: 1 year 7
weeks 6 days (20h 1m 30s) ag |
19:05.54 |
archivist |
your not here !!!! |
19:06.18 |
``Erik |
:) |
19:07.14 |
Maloeran |
So the job is detected by the thread adding
the task, but not by the other thread reading the task |
19:07.50 |
archivist |
you could attempt to drop the nick |
19:08.07 |
``Erik |
archivist: tried it a while back... via an
ircop... :) |
19:08.43 |
archivist |
I was wondering if nickserv sees you do it it
may work |
19:09.12 |
``Erik |
sees me do what? |
19:10.44 |
archivist |
needs the password though, /msg nickserv
DROP <nickname> <password> |
19:11.11 |
``Erik |
yeah, ... I tried to get the oper to drop it
cuz I forgot the password |
19:11.17 |
Maloeran |
I would have thought nicknames are dropped
eventually |
19:11.19 |
``Erik |
they couldn't reset the passwd or
anything |
19:11.26 |
Maloeran |
I mean, it should be obvious after an
year |
19:11.46 |
``Erik |
the oper said they were, but was gonna drop it
'early' for me... never did, though *shrug* freenode just sucks
;> |
19:18.21 |
Maloeran |
If I had access to a crashing box, I would
print the pointer of the tasks queued, and the pointer of the
"empty" task |
19:18.52 |
Maloeran |
Okay. More than the Shark profiler, I need
multi-processor without shared caches |
19:24.05 |
``Erik |
heehhe, the list of shit you need keeps
growin', dude :D |
19:24.13 |
``Erik |
portable quality sw can be a bitch to
write |
19:24.59 |
Maloeran |
I really hate hunting for bugs without being
able to reproduce the bugs myself |
19:25.41 |
Maloeran |
This one is incomprehensible in its apparent
simplicity |
19:26.28 |
Maloeran |
Do you think you could give me a couple
minutes to insert some printf()s? I fail to understand |
19:28.07 |
``Erik |
sure, tell me what file/line and what to
print |
19:28.21 |
``Erik |
or if you want, make a branch in cvs, make the
changes, I'll update against it, run it, and let you know the
results |
19:40.05 |
``Erik |
efnet... |
19:42.43 |
Maloeran |
Thanks, though it doesn't print the pointer of
the funky broken task before FAIL()'ing |
19:43.36 |
``Erik |
erm, it doesn't? |
19:44.18 |
Maloeran |
Doesn't seem so at least, lack of fflush
perhaps? |
19:44.27 |
``Erik |
here comes another |
19:44.41 |
``Erik |
okie, I'll fflush both prints |
19:45.30 |
Maloeran |
Wait, I'll just send you a job.c |
19:50.44 |
Maloeran |
I think I may have a clue what's going on,
finally |
19:52.15 |
Maloeran |
Thanks Erik |
19:52.18 |
``Erik |
np |
19:53.18 |
Maloeran |
Did you get crashes in the prep or during
tracing earlier? |
19:53.27 |
Maloeran |
When you tried before generating a
cache |
19:54.03 |
Maloeran |
Ah, during the prep too. Okay |
19:57.54 |
Maloeran |
Cool, that's some neat thread race condition.
I don't explain the prep crash yet though |
19:58.17 |
``Erik |
crashed during prep, ran it single threaded to
generate the caches, now it crashes during the trace (it actually
flashes a pic of the trck up before crashing) |
19:59.37 |
Maloeran |
I don't explain the prep crash yet, but that's
a complex beast with many passes, I'm less worried about being able
to miss something there |
20:06.34 |
brlcad |
``Erik: tried to just identify with no
password? |
20:07.01 |
``Erik |
-NickServ(NickServ@services.)- Password
Incorrect |
20:10.01 |
brlcad |
hmm |
20:17.28 |
brlcad |
happen to know who you talked to? |
20:17.40 |
brlcad |
maybe got some newb |
20:36.11 |
``Erik |
don't remember, was heh almost a year
ago |
20:41.37 |
*** join/#brlcad docelic
(i=docelic@ri01-174.dialin.iskon.hr) |
20:49.01 |
*** join/#brlcad clock_
(i=clock@84-72-61-143.dclient.hispeed.ch) |
21:50.23 |
b0ef |
what toolkit was chosen for the new
modeler? |
22:08.19 |
``Erik |
sync |
22:08.19 |
``Erik |
ls |
22:08.21 |
``Erik |
woops |
22:42.05 |
brlcad |
b0ef: it's not decided yet |
22:42.39 |
brlcad |
at least not 100% though there are very strong
notions once a full consideration matrix was put together to
consider the features of the various options available |
22:43.28 |
brlcad |
still, there is plenty of work to do on the
foundation API layers and geometry management before that decision
has to be made -- though if others were involved, that could easily
change |
22:44.12 |
brlcad |
there are some options that will flat out not
be considered due to the nature of the project and
purpose/vision/approach of the new modeler |
22:45.19 |
brlcad |
and I merely assume you're not talking about
archer, as that's mostly unrelated to the long term interface
goals |
22:47.35 |
brlcad |
``Erik: got a staffer willing to fix the
nickserv account problem, at least when he wanders back |
22:47.52 |
brlcad |
RichiH is da man |
23:09.03 |
*** join/#brlcad SWPadnos_
(n=Me@dsl245.esjtvtli.sover.net) |
23:21.02 |
brlcad |
``Erik: so do you want the password reset or
the registration deleted, he's willing to do either -- just need to
call it |
23:21.21 |
brlcad |
says he sent you some e-mail(s) |
23:21.38 |
Maloeran |
Registration deletion should do, no one else
can register the nickname as long as he holds it |
23:23.59 |
brlcad |
done |
23:26.16 |
``Erik |
hum? |
23:26.25 |
``Erik |
what's going on? |
23:26.32 |
brlcad |
wake up |
23:26.39 |
Maloeran |
Feel free to register your nickname,
Erik |
23:26.43 |
brlcad |
take you hand off the bottle and
register |
23:26.48 |
``Erik |
heh, no bottle |
23:26.52 |
``Erik |
just got home and started dinner |
23:27.13 |
``Erik |
hum |
23:27.30 |
``Erik |
is there any way to change a
password? |
23:27.49 |
brlcad |
there is, but had a staffer delete your
account (blame Maloeran for calling it) so it's gone |
23:27.57 |
Maloeran |
/msg nickserv help |
23:28.11 |
``Erik |
aaaaalllrighty then |
23:28.12 |
``Erik |
heh |
23:28.17 |
``Erik |
did a drop and register |
23:28.35 |
brlcad |
heh |
23:29.02 |
brlcad |
and quick to change your password before
saying that I see :) |
23:29.11 |
``Erik |
of course |
23:29.13 |
Maloeran |
Eheh |
23:29.16 |
``Erik |
I'm not a 'tard |
23:29.37 |
``Erik |
buy me some tequila and I'll get like that
soon 'nuff ;) |
23:29.46 |
brlcad |
usually takes about a dozens ghostings before
they "get it" |
23:29.51 |
brlcad |
and sometimes they don't |
23:30.28 |
Maloeran |
Bah. I'm going to need your help again for
that prep bug, Erik, I couldn't manage to trigger it once for the
last hour |
23:30.50 |
Maloeran |
I guess it will wait Monday |
23:31.37 |
brlcad |
Maloeran: i've been meaning to mention some
"user experience" feedback I had with rfdemo while preparing for
the presentation a week ago |
23:31.59 |
Maloeran |
Go ahead, the demo sure is crude |
23:32.09 |
``Erik |
"man, that's one ugly assed truck" |
23:32.24 |
brlcad |
mostly it has to do with the conversion and
prep phase, almost undoubtedly degenerate geometry issues |
23:32.43 |
Maloeran |
The CSG->Triangles leave small and big gaps
everywhere, the raytracer isn't always to blame there |
23:32.50 |
brlcad |
i had a bunch of various models that I
converted from g to ase cleanly |
23:33.22 |
brlcad |
and must have gotten lucky with the first
model as it went through perfectly, about 200k tris |
23:34.13 |
brlcad |
but all four of the next ones I tried all
failed horribly, as they'd prep spewing lots of output and then
basically showing what looked like a polygon soup |
23:34.26 |
Maloeran |
The ASE converter was written specifically to
convert the the rotter-lowe and cathedral models, I won't pretend
it's perfectly compliant with the specs |
23:34.28 |
``Erik |
mmm, curley brackets |
23:35.16 |
brlcad |
it might have been the ase phase, but it
seemed more like degenerate handling code in the reader that was
throwing away a lot of triangles |
23:35.17 |
Maloeran |
Right. I think the ASE converter is presently
ignoring matrices, because some other ASE exporters would provide
matrices... while already transfering the vertices |
23:35.54 |
Maloeran |
It should only throw away triangles with
colinear points, triangles that rays can't intersect |
23:36.18 |
Maloeran |
( My internal triangle representation can not
handle triangles of colinear points ) |
23:36.30 |
brlcad |
also, rfdemo's mouse input didn't work nor did
most of the key input except the cursor controls and maybe one or
two others (e.g. esc didn't work nor did the reset key,
etc) |
23:36.45 |
Maloeran |
There's no mouse input, escape should
work |
23:37.29 |
Maloeran |
already transforming* the vertices |
23:37.34 |
brlcad |
i glanced through the code just to try and see
what the bindings even were since I couldn't get anything other
than the cursor keys to do anything |
23:37.56 |
``Erik |
brlcad expects way too much of the
thing |
23:38.02 |
``Erik |
there's a "case 27:" for escaping |
23:38.03 |
brlcad |
pretty much only those four keys
worked |
23:38.09 |
brlcad |
nah, I expected very little |
23:38.10 |
``Erik |
and a few others |
23:38.14 |
``Erik |
like space, ummm |
23:38.23 |
Maloeran |
Arrow keys, page up/down to zoom in/out/,
escape |
23:38.34 |
``Erik |
space to stop rotation |
23:38.37 |
brlcad |
that's what I mean.. ONLY the arrow keys
worked |
23:38.53 |
brlcad |
i hit the others testing once I found the
bindings in the code |
23:39.00 |
``Erik |
odd |
23:39.06 |
brlcad |
so there's maybe some issue there |
23:39.26 |
``Erik |
worked for me on my g5 and remote X to a fbsd
opteron |
23:39.30 |
Maloeran |
I really haven't focused too much on fancy
demos... All I wanted was to make sure things were working smoothly
so far |
23:39.49 |
Maloeran |
SDL key bindings should work pretty much
everywhere, normally |
23:39.50 |
brlcad |
added a print statement, it was definitely
getting the event .. just not doing what it was supposed
to |
23:39.50 |
``Erik |
O:-) |
23:41.20 |
Maloeran |
Transparency shouldn't be too much trouble,
but I'm not too sure what model to use for that. The truck has gaps
everywhere |
23:42.23 |
``Erik |
*shrug* the truck also has lots of internal
geometry |
23:42.47 |
Maloeran |
brlcad, I'm not entirely following when you
say it was receiving the events but not doing what it was supposed
to |
23:43.06 |
Maloeran |
Are you talking about the escape, space bar
keys? I can't think of much else. Mouse input sure would be good
to add |
23:44.54 |
brlcad |
yeah, space is a good example.. press escape
and it'd print that an event was received right before doing into
whatever the name of that routine is in the case
statement |
23:45.35 |
brlcad |
so it'd get there.. but the reset routine to
stop the motion wasn't functional for "some" reason |
23:45.35 |
``Erik |
the interactive demo interface isn't the
point, though, ... don't sacrifice too much effort to dress it up,
just show off glitzy featues of the lib :) |
23:45.59 |
Maloeran |
<PROTECTED> |
23:46.50 |
Maloeran |
Anyhow, that can't be too serious as a
problem |
23:46.52 |
brlcad |
hmm, then that wasn't the one I was looking at
or not the same place in the code perhaps .. but same end
result |
23:47.08 |
brlcad |
i.e. space wasn't stopping it, and esc wasn't
quitting |
23:47.20 |
``Erik |
escape has worked since the beginning for me
o.O |
23:47.25 |
Maloeran |
Right, okay. OSX I assume? |
23:47.28 |
``Erik |
what A) version and B) os/arch ? |
23:47.31 |
brlcad |
intel OS X |
23:47.45 |
brlcad |
latest SDL binaries |
23:47.59 |
brlcad |
whatever ver of rayforce I was given.. recent
cvs iirc |
23:48.45 |
Maloeran |
I really have no explanation, the SDL
scancodes are supposed to be constant |
23:48.52 |
``Erik |
ok, I have a macbook pro here, lemme update it
and give it a whack there... |
23:57.18 |
Maloeran |
Status, Erik? |