| 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) |