| 00:00.59 | *** join/#brlcad ValarQ (i=vq@90-225-114-111-no122.tbcn.telia.com) [NETSPLIT VICTIM] | |
| 00:00.59 | *** join/#brlcad Twingy (n=justin@c-69-250-236-111.hsd1.md.comcast.net) [NETSPLIT VICTIM] | |
| 00:01.05 | *** join/#brlcad ValarQ_ (i=vq@90-225-114-111-no122.tbcn.telia.com) | |
| 00:02.08 | *** join/#brlcad justin_ (n=justin@c-69-250-236-111.hsd1.md.comcast.net) | |
| 01:23.17 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 01:56.23 | *** part/#brlcad digitalfredy (n=digitalf@200.71.62.161) | |
| 03:03.17 | *** join/#brlcad danfalck (n=dan@pool-71-111-76-8.ptldor.dsl-w.verizon.net) | |
| 03:53.54 | justin_ | I have lay-in lugs, w00t |
| 05:55.04 | *** join/#brlcad clock_ (i=clock@84-72-94-100.dclient.hispeed.ch) | |
| 08:49.48 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 12:13.33 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 12:37.17 | *** join/#brlcad clock__ (n=clock@zux221-122-143.adsl.green.ch) | |
| 12:51.13 | Maloeran | Woah. I mentionned my interest to explore raytracing hardware to Mark from Survice, and now they ask if they can provide anything I could use, even if it's as a hobby |
| 12:53.15 | Maloeran | Prasad stopped idling on IRC long ago, hasn't he? |
| 12:55.02 | archivist | !seen Pra5ad |
| 12:55.09 | Maloeran | Erik seemed to have some vague and diffuse interest to tackle raytracing hardware. What about you, Sean? |
| 13:23.49 | Maloeran | Or anyone else for that matter ;). I sure wouldn't mind exchanging a few thoughts with Prasad if he were to drop by again |
| 13:27.30 | CIA-9 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/Makefile.am: |
| 13:27.30 | CIA-9 | BRL-CAD: make the dependency on libbu.la more explicit, otherwise some versions of |
| 13:27.30 | CIA-9 | BRL-CAD: automake/libtool seem to not detect the dependency causing them to attempt a |
| 13:27.30 | CIA-9 | BRL-CAD: linking of htester before libbu has finished building. thx to dan o'neill for |
| 13:27.31 | CIA-9 | BRL-CAD: reporting this issue (sf bug report 1563466, libbu.la missing) |
| 13:31.37 | brlcad | ~seen pra5ad |
| 13:31.51 | ibot | pra5ad <n=prasad@pool-151-196-137-196.balt.east.verizon.net> was last seen on IRC in channel #brlcad, 32d 13h 28m 54s ago, saying: 'pickle'. |
| 13:32.03 | brlcad | heh, pickle |
| 13:32.14 | brlcad | that about sums up prasad |
| 13:33.19 | brlcad | Maloeran: mildly.. it really depends on the hardware and cost |
| 13:35.13 | Maloeran | FPGAs first, followed by ASIC, then the world? :) VHDL/Verilog code are fairly "portable" for hardware design |
| 13:35.36 | brlcad | in general if it's just an academic persuit with little chance of ever spreading through the community, then my interest dwindles.. even if the hardware and research would be cool .. :) |
| 13:35.56 | brlcad | fpgas in general would be nice to play with just because they have broad applications |
| 13:36.07 | Maloeran | I'm unsure about that, it must be possible to get some backing in order to pursue this beyond a toy |
| 13:36.28 | Maloeran | If we solve dynamic geometry, raytracing hardware should be very appealing |
| 13:37.28 | brlcad | but something tells me that the prices on them aren't going to drop anytime soon, and even if "only" costs a few grand a card (which is currently unrealistic) and gives a nice 10x boost.. and I could have gotten that same boost or better with other chips.. |
| 13:38.04 | Maloeran | FPGAs are just meant for quick testing and experiments I think. To get serious, we need ASIC |
| 13:38.16 | brlcad | i'm not saying I doubt that it couldn't get backing beyond a toy, that doesn't make it something that will "spread through the community" though |
| 13:38.29 | brlcad | getting the backing is frankly easy |
| 13:39.05 | Maloeran | An ASIC design can be fully developed before any real investment, and then we could look for backing |
| 13:39.22 | brlcad | i'm just questioning the merit of the approach, the overall long term utility is quite dubious |
| 13:40.01 | Maloeran | I suppose the long term utility would be to make the first steps towards the disappearance of rasterization hardware |
| 13:40.48 | brlcad | and I don't think that will happen anytime soon |
| 13:40.58 | brlcad | they're driving the market by a couple orders of magnitude |
| 13:41.10 | brlcad | more likely is that video cards will get more and more generic |
| 13:41.22 | brlcad | maybe a union of the "physics card" capabilities |
| 13:41.53 | brlcad | and more programmable in general, maybe eventually to the point of an fpga or some limited subset |
| 13:42.19 | Maloeran | Possibly. Commercial raytracing ASIC boards are already avaiable out there, so there must be a market of some sort |
| 13:42.36 | brlcad | or at least someone thinks there's a market :) |
| 13:42.46 | Maloeran | The more programmable it is, the less optimized it is for raytracing specifically |
| 13:42.53 | archivist | build into your stuff into tft display then |
| 13:43.13 | brlcad | yep, which is why fpga's are mostly academically interesting until you can get that onto an asic |
| 13:43.26 | brlcad | since you won't get the best performance |
| 13:43.38 | Maloeran | Clearly so, but it's handy as a development toy |
| 13:44.40 | brlcad | my main "concern" though is say that the technical implementation was all taken care of and we could fab the "best" ray-tracing specific asic today |
| 13:45.12 | brlcad | someone ponies up 500k in funds to have a bunch of cards made, a massive render farm of sorts |
| 13:46.06 | Maloeran | How is that a concern? |
| 13:46.07 | brlcad | how does that performance compare to 500k invested into a supercomputer/cluster instead? |
| 13:46.14 | Maloeran | Ah right |
| 13:46.18 | brlcad | i don't think the numbers are there myself |
| 13:46.30 | brlcad | and the supercomputer/cluster has vastly more applicable use |
| 13:46.40 | brlcad | s/applicable/general/ |
| 13:47.01 | brlcad | i mean it's cool, very cool |
| 13:47.08 | brlcad | but .... :) |
| 13:47.14 | Maloeran | That's the main issue, definitely. The way I see it, and I could be mistaken, raytracing has not become meanstream because of lack of dynamic geometry support |
| 13:47.31 | Maloeran | With superior algorithms, we can correct that, among other things |
| 13:47.59 | brlcad | and in two years after you dump that 500k in, the cards may depreciate something like 80% and the cpus 50% |
| 13:48.40 | Maloeran | If the design was good, it should be equally possible to build new fancy ASICs with the technology of the moment |
| 13:49.17 | brlcad | while i don't think ray-tracing has become mainstream because 90% of the community doesn't need or care about the capabilities provided -- that will slowly change as more and more realism is added, but even that is a few years off |
| 13:49.30 | brlcad | and in general you can always fake it much faster than you can simulate it |
| 13:49.48 | Maloeran | Quite true. I don't think we would get to the point where we are ready to put ASIC boards together within 2 years anyhow |
| 13:50.08 | brlcad | i mean every single effect and benefit that ray-tracing provides is generally doable on the video card with maybe the exception of subsurface scattering |
| 13:50.10 | Maloeran | So this is a long-term project and/or hobby |
| 13:50.41 | brlcad | and even subsurface is "close enough" with the right textures |
| 13:51.03 | Maloeran | Realistic lighting, as a whole, is not possible by rasterization, but there are other advantages. Ray-tracing doesn't really care about the count of polygons |
| 13:51.09 | Maloeran | You can even have curved surfaces |
| 13:51.13 | brlcad | the benefit will come when all of the "hacks" can be thrown away for the considerably more simple "ray-trace" approach when the performance just isn't a concern |
| 13:52.32 | brlcad | see, you say realistic lighting isn't possible, yet there are a slew of games that hack away "good enough" at reasonably good lighting, good enough for their users regardless if there's no foundation on realism |
| 13:52.56 | brlcad | and they already have curved surfaces (end result, not underlying implementation) from their perspective |
| 13:53.35 | brlcad | not caring about the polygon count would be a benefit |
| 13:54.08 | Maloeran | Quite right. Raytracing still have some serious advantages regarding the simplicity and flexibility of the rendering, and performance being mostly independnat on the complexity of the scene |
| 13:54.44 | Maloeran | It's horrible how much you have to hack things together to do something "realistic" with rasterization rendering, I played with OpenGL for a while... |
| 13:55.17 | brlcad | what I could see happen would be a dedicated ray-trace pipeline getting tacked onto video cards |
| 13:55.39 | brlcad | but that'd only occur IFF the ray-trace community could standardize |
| 13:56.08 | Maloeran | That would only be possible with serious hardware support for space partitioning and so on, I don't think it's so likely to appear on GPUs |
| 13:56.22 | brlcad | talked about that sort of an idea several times with some guys at ati a few years ago and the idea wasn't unheard of |
| 13:58.01 | Maloeran | Well then... To summarize, if we were to seriously aim for a high-performance ASIC implementation, would you have any interest? |
| 13:58.08 | brlcad | heh |
| 13:59.51 | brlcad | possibly, I suppose it really depends on a lot of (other) issues |
| 14:00.40 | brlcad | i've got a new modeling system to focus on, geometry server, run-time engine, solid model analyses, ... |
| 14:01.42 | Maloeran | Understood, and it can wait a few months... I wish we could put together a little team of motivated individuals on this problem, I am personally very interested as you surely noticed |
| 14:13.11 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 18:08.42 | *** join/#brlcad IriX64 (n=Who@bas3-sudbury98-1168052522.dsl.bell.ca) | |
| 18:09.30 | IriX64 | <PROTECTED> |
| 18:09.44 | IriX64 | whats that all about? |
| 18:10.58 | IriX64 | happened in overlap tool obj1-obj2. |
| 18:11.16 | IriX64 | havoc database. |
| 18:11.27 | IriX64 | reproducible. |
| 18:12.09 | IriX64 | and don't tell *me to fix it, you own it :) |
| 18:30.14 | IriX64 | castle has no overlaps. |
| 18:32.04 | IriX64 | neither does cornell :) |
| 18:33.14 | Maloeran | The 10k polygons castle model? Ah, I remember Twingy and I using that in our early ray-tracing experiments :) |
| 18:34.01 | Maloeran | In the days where we would get 200k rays per second instead of 10 millions |
| 18:36.13 | IriX64 | says its the logo castle. |
| 18:36.44 | IriX64 | btw you're at a conference, are you playing hookey? :) |
| 18:37.03 | ValarQ | IriX64: hey, stop spamming me |
| 18:37.12 | IriX64 | haha all right. |
| 18:37.41 | IriX64 | was looking for something you might like because i so enjoyed your vortex. |
| 18:37.56 | ValarQ | you're filling my 0.5TB raid in my mailserver :P |
| 18:38.09 | Maloeran | Ah, we came back from that conference last Friday |
| 18:38.10 | IriX64 | hehe ill tar them up then ;) |
| 18:38.19 | IriX64 | ah i c. |
| 18:39.18 | IriX64 | half a terrabyte? whooo hooo. |
| 18:39.46 | IriX64 | 500gigs later of Irix^4's screen shots and what do we have :) |
| 18:39.58 | IriX64 | s/6/^ |
| 18:41.25 | IriX64 | BTW that error is real. |
| 18:42.59 | IriX64 | hahaha Gordon Lightfoot, summerside of life albumn "and the kind of gig I like the most is a rubbing the wrong girl right" |
| 18:43.45 | IriX64 | :) |
| 18:44.34 | IriX64 | Mouth Wash only $1.50 per bottle ;) |
| 18:46.14 | IriX64 | and no i'm not implying you have halsitosis. :) |
| 18:48.49 | IriX64 | star.g->shooting rays at 100.0mm this may take some time. doh tell me about it. |
| 18:50.25 | IriX64 | if you're going to be a solid modelling suite *be a solid modelling suite ;) |
| 18:51.54 | IriX64 | ray spacing .1m sigh.... look before you shoot :) |
| 18:53.58 | IriX64 | cpu load 100% however kernel time is not even on the scale it's so low. |
| 19:07.13 | IriX64 | scuse me, leaky horse, brb. :) |
| 19:22.22 | IriX64 | g_lint -> 98% sheesh. |
| 19:23.07 | IriX64 | cpu that is not progress.... blargh. |
| 19:25.23 | IriX64 | but as they say, I mourn, I grieve, I move on. |
| 19:25.57 | IriX64 | he was such hot shit toilet paper burned when it touched him :) |
| 19:55.08 | Maloeran | What do you use BRL-CAD for, IriX64? Just curious |
| 20:12.13 | IriX64 | testing my x-compiler. |
| 20:12.52 | IriX64 | how do you test any compiler?throw lots and lots of code at her, and BrlCad qualifies as lots and lots of code :) |
| 20:17.46 | IriX64 | thats why i only report bugs I come across, too busy fixing my own ;) |
| 20:18.38 | Maloeran | Interesting, what compiler are you working on? |
| 20:38.22 | IriX64 | working on what started life as gcc 3.3.3 but has eveolved to be cassie.exe |
| 20:38.32 | IriX64 | evolved too. |
| 20:39.13 | IriX64 | checking for x86-unix-linux-gnu-gcc...cassie.exe love it. |
| 20:40.13 | IriX64 | left a copy called gcc.exe for configure scripts that don't honor CC. |
| 20:42.33 | IriX64 | can you believe this, overlap tool is still shooting rays, what'd you guys do? |
| 20:43.28 | IriX64 | this gui is the shits, i should abandon it. :) |
| 20:44.04 | IriX64 | you see i need to work on something between 5 hour compile runs. :) |
| 20:44.10 | Maloeran | Whine about the current raytracer, you'll like the next one ;) |
| 20:44.25 | IriX64 | heh thanks for the invitation :) |
| 20:44.49 | Maloeran | It might be the fastest in the world, apparently |
| 20:45.14 | IriX64 | define fast, all computers wait at the same speed. :) |
| 20:45.36 | IriX64 | 18.2 ;) |
| 20:48.29 | IriX64 | altho, you know they could use 36.4 or 44.4 and scale for backwards compatibility *shrug. |
| 20:57.40 | Maloeran | Anything special about your branch of gcc? Better optimisation? |
| 20:58.52 | IriX64 | arch mcpu things of that nature, and yes optimization of 3 is there. |
| 21:02.27 | IriX64 | $ gcc --version |
| 21:02.27 | IriX64 | gcc (GCC) 4.1.1 |
| 21:02.27 | IriX64 | Copyright (C) 2006 Free Software Foundation, Inc. |
| 21:02.27 | IriX64 | This is free software; see the source for copying conditions. There is NO |
| 21:02.27 | IriX64 | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
| 21:02.28 | IriX64 | IriX64@hagarsfi-f038a0 ~ |
| 21:02.30 | IriX64 | $ gcc -dumpmachine |
| 21:02.32 | IriX64 | i686-pc-cygwin |
| 21:02.34 | IriX64 | if it helps :) |
| 21:07.58 | *** join/#brlcad ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) | |
| 21:07.58 | *** topic/#brlcad is http://brlcad.org/ || BRL-CAD is an open source solid modeling software suite || Developers needed! Read the HACKING file for details on getting involved | |
| 21:14.44 | IriX64 | lf i post my ld --help screen, you'll.... :) |
| 21:24.25 | IriX64 | www.pastebin.com Mario D'Ulisse |
| 21:27.13 | IriX64 | you know overlap tool needs some work scuse me. |
| 22:28.41 | *** mode/#brlcad [+b %IriX64!*@*.dsl.bell.ca] by brlcad | |
| 22:29.23 | brlcad | you'd think he'd learn |
| 22:33.12 | dtidrow_work | lol |
| 22:46.37 | ``Erik | heh |
| 23:37.47 | Twingy | took you long enough |
| 23:42.11 | brlcad | it's not a full ban, just stole his voice |
| 23:46.27 | dtidrow_work | heh |