Slashdot Mirror

Actually there are other fp languages that give a lot more performance than Erlang. Try OCaml with the native compiler, or SML with the MLton optimizing compiler. These can come very close to C in performance. See http://shootout.alioth.debian.org/

And for an ML like language that provides features similar to Erlang (concurrent, distributed programming), but with even more goodies like constraint based programming, check out AliceML. See: http://www.ps.uni-sb.de/alice/

Read this response of mine... I am aware of FPGA chips and I also understand that they are limited as to what their top performance capabilities are.

The performance gap between FPGAs and ASICs have dwindled in recent years, with FPGAs taking advantage of smaller fab processes than ASICs currently have readily available. That's why Xilinx preaches their "Make Spartan your ASIC" line and gets away with it. :-)

That's why I see this as being a difficult to get running kind of venture. Unless they can perform some kind of miracle, very few regular PC users will be interested in this sort of thing.

I wouldn't be entirely sure about that. This sort of thing should be able to be competitively priced (granted, with a poorer price/performace ratio) to where it could easily be the standard choice for OEM Linux machines.

As another poster suggested, this might work great for embedded or tiny form factor devices, like PDAs, Cell phones and similar. It will be quite a feat to see these graphics cards come close to competing with current mid to low range offerings from ATI and Nvidia.

Nonsense. You can get a lot more out of the FPGAs than most people believe. A lot of individuals still think of FPGAs as those electronic oddities from the 80's. Projects like SaarCor are demonstrating how FPGAs can outperform even a Pentium IV. Do not underestimate these guys.

To your original question, if the ASIC route is taken, the chips can either be delivered by the fab to the board manufacturer on a tape and reel, or sockets can be used to plug in the chip during packaging.

try running Quake III on an FPGA - it will be killed by the CPU in processing and killed by the GPU in graphics

Oh, you mean, like this?

If you haven't taken a gander at it yet, you may want to take a look at OpenRT and projects using OpenRT such as Quake3 Raytraced. Also take a look at the hardware architecture as well.

Ray-tracing presents a much more detailed rendering of a scene, but was always considerably slower than rasterization. If hardware-accelerated ray-tracing architecture grows in the market, you may see your skyline beautifully rendered in real-time .. with traffic, crowds, etc.

Aside from the "wow" factor, how much does Raytracing really add?

This is one of their raytraced scenes, and this is a shot from the half-year-old Half-Life 2. Notice how while the shadows and lighting in HL2 are burned-in, they're still pretty convincing. This is a shot from a raytraced Quake 3. Notice how it's single-pass raytracing with no reflections and sharp edges... For the full benefit of raytracing you need multipass.

This is an early, leaked shot from Quake 4, a traditionally poly model engine. Traditional racing Games always have great lighting. This is a scene from GTA based on the Q3A raytracing engine, and this is a vaguely similar scene from the game.

With normal mapping coming into it's own and polygon edges mostly a thing of the past, what benefit does raytracing give us? Shadows? It costs us less than one character to draw a drop shadow. Dynamic lighting? There are tricks to doing pseudo dynamic lighting in many circumstances. Generally, though, you don't want too many moving lights in your scene anyway, as the effect is quite nauseating.

The only major benefit that I see with real time raytracing is that it would free up the artists and coders to drop some of the tricks they've been putting in place for the usual lighting stuff.

But for lighting effects, we've got a lot already going, and more coming in soon. I personally can't wait for relative light levels to make their way into more game engines. And normal mapping to become really normal. For many years I had wanted realtime raytracing, but now it seems so unnecessary.

It just seems like raytracing will always be so much more expensive, that the flat-polys-with-tricks models will always look better for the same hardware.

Of course, knowing this industry in 5 years we'll probably have chip boards that have one processor spit out a traditionally drawn 3d polygon scene and another which renders and layers upon that a 2d greyscale light map at a slightly lower resolution using a reduced parallel geometry set or some such. Instead of making things easier, they usually tend to make things harder. Oh well.

Can anyone here with more experience than I explain what raytracing gives you that you couldn't fake more cheaply?

Aside from the "wow" factor, how much does Raytracing really add?

This is one of their raytraced scenes, and this is a shot from the half-year-old Half-Life 2. Notice how while the shadows and lighting in HL2 are burned-in, they're still pretty convincing. This is a shot from a raytraced Quake 3. Notice how it's single-pass raytracing with no reflections and sharp edges... For the full benefit of raytracing you need multipass.

This is an early, leaked shot from Quake 4, a traditionally poly model engine. Traditional racing Games always have great lighting. This is a scene from GTA based on the Q3A raytracing engine, and this is a vaguely similar scene from the game.

With normal mapping coming into it's own and polygon edges mostly a thing of the past, what benefit does raytracing give us? Shadows? It costs us less than one character to draw a drop shadow. Dynamic lighting? There are tricks to doing pseudo dynamic lighting in many circumstances. Generally, though, you don't want too many moving lights in your scene anyway, as the effect is quite nauseating.

The only major benefit that I see with real time raytracing is that it would free up the artists and coders to drop some of the tricks they've been putting in place for the usual lighting stuff.

But for lighting effects, we've got a lot already going, and more coming in soon. I personally can't wait for relative light levels to make their way into more game engines. And normal mapping to become really normal. For many years I had wanted realtime raytracing, but now it seems so unnecessary.

It just seems like raytracing will always be so much more expensive, that the flat-polys-with-tricks models will always look better for the same hardware.

Of course, knowing this industry in 5 years we'll probably have chip boards that have one processor spit out a traditionally drawn 3d polygon scene and another which renders and layers upon that a 2d greyscale light map at a slightly lower resolution using a reduced parallel geometry set or some such. Instead of making things easier, they usually tend to make things harder. Oh well.

Can anyone here with more experience than I explain what raytracing gives you that you couldn't fake more cheaply?

Dude, way to miss the point entirely. First of all, this is a prototype, not a production model. Second, according to TFA, "Nvidia's GeForce 5900FX has 50-times more floating point power and on average more than 100-times more memory bandwidth than required by the prototype." In other words, imagine what this baby can do when backed up by today's graphics technology.

... are impressive (here and here, for example). They don't look like much and might appear a bit dull but the ammount of details in reflections and such is surprising.
Call me a kid, but this amazing technology appears and all i can think is how cool would it be to see enemies coming behind you reflected in a sphere...

Too bad there's no video - but then again, the poor server is doing bad enough as it is.

... are impressive (here and here, for example). They don't look like much and might appear a bit dull but the ammount of details in reflections and such is surprising.
Call me a kid, but this amazing technology appears and all i can think is how cool would it be to see enemies coming behind you reflected in a sphere...

Too bad there's no video - but then again, the poor server is doing bad enough as it is.

There already is one, but the .torrent seems to have gone down with the rest of the site: http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/ 20040509_egoshooters_q3rt.avi.torrent

Problem is, almost every interface I've ever used (including most apple ones) on the Mac was really (at least a) two-button interface, you just had to emulate the right mouse button with a key+click, an operation I always find HARDER than just a damn right click.

Actually, IMHO, the only platform to get it right was AmigaOS - two button mouse, right click activated the main hierarchical menu system - with no FUCKING STUPID JUMPAROUND CONTEXT MENUS that completely destroy ability to use muscle-memory to learn to do operations rapidly, context was indicated by ghosting out inapplicable menu items. Two buttons weren't "confusing". Left button was "select", right button was "menu", and that was that.

By default, the menus lived at the top of the screen like the Mac, but with a commodity (amiga daemon) called MagicMenu
they were whereever your mouse pointer was - the GOOD bit of context menus, but never changed ordering other than the context ghosting, unlike gay-ass conventional Windows/Mac/Linux context menus. I was at least 2x as fast using Amiga MagicMenu menus as any other platform before or since.

mobile Beowulf ;P

mobile Beowulf ;P

Vannivar Bush described it before anyone could do it. Actualy maybe Babbage and Lovelace, Asimov, and/or probably someone like Jay Williams did a better job.

I'm more a fan of http://graphics.cs.uni-sb.de/~morfiel/oasen/

..but how does raytraced Quake 3 grab you?

Actually, I bet with that much CPU horsepower, you could have a raytracing graphics engine instead of texturized polygons, and it would be real time still.

Are you aware of this?

Actually, it was only 20 Athlon XP 1800s. Slashdot article here.

nVidia Gelato
Mental Ray taking advantage of OTS hardware
Dedicated raytracing hardware
Raytraced Quake 3
OpenRT realtime raytracing framework

There's a prototype of a ray tracing GPU. Small, but fast.

Somebody didn't notice the frameset...
Screen Shots
Downloads (video)

Somebody didn't notice the frameset...
Screen Shots
Downloads (video)

This video is also very interesting. It should be entitled, "how to make one's jaw drop". =D

I'm not sure that's gonna happen. The fact of the matter is that current graphics hardware is fast approaching the point where raytracing will be irrelevant.

Actually, AFAIK the opposite is true.
Raytracers scale very nicely with geometric complexity: O(log n). So as the virtual environments continue to grow, raytracing should gain popularity over scan conversion. Have a look at this - that's 50 million triangles raytraced at 4-5 fps!

Most of the current interactive raytracing is still done on parallel computers or PC clusters, but there are a lot of optimizations that can be combined to achieve interactivity even on a single CPU. And hardware architectures are underway as well...

To hype anything as 'new' and 'revolutionary' is silly, since as we all know, nothing new has been invented since 1970. But there are certainly techniques which aren't as popular as they deserve to be. One is Delta Debugging as implemented by delta (a tool to automatically produce minimal test cases) and Ask Igor.

To hype anything as 'new' and 'revolutionary' is silly, since as we all know, nothing new has been invented since 1970. But there are certainly techniques which aren't as popular as they deserve to be. One is Delta Debugging as implemented by delta (a tool to automatically produce minimal test cases) and Ask Igor.

I found Ask Igor on Slashdot some time ago and I think that is a revolutionary debugging technique (I was going to say "as well" but after reading the advert from GuardSoft, err, the article, and some posts I am not so sure that is correct ;))

well, not that small but this one here also looks quite nice:

http://graphics.cs.uni-sb.de/~morfiel/oasen/index. html

Dunno what it is rendered with (and what hardware requirements) but the images are quite nice

Currently my research involves text adventures. My advisor and I believe that text adventure games could serve as an excellent testbed for research in intelligent agent behaviour cause they model a number of real-world challenges, like partially observable world states, incompletely specified goals, and the need for common-sense reasoning and belief revision. Here is his paper on the subject.

I'm currently working on doing Logical Filtering in an adventure game, which is a way to maintain a sort of belief about the current state of your world depending on your prior knowledge and observations. Somewhat like filtering in a Hidden Markov model.

Some people at Saarland University, Germany, are also doing great work on description logics in adventure games. A description logic is like a language where you express concepts and the relations between them so that inferring properties is very easy.

It would be great to get some feedback and suggestions from the IF community about what they think about this. Is there any really cool idea you've had about what more could be done with adventure games? I mean many games have some standard stuff like inventories, containers etc. Is there something fundamentally different you've ever thought of doing. Something which involves creative and complex relationships between entities in an adventure games is what we're looking for. Thanks.

If you check the FAQ page out, you'll see that one of "the people behind AskIgor" is Andreas Zeller, the guy who co-created DDD.

This is a tool, nothing more. Computers are deterministic state machines, but the state machine is essentially infinite. Anything that cuts down the number of states you need to look at is good.

Ask Igor seems to be an implementation of delta debugging. You can use the delta program to implement this on your own system. You choose a test program (or 'harness') and an input that causes the harness to exit with success; for example your harness might run some executable and test to see if it segfaults - if so success. Then you give an initial input that passes the test (eg causes the segfault). Delta chops out lines of text to find a minimal (or at least 1-minimal, see the website) test case that passes the test (causes the segfault).

This is slightly different to Ask Igor, which takes two different files and finds the important difference between them. But similar in spirit (if much simpler). Apparently the Ask Igor code will be made available for download after it has been used 1000 times from the website.

However, Passau University has filed international patents for the automatic isolation of cause-effect chains from computer programs--that is, Delta Debugging applied to program states. This is the core technology of AskIgor. This means that if you want to make money out of AskIgor technologies, you'll have to license the patent.

Arg, I thought us Euro's didn't have to worry about software patents anymore. Then again, isn't it a bit weird to have AskIgor licensed under the GPL and filing patents on it at the same time? IANAL, but is this possible? You file a patent to make cash from it by licensing it to others (or using the technique yourself), or you make it opensource and give it away freely. They say that "Delta Debugging" isn't patented, but when it's applied to program states it is (will be).

Gotta love IP...

While not applying AskIgor (being a huge mix of Python, PHP, and SQL) on itself, we have applied delta debugging on various parts of AskIgor to detect failure-inducing code changes, and especially failure-inducing GDB commands.

We're currently working on Eclipse plugins written in Java, and working on Java - and these will work 100% on themselves.

While not applying AskIgor (being a huge mix of Python, PHP, and SQL) on itself, we have applied delta debugging on various parts of AskIgor to detect failure-inducing code changes, and especially failure-inducing GDB commands.

We're currently working on Eclipse plugins written in Java, and working on Java - and these will work 100% on themselves.

looks like a page thats begging to get slashdotted..

Here is what the BOFH uses with great success.

The (perceived?) problem exists, and is preventing certain software from being released as GPL.

In particular, the ActiveMath system, developed in the University of Saarland and the DFKI.

I've been working in this project for one year, but I've been trying to convince them to release it as GPL for more than two years. Consistently and repeatedly, the answer has been that they wanted to do so, but "the GPL is incompatible with German law". The lawyer they consulted, some Professor at the Uni whose name I don't remember now, also wrote a lengthy analysis which I couldn't read since it was in German. But everyone here insists on that indeed the GPL is not valid in Germany.

I planned to raise this issue in the round table Suggestions for encouraging the creation of Free software for researchers at the end of the Libre software and research track in the Libre Software Meeting in Metz, so if other people want to discuss it there, I'd be very interested.

Below I reproduce the content of the email I sent to activemath-dev on Tue, 30 Jul 2002 10:49:41 +0200, with what I know about this issue:

>[copyleft doesn't agree with German law]

Do you have some exact quotation? Like an email or something?
Many GPL programs are produced in Germany.

Seems like the only clash is the "no warranty" clause (points 11 and 12), that would be illegal in Germany ("Gesetz zur Regelung des Rechts der Allgemeinen Geschäftsbedingungen"). (This doesn't mean that you become a criminal by releasing your software with such a clause. It's only that said clause does not apply.)
This just means that we can't reject responsability, just like any other software publisher in Germany.
AFAIK, the rest of the GPL is perfectly applicable in Germany:
http://mailman.fsfeurope.org/pipermail/discussion/ 2000-November/000043.html

However, it seems to be the case that, when distributing something free of charge and with the source available for inspection, that responsability is greatly reduced:
http://www.ifross.de/ifross_html/art3.html

More information can be found in the other pages at the "Institut für Rechtsfragen der freien und open source Software":
http://www.ifross.de

To avoid the dangers of not having the "no warranty" clause, some people use some "Allgemeine Geschäftsbedingungen" (AGB), which put some mechanisms in place to shield the software publisher from sueing. There is a peculiarity in German law that allows anyone to ask for a fee to a publisher when warning them of some infraction, such as trademark infringement. Thus one of the points of these AGB is to allow downloading only to people that abide to them by means of a password-protected download area, and then requiring for access an agreement that the person obtaining the software renounces to use the files to look inside for infringements.
However, this restrictions cause conflict with the GPL, as they are certainly restrictions on the freedom of the users, and can easily make the software non-free:
http://mailman.fsfeurope.org/pipermail/discussion/ 2001-May/0010

or NMM for short, might be a software option. Every piece of hardware is considered as a "node", and it doesn't matter where this hardware is located in a network. A so-called serverregistry is aware of every speaker, monitor etc and handles sources of video & audio towards desired output devices (sinks).

From their website: "The goal of our work is to design and develop a multimedia middleware, which considers the network as an integral part and enables the intelligent use of devices distributed across a network. We are currently designing and implementing a network-integrated multimedia infrastructure for Linux (as well as other operating systems). Our unified architecture will offer a simple and easy to use interface for applications to integrate multimedia functionality. Therefore, it can be used as enabling technology for traditional multimedia applications, but also for ubiquitous computing and mobile computing. The result of our work will be made available as Open Source (LGPL and GPL). "

As far as I know there will be a cvs repository soon, and, of course, there is no ready-to-use application for the situation you describe here. But there's a tool called "clic" which is part of NMM that can be used to connect a bunch of nodes (for example the MP3ReadNode with the PlaybackNode), maybe the way you need.

BabelFish, and other systems based off of the SysTran system use a literal translation algorithm, also called Word-for-Word translation. Thus, it doesn't search for phrases or sentence structure; it's not uncommon to see "su" (the Spanish equivalent of his/her/its) simply translated as "his". And as Spanish would have it, "Ciudad de Mexico" literally translates to "City of Mexico". ("White House" is "Casa Blanca", by the way)

As for the Mekong group, with a quick search you'd find their website. Note that it's "Grupo Mekong".

News flash: Not everything is based off of English. Nor does everything get passed on to American sites.

I wouldn't rate such hack as a good contestant simply because the method is way too simple. But if you prefer to do such a thing, just use this perl script.

Note that HTML tidy can easily clean up such simple hacks. Truly unreadable source cannot be fixed with something as simple as HTML tidy. You can try the above perl script on some HTML file and then inputting that file to HTML Tidy Online.

And just for the record, numeric character entities always refer to unicode character code positions. For example, — (0x97) is undefined (reserved), even though many people try to use that in HTML source to represent emdash.

IMHO, Michael Robertson talks nonsense all the time... he's just an opportunist, capitalistic businessman, just like you mention.

He doesn't know (nor do I think bother) with technology like how geeks see it, he only sees the step 3 part of it (PROFIT!!!!)... for exploitation to increase his money.

Want to see more of his passionate quotes? Check them out here (be prepared to use Google's language tools for some parts of the site). I bet you're loving him and his company more and more now, don't you?

Basically, the explanation is that rasterization takes a time proportional to the number of polygons to render a frame, while raytracing takes time proportional to the log of the number of polygons. That might make you think raytracing should be always faster, which it clearly isn't -- the reason it isn't is that the constant factor in each is very different. So you have a*N vs b*log(N), where b is much bigger than a. As N gets bigger (apparently in the neighborhood of 10 million polygons), the difference between a and b becomes less important than the difference between N and log(N).

The main benefits of raytracing over rasterizing is that it is very easy to get things like reflections, shadows, refraction, and other important effects with raytracing, but with rasterizing, you need to do a lot of complicate and CPU-intensive hacks to get the same effect. Another benefit is that raytracing is parallelizable while rasterization generally isn't. That means that if you have a raytracing accelerator card in your PC, you can nearly double the frame rate or resolution by adding a second raytracing card.

Of course, it's all a chicken-and-egg sort of thing, nobody's going to buy a raytracing card until it's a cheap way to do the rendering they want, and it won't be available unless there is a market. Fortunately, there is research into using the next generation of rasterizing graphics cards to greatly speed up raytracing. This will help bridge the gap, by making raytraced games possible using soon-to-be-existing hardware.

Freedom of expression is a right according to the Grundgesetz, but it can be limited under certain circumstances. I suspect the Dutch constitution will have similiar provisions.

Well, cool stuff but the lines between each nodes pass on one another so much that it is hard to read. They really should consider using vcg.

Don't waste your time with IRMan. It is too expensive. Look at the LIRC site for instructions on building a cheap serial IR receiver. I built mine for ~$5. I got all of the parts at Radio Shack, nothing special at all.

As for Dolby Digital, I'll bet that some high end sound cards support it, but I have no links to back this up. Also, Linux support may very well not exist for these. (hmm, I'm assuming you would be running Linux but you don't say... however this is /. afterall) ;-)

For other features, networking is a must, to control it from elsewhere and perhaps to get program data like the Tivo does. I've always envisioned my house of the future having a central audio server somewhere with all my CDs as high quality MP3s. Then in each room would be some sort of networked terminal for song selection, and a pair of speakers connected to the server's sound card. Have as many sound cards as rooms where you potentially want to have something different playing at the same time. The same could be done with video. I suppose someday soon disk space will be cheap enough that we'll store terabytes of DVD video the same way we store gigs of MP3s now.

Then, it'll need intelligent software to control it. The software should take command-line input, gui input, networked input from remote clients, ir remote control input, and of course, voice input. Fast search/play capabilities are a must, but a menu-driven UI could be available for those who want it. My current system at home (not quite the audio server described above, but slowly getting there) has a custom perl script I wrote that plays songs, albums, etc based on regular expression searches. So rather than wading through a menu to get to Rock -> Van Halen -> 1984 -> Hot For Teacher, I can simply type "playmp3 ^Hot" and it will play everything that matches. Great convenience. Same thing for playing movies on DVD (hmm, do they make 200-disc DVD changers or anything like that?) and selecting TV programs to watch.

Just some random ideas, that's all I have to say...

There are many devices which can be controlled with infrared remote controls. Linux can use IR control signals with LIRC. Not all IR transmitters can send all signals, so some testing will be needed, and transmitters need to be near devices which they control (ie, in the same room).

A: You have plenty of processor power to decode MP3, no $100 outboard dongle required. I also found it odd how hard it was to find that price on the lp3 web page.

B: You can build a parallel port IR reciever that will work with just about any remote controll and with the linux infrared remote controll drivers for about $10 worth of radioshack parts. see http://fsinfo.cs.uni-sb.de/~columbus/lirc/parallel .html for a scematic.

Happy hacking :)

Well, now someone with the TIVO remote control has to create a configuration file for the Linux Infrared Remote Control program.

LIRC may do exactly what you want. Unfortunately, it is a generic tool, and all remotes have different buttons. Therefore, you have to spend the time to hook the buttons up the apps you want. Painful, yes, but a good, good kind of pain. http://fsinfo.cs.uni-sb.de/~columbus/lirc/