00:37.27 |
brlcad |
hello |
00:37.49 |
*** mode/#brlcad [+o brlcad]
by ChanServ |
01:44.17 |
Maloeran |
brlcad or Erik, do you think there might be
any interest in performing raytracing on truly programmable "GPUs"?
http://developer.nvidia.com/object/cuda.html |
01:44.40 |
Maloeran |
From what I hear, it can do random memory
access and incoherent branching finally, compiling true C
code |
02:04.09 |
Maloeran |
This really looks perfect to perform tasks
such as raytracing, an excellent architecture. It's nothing like
our mess of CPUs and their hardware cache synchronisation |
02:11.34 |
*** join/#brlcad IriX64
(n=IriX64@bas3-sudbury98-1168056909.dsl.bell.ca) |
02:11.58 |
IriX64 |
guys, automake-1.10 broke your
autogen.sh. |
02:12.44 |
IriX64 |
can i get away with renaming it to
-1.9.9? |
02:14.46 |
IriX64 |
no i cant |
02:15.24 |
brlcad |
IriX64: what's the error? |
02:15.33 |
brlcad |
./autogen.sh --verbose |
02:16.09 |
brlcad |
Maloeran: haven't we talked about that before
already? :) |
02:16.29 |
IriX64 |
at least version 1.6.0 is required. |
02:16.30 |
brlcad |
we've been watching the gpgpu developments for
years |
02:16.44 |
bjorkBSD |
brlcad, are you in belize? |
02:16.45 |
brlcad |
IriX64: hmm, maybe they changed their version
string |
02:16.49 |
brlcad |
bjorkBSD: heh, no |
02:17.05 |
bjorkBSD |
thought so. |
02:17.07 |
Maloeran |
brlcad, they finally reached the point where
GPUs can be usable for some real computations |
02:17.08 |
brlcad |
the server name comes from bz.bzflag.bz .. tld
makes for a nice server name |
02:17.09 |
IriX64 |
they did it says 1.10 |
02:17.24 |
brlcad |
Maloeran: that's been the case for at least
two years |
02:17.42 |
brlcad |
there are still some issues, but it's
usable |
02:17.59 |
Maloeran |
Random memory access with pointers,
synchronisation between threads, shared memory, incoherent
branching ; this is new |
02:18.15 |
brlcad |
floating point being one, generality being
another, and writing to an interface that is constantly changing
fast |
02:18.44 |
Maloeran |
CUDA is pseudo-C and meant to stay, it seems
quite nicely designed |
02:19.25 |
IriX64 |
_report_error=no for now ;) |
02:20.20 |
brlcad |
yep, cuda is interesting, and has come a
ways |
02:20.25 |
brlcad |
interface is still changing fast |
02:20.25 |
bjorkBSD |
brlcad, you mentioned the other day that tk
wouldn't be used for the next interface, what might it be
instead? |
02:20.39 |
bjorkBSD |
your answer scrolled offscreen when i got
back. |
02:20.46 |
bjorkBSD |
screen/buffer etc |
02:20.57 |
Maloeran |
brlcad, I think it's a huge leap forward. My
nv6xxx and nv7xxx were unusable for tasks such as raytracing ( I
tried ), but these programmable arrays of little processors will do
nicely |
02:20.57 |
brlcad |
bjorkBSD: not logging? :) |
02:21.14 |
bjorkBSD |
no :D |
02:21.19 |
bjorkBSD |
i've run out of harddisk space :( |
02:21.30 |
Maloeran |
Could there be any interest in developing CUDA
raytracing over there? |
02:21.34 |
bjorkBSD |
... i'm trying now to delete some
non-essentials i don't wanna get rid of. |
02:22.13 |
bjorkBSD |
small harddisk. |
02:22.46 |
brlcad |
Maloeran: again.. this isn't anything new :)
there is/was interest -- just a matter of being interesting
*enough* to actually dominate over other tasks and to date that has
not been the case for pragmatic reasons |
02:23.03 |
brlcad |
there is certainly interest though.. that
would be sweet to testbed |
02:23.10 |
brlcad |
I'd certainly fund the idea ;) |
02:23.17 |
Maloeran |
I'm certainly very interested to try
out |
02:23.31 |
brlcad |
bjorkBSD: hehe |
02:23.53 |
brlcad |
bjorkBSD: hmmm did you build static, or do you
just not have much hard drive space? |
02:24.21 |
bjorkBSD |
not much space to begin with. |
02:24.21 |
brlcad |
cd / && du -k | sort -nr |
02:24.37 |
Maloeran |
And the Rayforce API would adopt such a new
back-end very nicely, it was meant to do so |
02:25.01 |
brlcad |
bjorkBSD: as to the answer, it's still
somewhat undecided though also somewhat non-critical given how the
design is layered |
02:25.01 |
bjorkBSD |
and i've been too lazy to go get another
drive. |
02:25.08 |
bjorkBSD |
ah okay. |
02:25.23 |
brlcad |
opengl driven would be a requirement |
02:25.31 |
bjorkBSD |
do you think it would still look the same?
:D |
02:25.37 |
brlcad |
as well as some form of framebuffer
support |
02:25.41 |
brlcad |
bjorkBSD: not in the least |
02:25.57 |
Maloeran |
It's usable outside OpenGL and other APIs. You
can use the library directly to offload computations on the
GPU |
02:26.13 |
brlcad |
some of the same capabilities, taking some of
the best features, but none of the existing gui code in mged would
be used |
02:26.15 |
Maloeran |
Though it can of course be used along with
OpenGL |
02:26.52 |
brlcad |
Maloeran: my opengl comment wasn't towards you
:) |
02:27.01 |
brlcad |
towards new modeling interface |
02:27.42 |
brlcad |
i agree that leveraging the gpu behind a C api
would be sweet |
02:28.10 |
brlcad |
what that api is, looks like, and how
functional it is from a practical standpoint becomes
important |
02:28.13 |
Maloeran |
And CODA uses C code directly, with several
extensions to the language, such as vector data types |
02:28.30 |
Maloeran |
It looks very much usable to me, from all
points of view |
02:29.48 |
brlcad |
from all points of a view is a rather bold
statement.. |
02:29.48 |
Maloeran |
I dreamed of raytracing hardware as I was
frustrated of the horrible architecture of processors, memory and
cache. These GPUs actually have an elegant architecture, highly
efficient, very flexible |
02:31.26 |
bjorkBSD |
hmmm Maloeran you just might re-invent the
ancient SGI machines ;) |
02:31.27 |
brlcad |
elegant and efficient for certain purposes,
not for all purposes in the least |
02:31.27 |
brlcad |
it's a great approach for some tasks, but
there's no sense in overhyping it beyond what it actually is
:) |
02:31.45 |
Maloeran |
:) Fine fine, forgive me if I'm a bit excited
by these new chips :) |
02:32.01 |
brlcad |
a little transparent ;) |
02:33.11 |
brlcad |
as far as I recall, cuda still didn't directly
support (i.e. hardware-accelerate) double precision yet did
it? |
02:33.36 |
Maloeran |
Well no, it doesn't |
02:33.42 |
brlcad |
k |
02:33.59 |
brlcad |
what about framebuffer locking? |
02:34.26 |
Maloeran |
What do you mean by framebuffer locking
exactly? |
02:35.14 |
brlcad |
(so you can cluster-compute with gpu cards) ..
their high-end cards support this, but to date none of the others
did |
02:35.21 |
brlcad |
basically, the ability to lock and share
portions of the framebuffer memory |
02:35.36 |
brlcad |
akin to acquiring a semaphore lock on portions
of memory between video cards |
02:35.49 |
Maloeran |
brlcad, CUDA runs code like an array of
processors. You can store the results back straight into system
memory, without any "framebuffer" |
02:36.50 |
brlcad |
of course, but you're talking about one card
-- that's not what I"m referring to |
02:37.40 |
brlcad |
you can actually gang together video cards
across a cluster, for example, and get them inter-processing
similar to cluster cpus |
02:37.52 |
brlcad |
actually talking to or at least collaborating
between each other |
02:38.07 |
brlcad |
to date only a few cards have allowed this,
rather high-end |
02:38.15 |
Maloeran |
Hum. Well, the cluster CPUs manage the
operations of the GPUs, so I don't see that as a problem |
02:38.44 |
brlcad |
heh, that's a different approach and kills the
benefit I would have retained |
02:40.09 |
Maloeran |
I haven't read anything about synchronisation
of multiple GPUs. As far as I can tell, their operation is entirely
managed by the processors |
02:40.57 |
brlcad |
it's the same technology that allows you to
drive massive displays (like 40000x40000 pixel displays) |
02:42.03 |
brlcad |
(with one cpu) |
02:42.03 |
Maloeran |
Right, I see |
02:42.03 |
brlcad |
you can of course approach the problem in
other ways |
02:42.04 |
brlcad |
but most of them suck ass |
02:42.04 |
brlcad |
(in comparison to having framelock) |
02:44.07 |
brlcad |
it's one of the details that separates the
quaddro fxers from the geforce line |
02:44.07 |
brlcad |
and I forget the ati equivalent |
03:03.53 |
IriX64 |
may i give u a pastebin url? |
03:04.30 |
IriX64 |
http://www.pastebin.ca/359867 |
03:04.40 |
IriX64 |
hat happens with automake 1.10 |
03:04.59 |
IriX64 |
+w :) |
03:06.12 |
IriX64 |
ill be back when i have a fix (cripes Irix
just drop back a couple of revs :)) |
03:18.10 |
*** join/#brlcad IriX64
(n=IriX64@bas3-sudbury98-1168056909.dsl.bell.ca) |
03:31.37 |
brlcad |
IriX64: interesting |
04:56.25 |
brlcad |
IriX64: is that with CVS or a source
tarball? |
04:56.29 |
brlcad |
more importantly.. if that is a source
tarball, can you retry with the latest cvs? there have been
several changes with respect to adrt (which is what it is error'ing
on) |
04:56.30 |
IriX64 |
source tarball |
04:56.31 |
IriX64 |
dont have cvs |
04:56.36 |
*** join/#brlcad IriX64
(n=IriX64@bas3-sudbury98-1168056909.dsl.bell.ca) |
04:56.36 |
IriX64 |
tried to paste something to pastebin.ca, keeps
going away before i can cut the url, sorry but it was the output of
aclocal and automake. |
04:56.38 |
dtidrow |
brlcad: the ATI FireGL line is roughly
equivalent to the nVidia Quadro line |
06:17.28 |
Maloeran |
ATI's Linux drivers have always been
atrociously bad in my experience, especially the amd64 ones. I
can't imagine anyone using them for serious software |
06:17.33 |
dtidrow |
well, there is that |
06:17.33 |
dtidrow |
though supposedly they have gotten better, I
still much prefer nVidia |
06:17.33 |
dtidrow |
hopefully AMD will bash some sense into them
:-) |
06:17.33 |
dtidrow |
in my experience, the nVidia Linux drivers
'just work' |
06:17.39 |
brlcad |
dtidrow: true, but last time I check (2 years
ago?) the firegl line was still missing frame locking, or there was
some issue with it |
06:18.42 |
brlcad |
Maloeran: ati's drivers generally do suck in
comparison, though the quadro and firegl drvier line aren't the
same caliber as the consumer grade ones |
08:05.36 |
CIA-5 |
BRL-CAD: 03brlcad *
10brlcad/configure.ac: |
08:05.36 |
CIA-5 |
BRL-CAD: AM_PROG_CC_STD was deprecated and
later made obsolete by automake 1.8 with the |
08:05.36 |
CIA-5 |
BRL-CAD: functionality merged into AC_PROG_CC.
the macro attempted to ensure that the |
08:05.36 |
CIA-5 |
BRL-CAD: compiler is running in 'ansi mode'.
add AM_PROG_CC_C_O to handle compilation of |
08:05.36 |
CIA-5 |
BRL-CAD: non-libtool stuff with compilers that
don't happen to support the common -c -o |
08:05.36 |
CIA-5 |
BRL-CAD: syntax. latest automake seems to be
complaining about the option being |
08:05.37 |
CIA-5 |
BRL-CAD: missing/needed (reported by IriX64)
during autogen.sh. |
08:10.04 |
*** join/#brlcad clock_
(i=clock@84-72-93-122.dclient.hispeed.ch) |
11:55.58 |
*** join/#brlcad ``Erik
(i=erik@c-69-250-155-85.hsd1.md.comcast.net) |
12:40.35 |
*** join/#brlcad IriX64_
(n=IriX64@bas3-sudbury98-1168056909.dsl.bell.ca) |
13:13.15 |
*** join/#brlcad docelic
(n=docelic@212.15.183.177) |
13:21.40 |
*** join/#brlcad SWPadnos_
(n=Me@dsl245.esjtvtli.sover.net) |
15:05.34 |
*** join/#brlcad clock_
(i=clock@84-72-93-122.dclient.hispeed.ch) |
21:34.37 |
*** join/#brlcad ibot
(i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
21:34.37 |
*** topic/#brlcad is BRL-CAD
CSG Modelling... http://www.brlcad.org http://sourceforge.net/projects/brlcad |
22:11.21 |
*** join/#brlcad cad88
(n=530d8e42@bz.bzflag.bz) |
22:12.36 |
cad88 |
hello I have problem with mged and rt ( 7.8.4
), mged tries to lunch /usr/bin/rt instead of
/usr/brlcad/bin/rt |
22:12.58 |
cad88 |
is there any config to change path? |
22:13.59 |
cad88 |
during configure --prefix was not
changed |
22:15.09 |
IriX64 |
last line of make install output: be sure to
add /usr/brlcad/bin to your *path* |
22:16.03 |
cad88 |
I did it |
22:16.15 |
IriX64 |
did ir right? |
22:16.20 |
IriX64 |
it even. |
22:16.21 |
cad88 |
100% |
22:16.35 |
IriX64 |
try it from the bin dir then. |
22:16.43 |
cad88 |
The probelm is that mget tries to run rt with
absolute path |
22:16.46 |
IriX64 |
ie cd /usr/brlcad/bin |
22:17.02 |
cad88 |
rt works perfectly rom tty but not from
mged |
22:17.15 |
IriX64 |
just a sec. |
22:17.57 |
IriX64 |
works properly here |
22:18.06 |
IriX64 |
gotta be your setup |
22:18.31 |
IriX64 |
rt: a database is not open. |
22:19.10 |
IriX64 |
want me to pastebin it? |
22:19.41 |
cad88 |
when I do rt in mged i got: /usr/bin/rt no
such file or dir |
22:19.48 |
cad88 |
yes please |
22:19.59 |
IriX64 |
just a sec |
22:22.33 |
IriX64 |
http://www.pastebin.ca/361083 |
22:24.54 |
cad88 |
no you have miss understand me.... I mean that
mged ties to run rt with absolute path ... /usr/bin/rt ant it
should run it with /usr/bin/brlcad/bin/rt |
22:25.14 |
cad88 |
mged just cant find binary of rt |
22:25.20 |
IriX64 |
if it was trying that i would not have got the
result i did . |
22:25.41 |
cad88 |
if I link ls -s /usr/brldcad/bin/rt to
/usr/bin/rt all works |
22:26.12 |
IriX64 |
symlink? its not necessary, you've got issues
on your system. |
22:26.44 |
cad88 |
I'm running gentoo , self comiled ant it is
nto system paths problem |
22:27.20 |
IriX64 |
pastebin too. |
22:27.25 |
cad88 |
what version of brlcad You are
running? |
22:27.30 |
IriX64 |
7.8.4 |
22:27.51 |
cad88 |
ok thanks anyway ... |
22:44.54 |
CIA-5 |
libIRC: 03jeffm2501 * 10libirc/ (15 files in 5
dirs): remove the dependency on our own SDLNet, move the subset of
what we needed into net.h and net.cpp, so there isn't any confilcts
with apps that want to use SDLNet for other stuff. |
23:02.42 |
CIA-5 |
libIRC: 03jeffm2501 * 10libirc/src/net.cpp:
add in the actual net implementation |
23:03.02 |
CIA-5 |
libIRC: 03jeffm2501 * 10libirc/include/net.h:
remove the old pre OSX open transport code. |
23:25.33 |
*** join/#brlcad cad28
(n=54be5a78@bz.bzflag.bz) |