3D Raytracing Chip Shown at CeBIT

An anonymous reader submits "As noted at heise.de Saarland University is showing a prototype of a 3D Raytracing Card at CeBIT2005. The FPGA is clocked at 90 MHz and is 3-5 times faster in raytracing then a Pentium4 CPU with 30 times more MHz. Besides game engines using raytracing there was a scene of a Boeing with 350 million polygons rendered in realtime."

Comments

Hardware encoding

[BWJones]

FPGA is clocked at 90 MHz and is 3-5 times faster in raytracing then a Pentium4 CPU with 30 times more MHz.

I am really not surprised at the performance as most anytime you build code into hardware, it is significantly faster. For instance, I used to have a Radius 4 DSP Photoshop accelerator card in my old 68030 based Mac IIci I bought in 1990 that would run Photoshop filters significantly faster than even my much later PowerPC based PowerMac 8500 purchased in 1996 with faster hard drives and more memory.

The same sorts of benefits can be seen in vector math for optimizations that have been built into the G4 and G5 chips with Altivec.

So, the question is: Can these guys get ATI or nVidia to buy their chip?

Re:Hardware encoding

[master0ne]

where is more's law when ya need it!

Re:Hardware encoding

[ghereheade]

As an FPGA, no. NVIDIA et al would find it to expensive. But if they can roll their Verilog/VHDL code into an ASIC without to much trouble, it might be cost effective enough to catch the gamer and CAD markets. And as a side benefit, an ASIC should potentially run even faster thus giving even more amazing performance. In fact, without knowing what these guys are up to, I'd bet that is in their business plan.

Re:Hardware encoding

[foobsr]

So, the question is: Can these guys get ATI or nVidia to buy their chip?

They are trying (surprise, surprise).

From their site (already melted (yes, yes, mirrordot)): We are very much interested in evaluating new ways for computer games and therefore like to cooperate with the gaming industry. Thus if you are in such a position, please send us an email!

CC.

Re:Hardware encoding

[TLLOTS]

It's doubtful that people from ATi or nVidia would have anything more than a casual interest in such a chip. More than anything with the way GPU's have been heading, this device would be more of a backwards step than a forwards one. GPU's these days are far more flexible than they used to be, and there's every indication that trend will only continue, allowing developers to do what they want with the hardware, rather than being told what they can do with it and having no real choice either way.

So to sum up, don't expect to see vastly specialised GPU's for raytraycing hitting the market, at least not for the mainstream buyer. It's more likely that we'll see GPU's become more generalised to the point where raytracing can implemented on software. Will they be as fast as a purpose built chip like this? No, more than likely they won't. Will developers be able to do a whole lot more with them? Most definitely, and though that will come at a significant performance penalty for the moment, I think it's the right trade off to make as we should see far more creative uses of hardware put into practice, such as work being done already to use GPU's for something other than Graphics Processing.

Re:Hardware encoding

[wwahammy]

We already have a generalized chip in a computer; it's called a CPU.

Re:Hardware encoding

[_merlin]

But if you use an FPGA, you can load different code onto it dynamically, to make it do different things depending on the application you're running.

Re:Hardware encoding

[moosesocks]

unlikely. the current generation of 3d cards are all polygon-pushers. Direct3D/OpenGL are all about polygons. virtually all raytracing is done by the CPU.

Of course, raytracing produces beautiful results compared to the other methods of 3d graphics, but it is MUCH more expensive in terms of CPU cycles on today's CPUs and non-existant on graphics chips -- the first gfx chips were polygon-based because drawing polygons is indeed easier than raytracing even with specialized hardware. of course, specialized hardware definitely helps polygons as well. my 300mhz/whatever TNT2 can render a scene as fast as the fastest pentiums today can using software rendering.

all of the big renderfarms rely exclusively on the CPU to do their animations. this could change all that. I for one look forward to seeing the potential this has.

Re:Hardware encoding

[mrgreen4242]

I think there may be a market here. Say, for example, that the next generation of Unreal or Doom engine is designed around something like this. The SOFTWARE vendor could potentially, assuming they could get the cost down far enough, offer some sort of PCI or even better USB2/FW hardware accelerator bundled WITH the game.

Think of it like this... Unreal 4 or whatever the next next gen will be decides to partner up with these guys. They develop an engine that runs at 60fps with amazing graphics, etc. You can buy the USB3 or FW1600 or whatever add-on needed for the game for, say, $50, or a bundle for $75 that has the addon and the game. The development cycle would be much easier as there is only one type of hardware to worry about, and the consumer would win as they could get the new hottness game without having to drop $300 on a new new video card.

It could also serve as an amazingly effective copy protection scheme. Can't very well play the game without the required accelerator.

Seems possible to me.

Re:Hardware encoding

[norkakn]

ASIC should potentially run even faster

sed -e "s/should potentially/will/"

Re:Hardware encoding

[QMO]

I remember the day of hardware keys that would plug into the computer in order to use certain software (though those days were virtually over when I got my first PC).
They were never very popular then. I can't imagine them becoming so now.

Re:Hardware encoding

[Anonymous Coward]

Ray tracing and the current OpenGL/Direct3D way of rendering images are completely different. With OpenGL the rendering system renders a polygon to the frame/z buffer and can pretty much forget about its existance from that point on, meaning reduced memory overheads. Raytracing on the other hand requires every object in the scene to be accessible to render any pixel, each pixel "ray" needs to be tested against all objects in the scene to see which one it hits. This also causes problems moving from the current way programs send polygons to OpenGL to the way required for Raytracers, as I said earlier OpenGL can render and forget, whereas a raytracer can't.

Once those problems have somehow been solved (I don't like the thought of storing 100+million triangles+textures+material info in a video cards memory) then raytracing provides some nice benefits, like parallel rendering - each pixel can be rendered completely independant of any other pixel. Running at 1024x768 could possibly make use of 1024x768 raytracing chips running in parallel! The actual process of raytracing is fairly simple and very elegant (zero overdraw and reflections that can be implemented in a couple of lines of code on a suitable raytracing design), which to me means it is a better solution than all the hacks required to make OpenGL style rendering work. I'm not saying OpenGL is bad, in fact its amazing what can be done with current rendering techniques, but those techniques have come about largely as ways around the problems created by a sub-optimal process which was designed as a way to get around having to keep everything in memory.

Re:Hardware encoding

[Afrosheen]

Those days are over for the average computer user at home, but it's very alive for corporate users. Alot of CAD and design software requires keys on the workstation AND the server.

Re:Hardware encoding

[Cylix]

I used to use a usb key for lightwave.

I'm sure they probably still do this, but it's been some time.

Re:Hardware encoding

[lgw]

I don't know about the cost limitation for CAD cards. You can easily spend 6-7K on a NVidia CAD SLI setup today - if you could replace that with 1 card that was faster, I'm sure NVidia could get just as much for it.

Re:Hardware encoding

[aichpvee]

They develop an engine that runs at 60fps with amazing graphics, etc.

Should be able to run a lot faster than that. If they've actually got a 350m poly model rendering in realtime I can't really see how they'd need to run any game on it that slowly, especially if they're using a dedicated PPU (which by Unreal 4 or whatever all the major games are likely to be doing) to unload the physics calculations from the CPU. I mean, a 1600x1400 monitor can't even display 2.3m polys at any given time. Even if you assume it's running calculations on a lot of polys that it isn't displaying there's still a lot of headroom left over.

Re:Hardware encoding

[PedanticSpellingTrol]

mmm... ARCsoft

Re:Hardware encoding

[addaon]

Yeah, but a large, fast FPGA can easily top $10k.

Re:Hardware encoding

[gadget junkie]

"I think there may be a market here. Say, for example, that the next generation of Unreal or Doom engine is designed around something like this. The SOFTWARE vendor could potentially, assuming they could get the cost down far enough, offer some sort of PCI or even better USB2/FW hardware accelerator bundled WITH the game."

..as a useful aside, I am buying a new rig for myself and since the specs involve some "advance work" in Pacific Fighters, it isn't what I consider cheap.
At the same time, my father's computer quit on him. He uses it for the "ordinary " things, like mail, web browsing, office work, etc. The machine he needs costs less than half of mine.

My conclusion is, the more the difference between a simple rig and an advance one is add-on cards, the happier I am. I'd love to have the same basic computer for my father, son and me, with differences only in processor specs, graphic card etc. , but it is not so simple, because either you overpay for the basic rig (in a relative sense, since you are trying to buy quality components with a longer useful life) or continue with different types of computer in the house.

Re:Hardware encoding

[Anonymous Coward]

Yeah, but a large, fast FPGA can easily top $10k.

Which FPGA costs $10k precisely? I'm no expert, but $10k sounds pretty crazy for an FPGA on this side of the 1980s.

Last I checked high end Xilinx FPGAs (virtex 2 pro) were going for under 50$USD in quanity, and that was a loooong time ago in terms of the FPGA market.

Prices have been dropping for these parts for some time.

These guys are quoting ~ 60$USD for the new Virtex 4 (beit the two low end models) in quanity.
http://www.cimdata.com/newsletter/2004/37/02/37.02 .21.htm

I saw someplace (FPGA Journal?) that some Xilinx Spartan 3 were going for something like 2$USD in quantity.

No doubt the present offering from Altera (in the Stratix 2, and the Cyclone) are competative.

Reconfigurable logic is fast becoming common place in consumer electronics. Previously you wouldn't dream of putting an FPGA in something you'd have to sell a million of, but now days that propersition is not that far out of reach. For some items it's already cost effective (set top boxes for example).

Actually if you do a little googling you'll find a couple of big names in the computing world researching and developing reconfigurable computing platforms (one as I recall, has an office in Redmond). I wouldn't be suprised if big names in PC graphics cards weren't already throwing money at it.

Re:Hardware encoding

[Rothron the Wise]

Of course, raytracing produces beautiful results compared to the other methods of 3d graphics, but it is MUCH more expensive in terms of CPU cycles on today's CPUs

This may not be true for very long. The complexity of a scene in a traditional polygon renderer like nvidia's chips scales fairly linearly with the number of polygons in view. Not so with raytracers. They have hierarchical structures to test for which group of triagles a ray may intersect and scales more like O(n log n). They also render _only_ viewable pixels, while overdraw is a major hurdle for traditional 3d cards.

What this means is that as scenes get increasingly more complex, there is a crossover point where ray-tracing will overtake traditional rendering, and dedicated raytracing hardware ensures that this happens sooner. If you add this to the fact that raytracing lets you have perfectly smooth non-polygonized objects, perfect reflections and other features not easilly replicated by traditional rendering you'll see the incentive.

A case in point: prman, the renderer used by Pixar is a traditional polygon rasterizer, but Pixar has on occation used BMRT (A renderman compliant ray-tracer) for scenes that require ray-tracing for realism.

Specifically a scene in A bug's life depicting a glass bottle filled with nuts was renedered using BMRT. Flexible and robust realistic reflection and refraction is solely in the domain of ray tracing. What you saw in Half Life was only cheap tricks which would fail miserably in less constrained scenes.

Re:Hardware encoding

[Rolo Tomasi]

USB, Firewire and other serial protocols have much too high latency to be usable in this kind of application.

Re:Hardware encoding

[RichardX]

The thing with dongles is they're expensive, they're a pain in the arse for users, and they still don't stop a determined cracker.

At the end of the day, there comes a point where the software checks it's key/dongle/word from the manual/price of fishcakes in japan and asks itself "So, am I allowed to run?" and all you need to do is ensure the answer to that is always "Yes!"

Re:Hardware encoding

[orasio]

unlikely. the current generation of 3d cards are all polygon-pushers. Direct3D/OpenGL are all about polygons. virtually all raytracing is done by the CPU.

Are not just polygon pushers since a long time now. You should watch Doom3, maybe.

For example, with nvidia shaders 2.0, in a nvidia 5900, there's some people who built a photon mapping kind-of-realtime renderer. I'm sure with the new cards, it could be actually realtime.

For your information, ray tracing is far, far from providing the best results, party because of its failure to represent complex diffuse-specular interactions (caustics being the most visible difference).

Photon mapping is veeeery slow, but comprises two phases, so it /could/ be provided half baked for games, with the 3d card performing the last phase.

Re:Hardware encoding

[kimmo]

I might have missed your point, but the news here is raytracing.

And in RT it is possible that for example 350M objects behind the camera all contribute to the color of one tiny visible object in front of the camera. Think of a one pixel sizes mirror on the screen, which mirrors 350M objects from behind the camera. Huge amount of computation for only one pixel.

Now think about a screen full of such one pixel sized spherical mirrors, with rays bouncing between them and you suddenly have 350M^350M^n rays to trace for each pixel in each frame.

No need to "run it slow" really :)

Re:Hardware encoding

[InvalidError]

I do not think this design would fit in the smallest FPGAs... but a Spartan3-1500 (XC3S1500) does cost only $100 while the nearest equivalent Virtex2 was over $500 little more than a year ago. I tried to check the nearest equivalent Virtex4 (XC4VLX40) but the distributor I checked did not have that model in their database. (and the XC3S1500 was the largest Spartan3 in stock)

With a Spartan3, their 90MHz design would probably reach 150MHz or more then again, I have not seen any mention of what FPGA they used. (I'm presuming they used something older)

Re:Hardware encoding

[Hortensia Patel]

They have hierarchical structures to test for which group of triagles a ray may intersect and scales more like O(n log n).

I assume you're talking about kd-trees... these do indeed offer very nice performance characteristics, but they're designed for static geometry. Efficient raytracing for dynamic geometry (moving or deforming objects) is AFAIK still far from "solved".

If you add this to the fact that raytracing lets you have perfectly smooth non-polygonized objects

and take away the fact that they don't particularly like the arbitrary triangle meshes that make up the vast majority of real datasets...

Flexible and robust realistic reflection and refraction

Yes, "Flexible and robust" is the killer. And not just for refraction/reflection; there's still no fully-general, clean, robust method of shadowing for rasterizers, and it's not for want of trying. Radiosity is a joke. Attempts to get realism out of current rasterization approaches are bodges piled on kludges piled on hacks. It became clear some time ago that the technology was heading up a dead end. Of course, so much has been invested in making that dead-end fast that it's going to be hard to take the performance hit of moving to a better but less optimized approach.

I suspect we'll eventually end up with a hybrid, rather like current deferred-shading techniques. It'll be interesting to watch it all pan out.

Re:Hardware encoding

[oliverthered]

modern rasterising with pixel shaders isn't far off of raytracing polygons, rendering solids has some benifits, but i don't think they'll be that great.

For good rendering you want volumeric processing, to do this you calcualte the light that falls on each surface via any other surface and then put the calculation into a matrix and invert the matrix.

You can then work out from any point in the scene how much light should fall onto it using a simple matrix multiplication.

Re:Hardware encoding

[bleckywelcky]

At something like $14,000 per standalone license, Unigraphics NX can afford to send out a custom-built hardware dongle with every copy purchased. But when you get a piece of software that can allow you to completely collaborate the design, test, and production of a new piece of hardware, it's worth it. The Boeing 777 was designed and tested in software (Unigraphics I believe), and then went straight to production ... no prototype whatsoever. The millions upon millions of dollars Boeing saved by buying a few hundred or thousand licenses was worth it.

Re:Hardware encoding

[daVinci1980]

There's a few pieces of information here that you're missing, I figured I'd drop in my $0.02.

while overdraw is a major hurdle for traditional 3d cards.
Not lately (as of geForce5K+). There are two very tried-and-true methods of getting around this. One is to lay down a depth-only pass first, which allows the hardware to render at ~2x the normal polygon throughput (which is pretty much infinite at this point anyways), and then reject the hidden color pixels *before shading ever occurs*. Also, there is *a staggering* amount of area devoted to doing z rejection in the most efficient manner possible. A rough front-to-back sort of all non alpha-blended objects will generally result in very good performance in terms of z-complexity. Overdraw is very rarely a problem on modern hardware, or at least it's not a problem that developers cannot address.

Flexible and robust realistic reflection and refraction is solely in the domain of ray tracing
Only in your limited view of how to perform reflection / refraction / diffraction effects. There are actually quite effective techniques that allow someone to perform fairly accurate reflections and refractions through an arbitrary object at an arbitrary location. It's all about cube-map lookups and scene management.

Plus you're missing the very large problem with raytracing. Whereas typical 3-D rendering techniques are marginally dependent on viewport size (depending on their specific data set), raytracing is *completely* bound by the number of pixels that have to be displayed. 640x480 is half as bad as 800x600. 1600x1200 is four times worse then that. Anti-aliasing is *4 times* worse then that. Whereas going from 1024x768 to 1600x1200 with 4xAA in a traditional rendering platform is dependent on the data set, in terms of raytracing the problem is *automatically* 10 times harder on raytracing, EVEN IF YOUR SCENE IS EMPTY.

Yikes.

Re:Hardware encoding

[randyest]

No you can't. Programming an FPGA is a relatively slow process. You can't just load new code onto it in system. Not practically at least.

Re:Hardware encoding

[Psyborgue]

First of all sir you seem to be talking out your ass. It's not polygonized, it's tesselated. And Pixar's renderman is a resolution independant REYES Based renderer. It does not tesselate. See the Aqsis manual for information about this. Damn near ALL renderers apart from reyes based tesselate down to polygons. This has _nothing to do_ with whether the scene is raytraced or not. Polygons are a form of geometry. Nurbs and subdivision surfaces would be other types of geometry. Raytracing is a rendering technique. Most raytracers such as mental ray as well as scanline renderers tesselate (or "polygonize") the geometry into appropriately detailed polygon meshes when they render. It only looks smooth since the mesh is so tesselated. Why do you think displacement mapping kills performance so drastically.

Besides... Dedicated hardware raytracing solutions already exist and are widely used. Ever heard of Renderdrive?!?!
Graphics cards now are fast hardware accelerated scanline renderers (no raytracing(there are a few exceptions where it has been done for test purposes)). See NVIDIA's "Gelato" for instance. Or "Parthenon". Both are hardware assisted photorealistic renderers.

You must work in management.

Re:Hardware encoding

[ErikZ]

Let him be, he works for the government. ;)

Re:Hardware encoding

[Bryan Ischo]

Just curious, why do you say "radiosity is a joke"? I don't know very much at all about raytracing, but I remember years ago when the radiosity concept surfaced in practical raytracing programs and I could swear that just about everyone said that it was a *major* improvement.

Re:Hardware encoding

[aichpvee]

Oh, good point. Forget I said anything.

Re:Hardware encoding

[Rothron the Wise]

Only in your limited view of how to perform reflection / refraction / diffraction effects. There are actually quite effective techniques that allow someone to perform fairly accurate reflections and refractions through an arbitrary object at an arbitrary location. It's all about cube-map lookups and scene management.

This is as far away from "robust and flexible" as you can come. Add more than one reflecting/refracting object and you'll have problems. Add a dozen and it's insurmountable.

Whereas typical 3-D rendering techniques are marginally dependent on viewport size (depending on their specific data set), raytracing is *completely* bound by the number of pixels that have to be displayed.

You seem to be conveniently ignoring all forms of adaptive sampling tricks raytracers can use. Also: The reason why conventional graphics cards do not scale exactly the same way is because they are fast enough to be cpu-bound. My initial statement still stands. If you keep adding polygons sooner or later raytracing them will be quicker than rendering.

Re:Hardware encoding

[Rothron the Wise]

The discussion was regarding the practicality of using ray tracing in games, not the implementation details of prman.

The reason why I stressed polygons is because this is the only type of geometry primitive available to traditional graphics cards.

Re:Hardware encoding

[Hortensia Patel]

Oh, radiosity itself is anything but a joke; in a raytracer, it's both natural and a huge improvement. I was talking about attempts to get rasterizers to do (realtime) radiosity, an endeavour rather like training a dophin to play the piano.

Doesn't stop people trying, but it's not pretty.

Re:Hardware encoding

[rescendent]

I assume it works with polys and phong etc. I'd like to see the hardware doing splines and objects not using polys... Though I'm reaching for my check book already...

Whoa, 90 MHz??

[CypherXero]

For a second there, I thought I hit my head, and I had gone back to the early 90's!

Re:Whoa, 90 MHz??

[Meumeu]

According to my cpu I'm in the year64 3000+, well actually I'm in 800, 1600 or 1800 depending on what I'm doing, but it should look like the year 3000.

Great scott!

meh

[Anonymous Coward]

In other news The Miskatonic University is showing a prototype of a 3D Raytracing Card at CeBIT2005.

The FPGA is clocked at 666 MHz and is 3.5 billion times faster in raytracing then a 80486 CPU.

Besides game engines using raytracing there was a scene of Cthulhu awakening in 350 trillion polygons rendered in realtime.

i.e. Vaporware

Re:meh

[YOU LIKEWISE FAIL IT]

The big limitation is that it only renders non-euclidian geometry.

Re:meh

[SilentChris]

Better than the model that only uses imaginary numbers.

Re:meh

[menace3society]

Great! Now we can have our games implement special relativity as a part of the game physics! Think of the possibilites.

Re:meh

[Afrosheen]

Game physics possibilities have already been pushed to their limits. In Half Life 2, the amazing physics engine gave you incredible powers. You could use floating barrels to solve puzzles! You could break things into individual pieces for fun! Cinder blocks dropped into baskets could open doors!

I mean, what else is there? ;)

Re:meh

[falzer]

It'll work great for for games that Man Was Not Meant to Play.

Re:meh

[Mancat]

Why are you so mad at the world?

Re:meh

[KDan]

See the definition of "sarcasm".

Daniel

Re:meh

[Luigi30]

There was a BASKET!? I just put them all on the end of the plank and hoped it'd work enough.

Re:meh

[Meumeu]

Actually you can implement general relativity. Maybe one day, we will have physics engine where space ships don't slow when you cut the engines (yes I've seen games like that).

Re:meh

[Taladar]

Liquid Movements are pretty much ignored due to the high performance cost.

Re:meh

[Afrosheen]

Yeah, you don't remember? It was kind of a side bonus I think, towards the end of the airboat chapter. You had to get out and move cinder blocks into a steel cage to get some panel to slide upwards IIRC.

Re:meh

[blackicye]

One such game from the yesteryears that employed Newtonian physics was I believe Mantis: XF-5700 Experimental Fighter.

It was a pretty fun game back in the day.

Re:meh

[Meumeu]

It was a pretty fun game back in the day.

That's not what the first google result says:
Mantis is one of the least known Microplay / Microprose games ever made, and for good reason: it is a mediocre ship-to-ship flight combat simulator(...)

Also when you try a real space simulator like Orbiter, you have to wonder how anybody can fight up there.

Re:meh

[TomorrowPlusX]

Cthulhu awakening in 350 trillion polygons And when I saw the demo, I promptly went insane and threw myself out the window.

Just annonced

[Prophetic_Truth]

3D Realms upon learning of this new technology has decided to push back "Duke Nukem Forver" until the engine rewrite is completed.

Re:Just annonced

[moeffju]

You misplaced your quotes. It should read:

3DRealms, upon learning of this new technology, have decided to push back "Duke Nukem" forever.

What I would like to see

[narcolepticjim]

Is the Beowulf movie rendered with a cluster of these.

oh yeah

[lycium]

ray tracing will *so* usher in a new era of realtime graphics when we can do something like 10-50m intersections per second.

it's amazing to me that nvidia have ignored this up until now, their existing simd architecture and memory subsystems can be easily adapted...

all we need now is consumer push!

Re:oh yeah

[forkazoo]

It's not amazing at all. When nVidia started making 3D accelerators, OpenGL was a mature, common API. Direct X was gaining traction. DCC and game programmers were familiar with the immediate mode API's, and were making programs that used them.

By making a card that rendered in immediate mode, nVidia had, ya know, a market. If they created a raytracing card, they would have needed to invent a new API to run it. They would have been the only ones with a card that used the API. Because they would have had a very small installed base, nobody would have written programs to take advantage of the API. Other companies have made raytracing accelerators. This isn't new. Most of them have not done incredibly well because there is so little actual use for the product.

Think of it this way... How many programs have you seen written for the 3DFX glide API? So, if you are one of the people who still has a glide card, but it was designed so that it couldn't do OpenGL becuase it used completely different technology, how useful would it be to you?

Personally, I'd love a card like that, if it was well supported by Lightwave, and had a vibrant developer community, and multiple vendors making cards for the raytracing API, and I was sure it wouldn't disappear soon.

Re:oh yeah

[jnik]

So, if you are one of the people who still has a glide card, but it was designed so that it couldn't do OpenGL becuase it used completely different technology, how useful would it be to you?

Normally I avoid Grammar Nazi posts on slash, but this is completely indecipherable. If you're setting up a hypothetical, use the subjunctive. If you're asserting that Glide-oriented cards don't support OpenGL, you're flat-out wrong; they have full OpenGL support. 3dfx also provided a stripped-down, "Quake only" driver that was significantly faster (as was Metabyte's WickedGL driver).

Interesting different example: the first two Delta Force games rendered with voxels, which meant they were software only (they managed to finangle some sort of minor hardware assist with the right accelerator, but only minor). I thought it added a lot to the game, but alas, with Land Warrior they switched to polygons to avoid, frankly, looking like garbage given the hardware support out there.

Re:oh yeah

[lycium]

oh really? 10m ints/s?

the main problem is, as with most graphics-related things these days, caching and bandwidth. i'd like to see you squeeze 10m ints/s out of 1GB/s or so of normal ia32 bandwidth, along with os contention etc. right now 3m ints/s is pretty good for some good homebrew code on a fast machine.

ingo wald's phd thesis nicely outlines the memory and caching systems they use, and you just can't beat a dedicated bus... they'll have the flops to back it too, of course.

anyway, you can all rest assured that interactive global illumination will arrive fairly soon :)

Re:oh yeah

[lycium]

wow, someone calls me mr trace3d (that program sucked btw)!

and yeah, ray tracing is definitely more than just a hobby ;)

Re:oh yeah

[Spy Hunter]

Bah. Raytracing is not required for good graphics. Pixar's Photorealistic RenderMan didn't even have raytracing until version 11, which came out *after* Monsters, Inc.

Raytracers can easily do hard shadows, reflection, refraction, and order-independent transparency. Today's rasterizers can do almost all that too: hard shadows (stencil shadows), and "good enough" reflections and refractions (using environment maps and shaders). Order-independent transparency is a tough one; it can be kludged using shaders, but it is often better simply to work around it.

Realtime raytracing is a dead end, because all of the techniques that make offline raytraced images good (soft shadows, subsurface scattering, caustics, global illumination, etc) are too slow to implement in a real time raytracer. Rasterizing renderers require hacks to simulate many things that raytracing does more naturally, but those hacks run tens if not thousands of times faster than their more physically accurate raytraced equivalents. What those hacks lose in accuracy they gain back in speed, essentially producing more image quality per unit time. And in real-time graphics, time is the most important thing.

Re:oh yeah

[GreyWolf3000]

If he were to use the subjunctive, I still would have a hard time figuring out what he said...

Re:oh yeah

[mrchaotica]

So what you're saying is that we need a raytracing API first, and then cards to take advantage of it later?

Re:oh yeah

[Oscaro]

Bah. Raytracing is not required for good graphics. Pixar's Photorealistic RenderMan didn't even have raytracing until version 11, which came out *after* Monsters, Inc.
Raytracers can easily do hard shadows, reflection, refraction, and order-independent transparency. Today's rasterizers can do almost all that too: hard shadows (stencil shadows), and "good enough" reflections and refractions (using environment maps and shaders).

I totally agree with you. Ray tracing is a totally inefficient algorithm, especially because it ofter requires keeping in memory a good part of the geometry of the scene, while other algorithms can process geometry and discard it immediately.

I would rather see new cards implement something more useful, like curved surfaces processing and real displacement mapping.

Re:oh yeah

[Buzzard2501]

Raytracing is not required for good graphics. Pixar's Photorealistic RenderMan didn't even have raytracing until version 11, which came out *after* Monsters, Inc.

IIRC, Pixar previously used BMRT (which supported raytracing) along with PRMAN to generate some of the scenes.

Re:oh yeah

[mikael]

If they created a raytracing card, they would have needed to invent a new API to run it.

Not necessarily. You can have a hybrid ray-tracer/triangle rasteriser that generates rays from the scan-conversion each triangle/line/point. Then the OpenGL texturing functions remain the same, as well as all the calculations required to support features like bump-mapping (TBN vectors).
Fragment shaders can easily do the calculations to support reflection and refraction as well as Fresnel effects, chromatic aberration and thin-film interference.

If you look around, you will see that people have implemented ray-tracers using OpenGL fragment-programs, although most of scenes are fairly small (100 sphere/triangles). The current limitation is being able to encode a complex scene into a format that can be interpreted by the fragment processor; For such a scene, you need to store all the generated geometry for a single frame on the card's memory along with an efficient space subdivision method to reduce the number of comparisons, then make ray-intersection queries into this database per sub-pixel.

Re:oh yeah

[duggy_92127]

Realtime raytracing is a dead end, because all of the techniques that make offline raytraced images good (soft shadows, subsurface scattering, caustics, global illumination, etc) are too slow to implement in a real time raytracer.

<chuckle> I love you people. Your argument boils down to: it's too slow right now, so therefore it's a dead end. You don't even notice that today we seem to be doing it 3-5 times faster than yesterday. What about next month? What about next year? Five years?

I'm not asserting that real-time ray tracing is the wave of the future or anything. I'm merely chuckling at your total lack of the "long view". What if in the 60s everybody said "This 'coherent light' stuff is neat, but what is it good for? Nothing. Shelve it." Would we have LASIK today? Barcode readers in supermarkets?

It's okay to be excited about cool tech, even if what we're using today is better/faster/cheaper. Because no technology is better/faster/cheaper than what it replaces right out of the gate. This is a demonstration, a prototype. It's something that couldn't be done yesterday. Lets applaud their efforts and just sit back and wait and see if it leads to better-looking games for you and I in the future, instead of telling them to give up because they didn't beat the current leaders on their first try.

Doug

Re:oh yeah

[baadfood]

"Today's rasterizers can do almost all that too: hard shadows (stencil shadows), and "good enough" reflections and refractions (using environment maps and shaders)."

Yep - thats why the mirror reflections in Doom III didnt look like such a cheap trick. NOT.

If you think environment mapping allows for compelling reflections - Ha!

Re:oh yeah

[Oscaro]

Actually we don't use the bubble sort algorithm even if we have fast hardware, simply because it is inefficient. So we use quicksort and other n*logn algoritms.

There is no use for raytracing, simply because no matter how fast your hardware is, it will always be an inefficient algorithm. Its time complexity is quadratic and its space consuption is linear to the number of primitives. Other algorithms have linear time complexity and constant space consuption. So they are better, no matter what hardware you happen to have.

Re:oh yeah

[Spy Hunter]

Huh? If the reflections in Doom 3 failed to impress, it's not the fault of environment mapping as a technique. Have you seen Project Gotham Racing 2? There's some compelling realtime reflections in that game.

Re:oh yeah

[Spy Hunter]

More like .5 to 5 FPS at just 1024x768 on reasonably sized scenes with no antialiasing, soft shadows, subsurface scattering, caustics, or global illumination. The soft shadow example they gave looked like it was using about 5 rays per pixel, way too few for a good-looking soft shadow. As for subsurface scattering, caustics, and global illumination, they didn't demonstrate any of that as far as I saw (though I didn't download everything, the site was too slow). Certainly you can't do all those effects with a measley 2-5 rays per pixel as in most of their demonstration shots.

Re:oh yeah

[Mattsson]

It's a bit of egg/chicken problem regarding more hardware and software supporting the OpenRT api.
But the api is there, there are at least *some* software supporting it, and now also one piece of hardware.
Wonder how long it will take before raytracers like Lightwave get OpenRT-support.
Hopefully not too long, but then again... They might never. =/

Re:oh yeah

[Oscaro]

OK but you still have to retain the whole geometry somewhere until the end of the processing, while scanline algorithms can process geometry in a pipeline way (i.e. read-render-discard)

90 mHz...

[Geogriffith]

90mHz chip that can raytrace far more efficiently than a p4... I want to overclock this thing SO bad!

Re:90 mHz...

[Meumeu]

Imagine if you can overclock it to one hertz, it would be 11 times faster!

Impossible!

[menace3society]

The FPGA is clocked at 90 MHz and is 3-5 times faster in raytracing then a Pentium4 CPU with 30 times more MHz.

That's ridiculous. Everyone on slashdot surely knows by now that the only reliable way to compare processor speeds across architecures is to compare clock speed!

Re:Impossible!

[jlongtin_of_CSM]

How'd this get modded interesting? He's obviously refering to the MHz Myth...

Re:Impossible!

[PxM]

In order to clear up the confusion about performance, the FPGA company involved here has decided to drop the 90MHz from ads and just call the FPGA 75000 ultra-uber-extreme edition.

--
Free iPod? Try a free Mac Mini
Or a free Nintendo DS, GC, PS2, Xbox
Wired article as proof

Re:Impossible!

[AndyChrist]

Yeah, just look at my 3.2 ghz Athlon 64 3200!

Wait, what?

Re:Impossible!

[ruoho]

How about the size? How many miniMacs? Furthermore, I'd like to know how many songs it can hold..

Can someone setup a torrent

[Anonymous Coward]

of the avi clips!!!

Re:Can someone setup a torrent

[synthparadox]

http://owntracker.com/synth/index.php

Torrent of low quality up, others will come as they finish downloading.

Re:Can someone setup a torrent

[synthparadox]

Low, good, and high quality torrents up. For the good quality torrent, you'll have to take the corrected version and add .php to the announce URL.

Quake 3 raytracing demo will be up soon.

Again, located here:
http://owntracker.com/synth/index.php

Re:Can someone setup a torrent

[myukew]

get the chip and render them yourself!

Open FPGA?

[Doc Ruby]

Is the SU driver open source? Because it would be fun to see people hacking it to send general purpose netlists to the FPGA, and harnessing it for other HW-accelerated tasks. Maybe loading up all the PCI slots with those boards, pooling the GFLOPS, and tapping them for graphics when needed - leaving the rest for computation.

Re:Open FPGA?

[Ziviyr]

FPGAs would probably be better at G-INT-OPS. :-)

Re:Open FPGA?

[Doc Ruby]

All digital processors are better at ints. I've always pushed for "an FPGA in every PC" (since 1990), because I expect that a larger community of developers will produce better float implementations. Especially if they're not bound by IEEE float specs, which are extremely valuable when they work, but not well suited to FPGA arch. Some developer out of thousands, coming to FPGA dev out of a different path than the "traditional" (mostly academic), is more likely to come up with a "better" float module if free from that rigorous straitjacket. Then some other developers can make that algorithm work with all the stuff that expects IEEE. The key to a productive organic soup is scale and complexity. Lots of open FPGA boards can make that happen.

Re:Open FPGA?

[harrkev]

And if every PC since 1990 has a FPGA in it, we would be stuck with backward-compatability problems. "I have the new Vertex 2 Pro. Too bad it can't run my game, which requires an original Vertex."

This is a major problem. A modern processor can abstract away many of the complexities of its design. The ISA just has to run, and the processor can handle the details of how this happens. With an FPGA, you are down-n-dirty with the hardware. Any architectural changes have an major impact on how you handle the device.

If you want software to take advantage of a FPGA, then you have to have a standard. Let's assume that an FPGA is chosen as the "standard." Here are the consequences:

1) You now have one vendor -- who can arbitrarily set their own prices. FPGAs have a lot of IP in them, so one manufacturer cannot simply copy another's design.

2) Upgrading would be very difficult, because you would loose backwards-compatability.

3) How do you handle multi-tasking? What if you have two programs running - both of which need the FPGA?

4) Bad code. It is easy to imagine a scan chain sending one "one" followed by a bunch of zeros. Then, tie all of the drivers to the same global net. Every clock tick = a blown transistor! Fun task for a virus writer!

I am not saying that having an FPGA is a bad idea, but you need to think long and hard before you do this. You would need some sort of API for the FPGA. Obviously, hard-coding for one FPGA will not work. We need flexibility. So, we need to be able to compile for an EDIF, with the ability to use cores. And going through this process once can take HOURS on even the fastest of machines. "Thank you for installing Photoshop 2008. We are now going to prepare the FPGA programming. Please wait 12 hours." This would only need to be done once per machine, but would still be a pain in the rear.

I can see that the FPGA is needed in certain circumstances, but I doubt that it is a good general-purpose device.

Re:Open FPGA?

[Doc Ruby]

All those problems are best addressed by a larger pool of developers. The same could be said of DSPs: practically every PC has had a DSP in its soundcard since about 1992, and that's a clear benefit (even if few apps have made the DSP a general purpose resource). It's exactly those kind of problems that can continue in the sheltered FPGA development community, which wide application can help bootstrap past the chicken/egg problem.

The FPGA is the (nearly) ultimate general purpose device. It lacks general-purpose SW, mostly because its market has been highly specialized niches. Get them in every PC, and, like math coprocessors and MMUs, programmers will work out how to use them for more than their original benefit.

Sweet deal!

[dauthur]

350m polygons is god damned amazing. I'm sure the kids at Havok will find good ways to implement this, and I'm sure Abit, Biostar, etc will too. I wonder how long it will take for them to make a PCI card you can put in as a graphics-card-booster... or maybe even USB? This technology is extremely exciting. It would definitely lessen the load off of g-cards, and drastically improve the framerate.

Re:Sweet deal!

[Quelain]

Would the number of lights be a limiting factor though? You'd have to account for each light to get the 'real' shadows right?

Should run Doom3 pretty well then I suppose...

Re:Sweet deal!

[dauthur]

Umm... I meant Havok mixing it into the works of their engine. Tool.

Re:Sweet deal!

[maglor_83]

I'm no ray-tracing expert, but I think it depends on the approach you take. You can either send out rays from all your lights, and see which ones get to you, or you can send out rays from the screen, and see what light they emanate from. The latter you could have any number of lights, whereas the former you have the same light-limiting problems we have now.

Re:Sweet deal!

[forkazoo]

In general, yes, lights will be one limiting factor. I'm going to blabber a bit about how complexity grows in raytracing when you move past very simple scenes... Then get to your comment about Doom3.

In the simplest algorithm, assume only point lights, no spots or area lights. Basically, when you are shading a point, so you can draw it on screen, you trace a ray from that point to each light. (You may limit the lights that are at a distance beyond some cutoff, doesn't matter.) If the ray hits some geometry on the way to the light, it is in shadow for that light.

So, without reflections, or anything cool, just pointlights, and shadows, you will trace
S+L*S rays

where S is the number of scene samples (pixels) that you are shading, and L is the number of lights. The lone S comes from all the rays you trace from the eye point out into the scene in order to figure out which point is visible at which pixel.

If you have lots of reflections and refractions, that's what can really start to slow things down. At your point being shaded, you have to trace a ray each for the reflection, and for the refraction. If the reflection ray then hits another surface which is reflective, you trace another ray to get the reflected reflection, same with refraction. So, in theory, each sample point can spawn two new rays in addition to the rays for shadow tests, and each of those two new rays can result in two more new rays, etc. You basically have to set some limit to how many times you let it recurse, because two parallel mirror planes would take forever to render accurately.

But wait, there's more! (it slices, it dices!) Everything really starts to explode when you throw out soft shadows and hard reflections. If you want everything to be nice and soft and smooth, you basically have to trace lots of rays and average the results. So, instead of each recursion in a shiny refractive scene spawning two more rays, it may need to spawn 20 or 200. Assume a max recursion of 5, and 20 rays being generated by each shading point.
First point traces twenty rays.
Each of those 20 trace 20 for 400.
Each of those 400 trace 20 for 8000
160,000
3,200,000 shading sample points for the fifth level of recursion, each of which will need to trace rays for each of the lights which might not be casting a shadow on it, possibly many more for soft shadows.

So, 3.2 million times Lights times soft_shadow_samples times pixels times samples_per_pixel (and believe me, 10 samples each for the reflection and refraction is not very smooth in my experience!)

A veritable explosion of rays, as I am sure you see. I won't even begin to discuss radiosity, because that's actually slow, and computationally intensive. :)

Now, we get to the subject of Doom3... I'm not sure this hardware would actually be that well suited to Doom3. You know all the lovely shading effects, with detailed highlights and bump mapping? They pretty much define the Doom3 Experience. That all comes from a technology called programmable shading. Basically, while your GPU is rendering the polygons in the game, it runs a tiny little program that determines the precise shade of black for each and every pixel.

A raytracing accelerator takes advantage of the fact that ray hit-testing is a very repetative chore which can be done in hardware very efficiently.

But, as you can see, most of the really interesting rays in a scene are the "secondary rays." The rays that are for reflection and refraction and lighting and such. So, suppose this card calculates a ray, and figures out the point that needs to be shaded. Because the accelerator is all in hardware, for programmable shading like Doom3, it would need to hand-off back to the host processor, which would run the shader code, which would ask for 20 more rays, etc. So, with a fully fixed function raytracer, there would either be annoying limits on what the scene could look like, or you would constantly be going back and forth be

Re:Sweet deal!

[smokin_juan]

Shitcockhead? Hell, you've come the closest to actually adding anything interesting to the discussion!

That being said, you still didn't answer the questions I haven't asked yet (that someone else should've by now).
Why is there no (more?) hardware raytracing hardware? I saw someone else mention PovRay, I'm personally thining AutoCAD and Blender although the list goes on. I'm guessing that people other than myself (movie studios?) are using ray tracing to make images and assuming theres some market for it. Rendering those images can take better than an hour and I'd think that any increase in speed would be usefull to someone who does this sort of work on regular occasion. Why must I start rendering before I leave for work just to come home 9 hours later and find that the light I added didn't make a damn bit of difference 'cause it was set to 0!? I thought the free market was supposed to work better than this. Where's my hardware?

Re:Sweet deal!

[Anonymous Coward]

I'm not sure I've managed to explain myself very well, so feel free to call me shitcockhead, or whatever is popular these days.

Okay.

Hey, shitcockhead! It's only like the very first sentence on their website which mentions that they have a programmable shader implementation in the card:

Visit us at CeBIT 2005 in Hannover, Germany. In Hall 9, booth A40 we are going to present the new version of our Realtime Ray Tracing Hardware Solution featuring fully programmable shading and geometry on our FPGA based prototype.

Re:Sweet deal!

[Quelain]

Thanks for the explanation, very interesting.

If the complexity of the scene becomes irrelevant, I suppose you could throw bump-mapping out the window and have 'real' bumps.

Maybe there's a whole new bag of tricks waiting to be found for doing things the RT way?

e.g. If you have magic hardware to crunch through the geometry of all those rays, you could fake a 'soft' light source with a tight cluster of point
light sources.

Re:Sweet deal!

[Anonymous Coward]

The cool thing about ray tracing which you've failed to realize is that while you might need to cast 3.2 million rays, that is a FIXED number! If you have an empty room or a room with 1 trillion pollygons (that's way, way, less than doom 3 by the way), it will still take 3.2 million rays to render. So essentially, it will take the same amount of time to render regardless of scene complexity (this is of course a *major* simplification, it's technically log(n), but this is essentially constant).

Raster based rendering, like what is used for doom3 with a GPU, is VERY dependant on number of polygons, so as you increase the number of polygons, game will noticably slow down.

So if you want to have games with tons of polygons, ray tracing wins out over raster based rendering. And I think we would all agree that more polys is better :)

Performance

[MatthewNewberg]

On the Ray Traced Quake 3 Website it says that runs faster with more computers (about 20 fps@36 GHz in 512x512 with 4xFSAA)

Assuming that is correct,a normal chip can render Ray Traced Quake 3 like graphics at 2 to 3 fps on a 4GHZ machine which means the Ray Tracing Chip could do it at 6 to 9 fps. This might be real-time for alot of research, but when it comes to games anything less then 15 fps is a joke. I'll be interested when they can hit 30 fps, with more graphics complexity then Quake 3.

Re:Performance

[Anonymous Coward]

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.

Re:Performance

[timeOday]

It seems like raytracing would be ridiculously easy to run in parallel. If they're only 90 mhz chips, they probably don't take much power anyways. They should slap 8 of them on a board.

Re:Performance

[SunFan]

This might be real-time for alot of research, but when it comes to games anything less then 15 fps is a joke.

It probably wouldn't be a huge challenge for them to up their clock rate by 75% or so to get 15FPS. Imagine if they moved it from FPGA into custom silicon with appropriate chip designer voodoo.

Re:Performance

[dj42]

Well... it's not quite that easy. It's one thing to make one 90mhz chip. It's a different story to create a system around 8 of them==with hardware and software==to run in parallel. Maybe there is a reason Intel never made an 8x90mhz setup?

Re:Performance

[Anonymous Coward]

While Intel didn't make a chipset that would handle 8x90Mhz Pentiums (IIRC there were many 2x Pentium 1 servers), there were 8x and 16x Pentium Pro (200, 233Mhz) boards.

Raytracing is stupidly simple to parrallel, all you need is one common memory bank that can be accessed by all 8 RPUs (Ray Processing Units), and the code to do it... I mean, this would be so much easier to do than an 8 way (or even a 2 way for that matter) pentium setup that it's a joke.

Re:Performance

[MatthewNewberg]

Lets assume that they made this into a production model with the possiblity of running at 3Ghz.. (Which is about 6 times faster then a normal video card) and were able to put 4 times the number of processing units. Without considering the issues with memory bandwidth you still only have 1024*1024 video at 60 fps. This would be fine, expect for the fact that is using graphics from Quake 3, which is out of date(not to mention in the future).

Hopefully you will see that this technology isn't going to come around anytime soon. I do think new forms of rendering will come around, but that doesn't mean Ray-tracing will be it. From what I have seen in the graphics industry there is a trend to be putting more realistic forms of rendering in games. If you know anything about Ray Tracing, it works in reverse of real light. Ray Tracing casts rays from the camera, not from the light source. I see the future of rendering going towards the emulating light rays, how I dont know

Re:Performance

[beetlefeet]

The problem with simulating the rays of light is how on earth do you know which rays will ever make it to the camera? You'd have to calculate each ray and then throw out all the calculations that never make it to the camera, and how long are you going to trace them to find out if they ever do?. I have no real idea but I imagine for a fps only a small % of the total light would be useful

You can't reliably guess because the light could scatter, reflect, refract back to the camera after many interactions.

With tracing from the camera you are only rendering exactly what you need.

Although, I'm not a mathematician, could be wrong.

Re:Performance

[belarm314]

also from the site:
The main development was done by Daniel Pohl in less than six months with contribution for shading by several other students

This guy re-wrote the Quake3 engine to use raytracing pretty much by himself. I have serious doubts about his ability to optimize his OpenRT engine as well as id did the original engine (that is not meant as a slam towards this guy...id is comprised of people who can do things us mere mortals cannot). And, as pointed out by another poster, this is without on-chip algorithms. Ever run Quake3 in software mode?
While I agree this concept is not ready for prime time, it may not be as far over the horizon as it seems from the benchmarks.

Re:Performance

[Anonymous Coward]

For a discussion of forwards and backwards ray tracing, see here.

Re:Performance

[cheese_wallet]

I'll be interested when they can hit 30 fps, with more graphics complexity then Quake 3.

You consumers are lame. You need to start producing.

all aboard!!

[BlueJay465]

Hooray for consumerism! Where's the boarding platform again?

FINALLY

[Anonymous Coward]

Hopefully, this will help FPGAs to get some much-needed exposure. Their potential is obvious to me, as I think it must be to anyone who's been shown some of what they can do. (For example, this wiki article mentions that current FPGAs can achieve speedups of 100-1000 times over RISC CPUs in many applications.)

Every time I hear about the latest beast of a GPU from ATI or NVidia, I can't help thinking what a waste all those transistors are for anything other than gaming, and maybe a couple other applications. We should be putting those resources into an array of runtime-programmable FPGAs! Your computer could reconfigure itself at the hardware level for specific tasks -- one moment a dedicated game console, the next a scientific workstation, etc.

Lest I get too breathless here, does anyone care to inject some reality into this? Are there technological reasons why FPGAs haven't burst into the mainstream yet, or is it something else? Have I misunderstood their potential entirely?

Re:FINALLY

[PxM]

They're still Not Good Enough. FPGAs are faster than running software on a normal CPU, but they're still not as fast as running on pure hardware. While modern GPUs are programmable, they're still dependent on extreme hardware which is basically tons of simple circuits doing the same few operations. FPGAs are used when the system has to be more flexible than just 1) get vertex 2) transform 3) paint. Places like ATI do use FPGA systems when they are designing the hardware since it has faster turnaround time from design->test->debug than real hardware. However, these FPGA implementations of GPUs tend to be 1-2 orders of magnitude slower than the final hardware.

--
Free iPod? Try a free Mac Mini
Or a free Nintendo DS, GC, PS2, Xbox
Wired article as proof

Re:FINALLY

[captain igor]

I'm actually on a reconfigurable computing project, which focuses on this, the simple fact is that right now we don't have good methods for generating HDL for a given task, as well as lacking the necessary tools to properly swap tasks into/out of an fpga while maintaining a reasonable communication speed to them. It's being worked on, but it will take time to develop the tools, and even longer before software makers start using them.

Re:FINALLY

[EMIce]

I don't think he means that we should use FPGAs to do things that dedicated hardware would be much better for. FPGAs would allow today's computers to perform the tasks of many dedicated pieces of hardware, not quite at their level, but fast enough for enough applications to make it worthwhile. Increased versatility my friend, that is the reason.

An extra reason for the slashdot crowd would be the open source potential. Wide availability would attract developers to open source FPGA projects and could lead to some neat hardware in time. Including hardware that might not have been developed otherwise, as companies are reluctant to gamble on new technologies that don't have a clearly forseeable and sizeable market.

Re:FINALLY

[Spellunk]

You are right in your thinking, but it is quite tough to achieve.

There are a lot of hardware issues, such as pin assignment, that are tough to make work with every foreseeable process.

I have worked with high end FPGAs and also high end DSPs (fancy word for fast multiplying processor).

Without wasting a lot of time on a post to an older article, it should be done this way, but the labor ot write the software is prohibitive.

idea: try to get all those fanatical opensource coders on the bandwagon.

A lot of examples od MP3 decoding on FPGAs are available.

Re:FINALLY

[Sycraft-fu]

One interesting place I foudn them used is high end Cisco hardware. The 6500 series layer-3 switches feautre Altera FPGAs on many of their boards, as well as ASICs and general prupose CPUs. I've never been able to find out why, if it's just cheaper than an ASIC, given the (relitively) low volume of production or if they actually update what they do in the field with new firmware releases.

Re:FINALLY

[TDO48]

Not true about the small number of rewrite cycles: large FPGAs (e.g. Virtex, Apex) are SRAM-based: their configuration is stored in a memory and you can reprogram it as many times as you want. Smaller devices (e.g. CPLDs) or configuration controllers do have flash, and them have limited reprogramming capabilities.

Re:FINALLY

[Hast]

If you compare the actual processing capability of a high-end GPU and a high-end FPGA you will find that the FPGA is extremely slow in comparison.

A FPGA is on orders of magnitude slower than ASIC and also orders of magnitude more expensive.

The main reason you don't find FPGAs in PCs and such today is because there's no need for them. Most things a CPU can do "good enough" that it doesn't matter, and otherwise you can get special ASICs to do the job better and more economically.

And you will find that things like place and route takes a hideous amount of time which makes it even less useful for common applications. It certainly is a facinating prospect but it is still on the research level.

FPGAs are certainly neat and fun though. If you want to play with them you can get development boards for a couple of $100 which are useful for playing around.

high quality animation

[poopdeville]

This is great! I do work with an animation company, and a couple of these bad boys would seriously speed up our render times. The last video our lead artist did had to be rendered below 720x480 because we didn't have six months or a cluster of G5's. We've also been looking at buying time on IBM's supercomputers, but this might end up being cheaper in the long run.

Re:high quality animation

[mr i want to go home]

Renderman for OS X.

Re:high quality animation

[donglekey]

That does run on Macs, so does the lightwave renderer, maya and mental ray, but PRman hasn't been out long for OS X, I doubt there are very many G5 render farms running PRman out there (it would require buying alot of expensive macs and at the very least upgrades to PRman licenses) My point is that the post was very unrealistic and seems to be a mashing together of other slashdot stories.

Re:high quality animation

[Michael Snoswell]

You might look in to some test implementations that compiled Renderman into Pixel Shader language so it was implemented in hardware. There were problems (only 32bits fixed point I think). It was a few years back in a SIGGRAPH paper. Maybe the compilers have improved now to be useful. All renderers for 3D progs (softimage, maya, lightwave, 3dsmax etc) can work over a network. Most companies I've worked with on this have things set up to render overnight the latest version of the scenes being worked on. Many seem to be moving to linux for the workstations as it's good at most of the popular 3d tools (except Max I think) and is so much easier to control for batch processing, scripting etc. Look at BMRT for a start if you don't like your renderer.

Saarland...

[Goonie]

It's really interesting to see that this comes from the University of Saarland. Saarland is a rather out of the way part of Germany, near the border with France and Luxembourg.

It's rather pretty in a European countryside kind of way - hills with wine grapes on them, big rivers with boats cruising up and down, and big vegetable gardens everywhere (Germans sure love their vegetable patches) - though I doubt it's the kind of place too many international tourists visit. Not the kind of place you'd expect cutting-edge graphics research either; but then, you find all manner of interesting research in all manner of places. Even Melbourne, Australia :)

Hi to any residents of Saarland reading this - are they holding the German round of the World Rally Championship there this year?

Re:Saarland...

[mattkime]

...and Cray was located in LaCrosse, Wisconsin.

(another place where bratworst are consumed)

Re:Saarland...

[O]

I think you meant Chippewa Falls, WI. Also home to Leinenkugels.

Mmmmm, beer.

Re:Saarland...

[thomasweber]

Well, your description of Saarland is a little bit too good (I am sitting in the same building as the graphics group). There is only a small part where wine grapes are planted (I come from there) and there are actually only two big rivers (the "Saar" - yeah, I know, big surprise and the "Mosel", where the wine region is). To give the rest of /. a measure - the Mosel has approx. 10 km in the Saarland, afterwards it continues in Rheinland-Pfalz.

That said, it sure is a nice area.

About your rally - I am not sure, after reading on wrc.com it will surely be close; but I don't know wether it's really in Saarland.

Okay, I checked (http://www.rallye-deutschland.de/). There will be part of it in Saarland (St. Wendel), but I doubt you will see the Saar.

Re:Saarland...

[doktor-hladnjak]

The Saarland may be an out of the way part of Germany, but the Computer Science Department there is one of the best in Europe, especially with regard to fundamental research. In addition to the CS Department, on campus there's the German Artifical Intelligence Research Center (DFKI) and the Max Planck Institute (MPI) for Computer Science, which both contribute to the research stature of the place. They're also planning to build a new MPI for Software Engineering at some point in the not so distant future there.

As for the geographic location, I'm not sure it's as beautiful as you're making it out to be. Saarbruecken is possibly one of the ugliest cities in the former West Germany and much of the surrounding area is dotted with steel mills and coal mines (many closed now though). There is some nice forest land though.

I lived there for almost two years, doing my MS in graphics (although I was associated with the group at the MPI, not the one mentioned in the article). Interesting place to be for sure.

The "Q3RT" screenshots...

[Lisandro]

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

Re:The "Q3RT" screenshots...

[Ziviyr]

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

That is pretty sad. Because I'd be thinking about shooting a laser rifle at that ref(le|ra)ction an seeing what happens!

Game rule 1, no direct shots of the enemy!

Fun fun.

Re:The "Q3RT" screenshots...

[utexaspunk]

movie here.

Re:The "Q3RT" screenshots...

[Lisandro]

Great link! Thanks!

A Boeing?

[mnemonic_]

A Boeing rocket, aircraft, missile, spacecraft or what?

Re:A Boeing?

[The boojum]

There's a standard model of a Boeing aircraft (777, IIRC) that's used as a something of a test scene in the computer graphics community. It's about 350M triangles (everything down to nuts and bolts, but modified so as not to give any trade secrets away) and over 4GB of data, so it gets used a lot for testing how the performance of an algorithm scales to large datasets.

Re:A Boeing?

[espek]

Is there a picture of this some place where I can just see a jpg of what the plane looks like? I'm a bit of an airplane nut.

Re:A Boeing?

[TheGuano]

Earth to Mnemonic. They're obviously talking about a David Boeing. Duh.

Re:A Boeing?

[The boojum]

Try http://graphics.cs.uni-sb.de/MassiveRT/boeing777.h tml when they're no longer being slashdoted.

Re:A Boeing?

[Anonymous Coward]

Boeing teapot.

Re:A Boeing?

[mobby_6kl]

CEO

How, Exactly?

[Musc]

Would you care to enlighten me as to what exactly ray tracing brings to the table, above and beyond what we already get from a state of the art GPU?

Only thing I can think of is that ray tracing would
allow us to replace complicated hacks for shadows
and reflections with a more natural implementation, but I can't imagine how this will usher in a new era of gaming.

Re:How, Exactly?

[The boojum]

How about non-tesselated geometry? You can have high detail curved surfaces without turning everything into a dense polygon mesh. That in turn lowers the memory and rendering requirements so you can apply those resources to proper detail instead.

Or how about global illumination lighting effects? Truely emissive surfaces and area lights? As a hobbyist map maker, I would kill to have an engine that supported these; imagine being able to just tag the sky as an emmisive surface and have the entire level lit up and shadowed accordingly without having to painstakingly add bounce lights everywhere and tune them till they looked correct.

Another good argument that I've heard is based on the complexity of the algorithms. GPU style rendering is inherently order O(n) on the number of items in the scene. While ray-tracing has a high constant factor, a good ray tracing acceleration structure makes the problem O(log n) -- as the scene grows the time to ray trace gets closer to the time to GPU render it. Admittely you can do much the same with the GPU: there's a lot of stuff like BSP trees and bounding volume heirarchies and frustrum culling that you can do to speed it up, but then you're already applying ray-tracing techniques anyway, and now you're really talking about something that's more of a hybrid with the CPU just doing the ray-tracing part.

Re:How, Exactly?

[Sycraft-fu]

Actually, raytraced shadows look like crap, at least in the classical sense. Classical raytracing is done by tracing rays back from the pixels to light sources. Works fairly well, but you find the images don't look right. There's a number of things that are generally problematic but the shadow one is that shadows are hard.

You have to use a different kind of rendering to get soft shadows and proer reflection. Radiosity is a popular method. Basically you treat all objects as light sources, after a fashion. Light hits an object, you calculate the relfections from it, then from that and so on. Gives nice, soft, fairly realistic results... But of course is an ironclad bitch in terms of processing time. It's an iterative process, you have to do multiple reflection passes, and the more you do, the more realistic it looks.

Really, when you get down to it, ray tracing isn't really that exciting anymore. As you note, GPUs do a better job now with the tools they have. It is, perhaps, less correct in the mathematical sense and more of a "hack" but that doesn't matter. It's all about making things the most realistic/pretty the fastest for the least cost.

So I agree, neat technology, and probably not useless, but I'm not seeing it for videogames.

Re:How, Exactly?

[Ford Prefect]

Or how about global illumination lighting effects? Truely emissive surfaces and area lights? As a hobbyist map maker, I would kill to have an engine that supported these; imagine being able to just tag the sky as an emmisive surface and have the entire level lit up and shadowed accordingly without having to painstakingly add bounce lights everywhere and tune them till they looked correct.

Erm... Half-Life has been doing these (with full radiosity too) since about 1998 or so, using code based on that which went into Quake 2.

Yes, it's all done with precalculated lightmaps and is therefore terribly old-fashioned, but it's still my favourite lighting model in terms of practical realism. I'm not sure raytracing is necessarily the right route for a fully dynamic version of this - my experiences with POV-Ray and radiosity, for instance, were time-consuming to say the least...

Re:How, Exactly?

[SammyTheSnake]

Actually, raytraced shadows look like crap, at least in the classical sense. Classical raytracing is done by tracing rays back from the pixels to light sources.

[...]

Radiosity is a popular method.

Another method used more recently is called photon mapping, in which the illumination of the scene is calculated by ray-tracing from the light source to the various surfaces, via reflection / refraction etc.

It's kinda like the next step on from radiosity calculation (in both efficacy and how much of a ball-ache it is on the processor!) but the single greatest effect is that you can calculate accurate caustics (ever see the strange light patterns cast by a glass of water on the desk? or the wavy patterns on the bottom of a pool?)

The results can be truly stunning. Incidentally, the round silvery that turns up as the 16th hit from where I'm searching from is exactly the same as the one I bought from ikea several years ago...

Cheers & God bless
Sam "SammyTheSnake" Penny

Price.. and compile time

[xtal]

Unfortunately the price is an order of magnitude (or two.. or three) too high for FPGAs to really be a consumer tech. The issue I think is an ASIC costs so little in volume, rather than spend all the money on an FPGA design that might be obsoleted next year anyway - a vendor is more likely to commit a design to silicon and then sell that.

There's also the speed issue - I've spent DAYS of CPU time to get a design syntheized from VHDL for a moderately complicated IC built up from available cores.

Factor in optimizing floorplans and the like, and you're talking about serious time commitments to optimize the hardware.

It works; I've been paid to do it in the past; but it's not something I can see in the consumer market for the time being.

An exciting hybrid is intersting though, putting silicon CPU cores on the same die with an FPGA. They've been around for awhile, and I haven't done any FPGA projects in ~18 months - but I haven't seen any real movement outside of areas where FPGAs are already popular.

See Open Cores (no, not sores.. :-) ) if you're interested in this - there is open source hardware out there, some really good designs at that.

Research not meant to be immediately practical

[Goonie]

Look, if it was production-ready, it wouldn't be research.

While it's certainly not enough to start playing games, it's a heck of a lot closer than I thought was possible. And there's a lot of tweaking that could be done to speed the process up with present technology. An FPGA is the integrated circuit equivalent of a stack of lego. It makes it possible to build custom hardware without forking out for a custom chip; they are however much slower than such a custom-built. I expect if Nvidia decided to make their next-generation chip a raytracer they could get your 30fps. They won't do that for a while yet though - 512x512 is a long way off the resolution gamers currently play in.

But this is interesting, even though it's not practical yet, because it puts the idea on the table that, in the not too distant future, real-time raytracing might well be a possibility. From here, the big graphics-chip makers can start seriously thinking about it, and, maybe about 5 years from now the first hardware raytracers will begin to appear in 3D graphics cards.

Do you know what an FPGA is?

[fireboy1919]

You're to be describing this as if it's some kind of custom hardware with many limitations.

This could not be further from the truth. FPGAs are more flexible than any of their counterparts. FPGA stands for "field programmable gate array," and are basically a matrix of memory elements (at the very least latches) connected to gates that configured to be a particular type of gate via a ROM or something similar.

It's kind of like a chip emulator written in hardware. You may be wondering why we don't use these all the time. First, they're a lot more expensive, bigger, and more power consuming than their one-chip cousins. Second (as if that isn't really enough), they're usually 2-5 times slower than the same logic on a custom chip.

So the big question is why should we use them? What improvements can they give that normal chips can't?

The big gain is when you want to optimize the hardware for a specific application and be able to change it. These were used in high end digital video cards to be able to handle whatever kind of signal is actually output by whatever kind of camera you've got (I can only assume this is still the case, but I stopped keeping track about 2000).

I don't know if the people who wrote this thing take advantage of this idea within their design, but it's a possibility.

Re:Do you know what an FPGA is?

[TLLOTS]

Thanks for that, I wasn't aware such things as that existed (I couldn't be bother to RTFA ^^;). Quite interesting to say the least. It'd be nice if it were possible to eventually make such devices with much better performanc that they were actually viable alternatives, though more than likely their ASIC cousins will always have too much of an edge in efficiency (feel free to correct me if I'm wrong here, as I'd like to be). It's a shame too, it would be very cool to have one chip for your computer which you could configure for any number of different tasks. What I'd actually do with it I don't know, but it'd be cool :P

Re:Do you know what an FPGA is?

[Mortlath]

Hmm, I assumed that they had used a FPGA because it was only their prototype board.

From what I've learned in one of my digitial system design courses from college, ASIC have an upfront production cost of $1,000,000 to $2,000,000 and a small unit price, while FPGAs have a much lower fixed cost (~ $10/unit).

So, I imagine they will manufacturer ASIC chips when they get a big sponser, unless they are using the FPGAs dynamic abilities...

Re:Do you know what an FPGA is?

[Spellunk]

Absolutely right.

wait, i have nothing to add.

ohhh, ok, i remember. Don't think the performance is from the FPGA. It is from having all the algorithms done in hardware (transistors, heh). FPGAs are the perfect prototype board for stuff like this (as mentioned above).

I seriously doubt they are using the FPGA's dynamic abilities.

for example, MP3 decoding takes a decent DSP a dedicated 30ish MHz to perform. Or you could go buy an ASIC from ST microelectronis for $7 that will do it all day with almost no intervention.

Re:Do you know what an FPGA is?

[oliverthered]

Well, raytracing is all about root solving, if they tweek the FPGA to match the scene they are renderin then they could get a good performance increase.

I'm looking at doing a simila thing to the DirectX 9 pipeline in Wine (well not a FPGA) but compiling some one the pipeline on the fly with self modifying code, there are inner loops that look like this.

if(a & 1){
blah
pointer1+=data1->size;
}
if(a & 2){
pointer2+=data2->size;
}
if(a & 3){
pointer3+=data3->size;
}
etc....

self-modifying code would get rid of the if statements and datax->size's etc.., and could possibly use vector processing such MMX &co, making the function run ten times faster or more.

to write the equivilent out in c code you would need a different function for each possible case, which would make for a massive staticly compiled binary.

Re:Do you know what an FPGA is?

[Montag2k]

Another reason that people don't use FPGAs that much in consumer applications is the security of the IP on the FPGA. They are loaded on power-on with a PROM chip and it is a somewhat trivial task to read the entire contents of the FPGA at power-on. This would be a nightmare for companies like Nvidia and ATI, who value their custom hardware.

Fortunately, there are some companies that are incorporating flash memory on to their FPGAs instead of using the standard SRAM. The problem is that flash-based FPGAs are usually a few generations behind SRAM-based FPGAs in terms of die size (and henceforth storage space and speed).

I think that as flash-based securable FPGAs become more popular, cheaper, and less power consuming, we'll start to see cards for the computer that come with completely configurable hardware.

-Montag

Re:Do you know what an FPGA is?

[Retric]

I don't realy have time to look at it right now but if I rember correctly you can do something like this.

if(a & 1){
functionptr = &fucnctionA1;
}
if(a & 2){
functionptr = &fucnctionA2;
}
...

while (...
for (..
functionptr(pointer, data, size);

Sorry, it's been a while sence I looked at C code like this but it works and can work great both as a speed optimisation and to clean up your code some. If you use a lot of conditionals thouought a function that evovled with a lot of extra clutter. It's not quite as fast as 100% custome code because your using a function but it's worth taking a look at if there are a lot of conditionals inside your loops.

Re:Do you know what an FPGA is?

[oliverthered]

Except it's bit wise, you'll need

functiona1b0c0d0
functiona0b1c0d0
functi ona1b1c0d0
functiona0b0c1d0
functiona1b0c1d0
fu nctiona1b1c1d0
functiona0b0c0d1
functiona1b0c0d1
functiona0b1c0d1
functiona1b1c0d1
functiona0b0 c1d1
functiona1b0c1d1
and finally...
functiona1b1c1d1

that's just for 4 conditionals, try it with 16 and you need to multiply the size of you code base by 64000, with vertex shaders, blends and tweening there'll be even more.

Do it self modifying, and you just drop the functions out of cache when they are no longer required.

The functions ends up something like

function=generateFunction(a,b,c,d,e,f)
*function(a,b,c,d,e,f)

generateFunction looks like this
generateFunction(a,b,c,d,e,f){
if(!supported(processor)){
return staticfunction;
}
if(chached(a,b,c,d,e,f)){
return chached(a,b,c,d,e,f);
}
return compilefunction(bytecode,a,b,c,d,e,f);
}

Re:Do you know what an FPGA is?

[oliverthered]

Just because you don't like .NET or Java it doesn't mean that it's the devil.

Re:Do you know what an FPGA is?

[Retric]

Ok if was realy 64000 options then the code would be huge anyway. Don't forget your realy only adding a wrapper around existing code so what your doing is adding some constant K times the amound of code your already dealing with. Let's say your code looks like this now: Loop1 {loop2{ If (A) { if (B) { if (C) { ... } else [...] } else { if (C) { ... } else [...] } else if (B) { if (C) { ... } else [...] } else { if (C) { ... } else [...] } } Than all you do is cut and past the conditionals above the loop and add one function for each { ... } case. Now self moding code works best when you have the more complex vertion of this aka. If (A) { ... if (B){ ... if (C) {...} else {...} ... ... }else { ... if (C) {...} else {...} ... } ... } Where you would need to replecate the same code in more than one fuction. It all realy comes down to what the code base looks like now and how fast you need it to become. If you need to use self moding code for space reasons that's one thing but a lot of these type of things are handeld by a good optomising compiler. AKA you could write int A = 27; For (int B = 1; B 10; B++) { int C = 10 * A + B; Fark(C * (30 + 9)); } and it might compile into the same code as int A = 27; int C; for (int B = 1; B 10; B ++ C = 270 + B; Fark(C *39); } PS: Don't forget using inline functions can save a lot of time even if they produce more code.

Re:Do you know what an FPGA is?

[BoneyM]

Both Xilinx and Altera (who have the high-performance end of the market sewn up between them) allow you to encrypt your configuration bitstream, so design security is not a huge problem any more

Re:Do you know what an FPGA is?

[Retric]

Ok if was realy 64000 options then the code would be huge anyway. Don't forget your realy only adding a wrapper around existing code so what your doing is adding some constant K times the amound of code your already dealing with. Let's say your code looks like this now: Loop1 {loop2{ If (A) { if (B) { if (C) { ... } else [...] } else { if (C) { ... } else [...] } else if (B) { if (C) { ... } else [...] } else { if (C) { ... } else [...] } } Than all you do is cut and past the conditionals above the loop and add one function for each { ... } case. Now self moding code works best when you have the more complex vertion of this aka. If (A) { then some code the if B then some more code } else { then some code the if B then some more code } Where you would need to replecate the same code in more than one fuction. It all realy comes down to what the code base looks like now and how fast you need it to become. If you need to use self moding code for space reasons that's one thing but a lot of these type of things are handeld by a good optomising compiler. AKA you could write int A = 27; For (int B = 1; B 10; B++) { int C = 10 * A + B; Fark(C * (30 + 9)); } and it might compile into the same code as int A = 27; int C; for (int B = 1; B 10; B ++ C = 270 + B; Fark(C *39); } I have seen code generation work realy well in a case where the same few conditionals showed up in the same function several times aka if ( PPC cpu) ShowPPC else ShowNonPPC ... if ( PPC cpu) ShowPPC else ShowNonPPC ... I was more trying to point out that you can avoid the cost of all those if statements and clean up your code without going to self modifying code, which can easly turn into a huge mess. PS: Don't forget using inline functions can save a lot of time even if they produce more code.

Re:Do you know what an FPGA is?

[Retric]

3rd times the charm...

Ok if was realy 64000 options then the code would be huge anyway. Don't forget your realy only adding a wrapper around existing code so what your doing is adding some constant K times the amound of code your already dealing with.

Let's say your code looks like this now:

Loop1 {loop2{

If (A) {
if (B) { }
else { }
} else {
if (B) { }
else {
}
}

Than all you do is cut and past the conditionals above the loop and add one function for each { ... } case.

Now self moding code works best when you have the more complex vertion of this aka.

If (A) {
then some code
the if B
then some more code
}
else
{
then some code
the if B
then some more code
}

Where you would need to replecate the same code in more than one fuction.

It all realy comes down to what the code base looks like now and how fast you need it to become. If you need to use self moding code for space reasons that's one thing but a lot of these type of things are handeld by a good optomising compiler. AKA you could write

int A = 27;
For (int B = 1; B 10; B++)
{
int C = 10 * A + B;
Fark(C * (30 + 9));
}

and it might compile into the same code as

int A = 27;
int C;
for (int B = 1; B 10; B ++
C = 270 + B;
Fark(C *39);
}

I have seen code generation work realy well in a case where the same few conditionals showed up in the same function several times aka

if ( PPC cpu)
ShowPPC
else
ShowNonPPC ...
if ( PPC cpu)
ShowPPC
else
ShowNonPPC ...

I was more trying to point out that you can avoid the cost of all those if statements and clean up your code without going to self modifying code, which can easly turn into a huge mess.

PS: Don't forget using inline functions can save a lot of time even if they produce more code.

Re:Do you know what an FPGA is?

[Montag2k]

I think that one of the security problems is related to the actual storage of the data on the FPGA. Since SRAM is used on Altera and Xilinx FPGAs, it could theoretically be read off of the chip after it has been configured.

However, this triple-DES stuff is interesting. Another factiod that I picked up is that Actel FPGAs are the only ones that can include an ARM soft core because ARM does not trust the SRAM-based FPGAs to keep their IP secure.

-Montag

Re:Do you know what an FPGA is?

[oliverthered]

What?

there are 64000 for any 16 bit number.

for(a=0;a10){
if(a & 1){
total +=dob;
}

if(a & 1 1){
total +=doc;
}

if(a & 1 4){
total +=doe;
}

}

etc... produces 2^n possible outcomes, but you so only need 16 if's to make 64000 options.

There's a bit more to it than that, but lets say I run that loop or 10000 items 10 times a second times a second, but it's alyaws going to take the same patch a a = 5, by compiling just the a = 5 version on request I can save a lot of derefernces, that my cause page faults, all my if's and make sure everything is nicely aligned etc....

Re:Do you know what an FPGA is?

[oliverthered]

here's my code

lea eax, [sp + 2]
lea ebx, [sp + 4]
test [eax]
jnz dontdothis
push [123455]
push [eax]
call dosomething
test [ebx]
jnz dontdothiseither
call dosomethingelse

etc.....

all the flags are unique, say colour, secondry colour, tweening, vertex buffers type 1, vertex buffers type 2, pixel shaders , pixel shaders, normals, binormals, tangents, skinning, textures, non-power of two textures, etc...

Re:Do you know what an FPGA is?

[ghereheade]

More of the engineering development equation...

As FPGAs are reprogrammable, they are often used in developement to try out and debug code (for hardware like this, Verilog and VHDL are very common). On the other hand, ASICs run faster as they are custom built for the specific application (thus the name Application Specific IC). So some trade offs:

The FPGA can be put on the board and reprogrammed thousands of times. The ASIC is what it is when it's built.

FPGAs are more power hungry than ASICs.

Typically an FPGA uses a larger die than an ASIC (that means it costs more). The larger die might also require a larger package (a problem for space constrained designs). That's part of the penalty for reprogrammability.

I can buy 1 or 10 or however many FPGAs for relatively small money. ASICs cost $$$ up front for mask sets and then you have to buy thousands.

I can get FPGAs in days after ordering. ASIC lead times are typically 10+ weeks (if you're a big player, small players could wait 16+ weeks).

When you think of total program cost, that makes FPGAs good for prototype development, small production runs, and systems that will need periodic updates. The ASIC market is suited to applications where the hardware design is stable and the production will be many thousands of units.

Re:Do you know what an FPGA is?

[Retric]

Just wondering where you are with this. I had been asumeing you where using C but looking at a snipit of ASM code I realy don't know what to say. If your going to look at this as a hobbie then feel free to deal with this as down and dirty as you want to. I was trying to point out a type of optomisation that might be usefull but if your going so far as to use ASM code I think your on the right path.

Unfortunately....

[geofforius]

Their server also runs on a 90MHz processor

from cavemen to aristocrats

[Threatis]

wow, hard to believe how far we've come in so little time..... from two "paddles" and a "ball" on a 10 by 10 inch screen......too a 350 million polygon superjet.

What kind of FPGA?

[brandido]

Working with FPGAs, I was quite curious to find out what kind of FPGA they are using - both Xilinx and Altera have some advanced hard functions (such as Multiply Accumulate functions, Block RAM, etc) that seem like they could have a huge impact on the abilities of this board. Unfortunately, after browsing through the links, I had no luck in finding any information about what FPGA they are using. Was anyone able to find this out? Even looking at the pictures of the board, it only shows the bottom side of the board, so it is impossible to see the chip markings!

Re:What kind of FPGA?

[k0ft]

Unfortunately, after browsing through the links, I had no luck in finding any information about what FPGA they are using. Was anyone able to find this out? Even looking at the pictures of the board, it only shows the bottom side of the board, so it is impossible to see the chip markings!

I work with a lot of fpga's, and while the view of the chip sucks, it's defintely a xilinx chip. Altera and Xilinx use a different pack design.

Re:What kind of FPGA?

[fizze]

also view: http://science.slashdot.org/comments.pl?sid=142507 &cid=11941863

it's a virtex II 6000-4
from some pdf at http://www.saarcor.de/pubs.html

raytracing with 350 million polygons?

[Speare]

Are you sure the Boeing thing was raytracing 350 million polygons? Or just traditional raster pipeline rendering?

See, the reason I ask is, you generally get away from raytracing polygons and raytrace against the actual nurbs or other mathematical surface definitions. That's the point. You don't feed it to simple scan-and-fill raster pipelines.

Re:raytracing with 350 million polygons?

[The boojum]

I can't speak for the chip yet, but I've read the papers on their software system and know that it gets a good part of its speed by rendering triangles only. The secret is that they have a cleverly laid-out, cache-friendly BSP tree of the triangles and their code uses MMX SIMD instruction to intersect 4 rays at a time with the triangles in the tree. Rendering triangles only lets them get away with a more compact (and therefore more cache friendly) memory structure and lets them avoid the performance penalty of switching or [vtable] dispatching on object types -- it's all one very tight loop to walk the tree and intersect triangles.

Re:raytracing with 350 million polygons?

[donglekey]

Most ray tracing renderers trace triangles. Blue Sky's CGI studio is the only renderer that I have heard of that traces nurbs surfaces directly.

Re:raytracing with 350 million polygons?

[photon317]

If it's true that they're only tracing triangles, then this isn't "real" raytracing to me. I'm sure it will be cool and useful, but there's a lot of things you can do with ray tracing that require more than triangles. Raytracing against solid objects with intersections and whatnot (ala Povray) can do a lot of things that this can't (like correctly render a crystal sphere with something behind it). I do hope hardware raytracing takes off though. The 3D we have to day is all an optimization hack, hence the unrealism. The path to photorealistic VR is so obviously Raytracing, we just aren't there yet in terms of speed.

Re:raytracing with 350 million polygons?

[cjameshuff]

Except that POV-Ray is not "Open Source" and it doesn't support direct rendering of NURBS...

Sleeping

[GerbilSocks]

Wake me up when they introduce a 3D Radiosity Chip.

Anti-Planet

[KalvinB]

Anti-Planet Screenshots. Anti-Planet is a FPS rendered entirely using ray tracing. It requires an SSE compatible processor (PIII and above. AMD only recently implemented SSE in their processors). This has been out long before Doom 3 and runs on systems Doom 3 couldn't possibly run on and the graphics tricks it does are just now being put into raster graphics based games.

That, along with Wolf 5k inspired me to start working with software rendering. I think ray tracing will eventually be the way real time graphics are rendered in order to keep upping the bar for realism.

Real Time Software Rendering

I'm working on tutorials covering software rendering topics. The tutorials start by deobfuscating and fully documenting Wolf5K, cover some basic ray tracing and are now going through raster graphics since the concepts used for raster graphics apply for ray tracing as well. I'll be returning to do more advanced ray tracing stuff later. The tutorials also cover an enhanced version of Wolf5K written in C++ that is true color and has no texture size limitations.

Re:Anti-Planet

[Lisandro]

Anti-planet looks cool. It reminds me of an old DOS game (the name escapes me) where the characters were all made based on ellipsoids: since they look as an elipse from every point of view it worked very well (and fast - quite faster than plain polygons IIRC) in the limited hardware back then.

Re:Anti-Planet

[bani]

amd only "recently" implemented sse? they've had it since 2001.

more recent amd chips have sse2, and sse3 on amd64 is just round the corner.

Re:Anti-Planet

[msormune]

You may be thinking about the game Backlash made by Paul Woakes. Indeed a very cool considering the hardware limitations back in the day...

Re:Anti-Planet

[RichardX]

Hey! I know the one you mean!
It was quite dark and violent, wasn't it? like an RPG or adventure or something.. I remember there was a bit where someone got impaled on spikes.
I've got a feeling it was named for it's graphics - something like "ellipsia" or "sphereworld" or somesuch

Re:Anti-Planet

[Zelgadiss]

Ecstatica?
http://www.adventurecollective.com/reviews/ecstati ca.htm

Re:Anti-Planet

[Lisandro]

It might have been Ecstatica 1 & 2 by Psygnosis.

YES! I kept thinking it was an Infogrames game, but those were the "Alone in the dark" series (also great).

Re:Anti-Planet

[RichardX]

That's the one! Thanks
Okay, I was a bit off with the name, but it's been a very long time :)

FPGAs are not a good tradeoff

[idlake]

You need about an order of magnitude more transistors to do something with an FPGA than to design a special chip for some task. That makes it an order of magnitude more expensive, too, and consume much more power. And even then, it won't run as fast as an equivalent hard-wired chip.

People build special-purpose chips for the mass market because it's the cheapest way of getting the functionality out.

And as general purpose computational devices, FPGAs are just too hard to program and too inflexible.

Re:FPGAs are not a good tradeoff

[aminorex]

But specialized chips don't get economies of scale. 1000 Asics chop up the marketplace into 1000 little tiny slices, while an FPGA solution could handle all of those cases, aggregate the market, and have production runs 1000 times as large. That would pull the per-unit cost of the FPGA solution down by an enormous factor.

Re:FPGAs are not a good tradeoff

[idlake]

But you only get economies of scale after you have found a large population of initial adopters willing to pay a premium for this kind of hardware. Their money is then used to build the large, efficient factories and amortize the development costs. I don't see that happening with FPGAs.

I think the cell architecture has a better shot at this (it's a bit more parallelism and configurability than a regular chip, but already a lot harder to program), but even with that, I remain doubtful that it makes the right tradeoffs.

M*O*N*A*C*O

[(3067)]

I wonder if there are any scientific applications that graphic algorithms can be put to other than graphics? Does anyone know of any cross-over application that would find fast processing of these types of algorithms useful? M*O*N*A*C*O

Surprising

[alehmann]

I was under the impression that real time raytracing was still far from practical. I know that Pixar's Renderman uses a much more efficient algorithm, and it still takes on the order of hours to render a full-format movie frame on beefy hardware (I know that's large, but raytracing should scale fine, and we aren't talking about millions of times more pixels). IIRC they use a raytracer only when they need reflections, and those frames are extremely expensive in terms of CPU time.

Re:Surprising

[cheekyboy]

Cannot they use one cpu or machine per raster line, ie 1080i needs 540 cpus or 270 dual P4s/G5s.

To render 2048 pixels in 41milliseconds shouldnt be too hard, thats 49 pixels in 1ms. About 1/1000th of 3ghz cpu which is about 2.5million instructions, or 51000 per pixel.

Though pixar has lots of money, and instead of just buying 270 G5 servers, they could make their own FPGAs to do it.

Re:Surprising

[iduno]

If you have a look at the sample pictures they aren't extremely detailed compared to that used by pixar. To get something running near real time at the quality pixar uses you would need hundreds, if not thousands of better and more expensive FPGA's running concurrently to produce a reasonable frame rate. Considering some FPGA's can cost around $1000/piece for the better ones, this could make it too expensive to put together something at the present. While FPGA's are good for designing hardware to handle ray tracing, it would probably be cheaper to design and build a custom chip to do real time ray tracing that would be suitable for commercial use.

Re:Surprising

[The boojum]

Interesting bit of history: According to "Advanced RenderMan", Pixar's RenderMan started out as a project to build a hardware renderer. The algorithms were prototyped in software on general purpose machines which ended up overtaking the hardware project on price/performance and the hardware was abandonned.

Re:Surprising

[SuiteSisterMary]

Part of the problem is shuffling around the 50+ gigabyte scene files, the textures, and so on.

Re:Then vs Than

[Craigj0]

So you rarely read an entire Slashdot comment?

Mirror to video

[DesiVideoGamer]

Here is a mirror to the video.

I seriously thought PS2/Emotion engine wud do this

[cheekyboy]

When the magic emotion engine of ps2 was announced, I thought, hmmm are they going to for once try realtime raytracing in hardware or cont with tired old polygon rendering.

Imagine if nvidia threw in an extra 5m transistors for a raytracing option ;)

Re:Then vs Than

[vga_init]

Are you sure it's accurate to judge a person's intelligence by the presence of a typo? I know grammar fairly well myself, and even I type out some horrendous things from time to time--[near] homophones (such as "than" and "then") are more likely to cause problems than anything else; sometimes I type "your" instead of "you're", but I know the difference well enough if you were to ask me.

Why not just overlook such a simple thing and judge the article by its subject matter? No need to go off on a rant and put some poor person down. =)

Don't you think it's an interesting chip?

Re:Then vs Than

[The Journalist]

"comparisson"

Suppose I point out it's "comparison"?

"Really, it may seem petty, but glaring grammatical errors like this are an immediate turn-off. I read stuff like this and immediately assume the author is a nitwit and don't bother reading further."

Could not have said it better myself.

why not old crap pcs are clusters

[cheekyboy]

Why not gather up some old crap PCs, 1ghz or 1.8s, build a stack of 10-20 of them ($299 * 10) and install linux/povray on em all or whatever you use.

Hell, even 20 chipped xboxs ;)

Re:why not old crap pcs are clusters

[PantsWearer]

There's a simple answer to this: Those people are expensive.

For small firms, the cost of a few dozen PCs in a render farm is far less than paying one person with those sorts of talents. This is basically true for all businesses. Machines are cheaper than people by far.

I've done small scale 3D animation. When I say small scale, I mean small: It's just me. It's just a side job I've done on occasion, so I don't have time to learn all the ins and outs of renderman. Why should I have to write up shadow maps and reflection maps when all I have to do is place light sources and put my textures on my geometries and then let the thing go? Sure, it may take 10 hours to raytrace compared to an hour on renderman, but my man-hours were a heck of a lot shorter. And since it's only me, I can just let it go overnight.

Heck, in the past, because raytracing is so parallelizable, I've actually run different parts of an image on different machines and slapped them together at the end, just for the speed-up. Of course, this was back in the days of 486s.

raytracing

[Anonymous Coward]

Raytracing scales linearly with processing power, but only logarithmically with scene complexity.

raytracing advantages

[bani]

afaik the advantage of raytracing is that you are no longer bound by polys though. you can easily have unbelievably complex scenes with little performance impact vs simple scenes. your bottleneck is no longer polys/sec but now rays/sec.

and iirc raytracing is a very simple thing to parallelize. given the performance they are getting out of their FPGA prototype, I expect this will scale nicely.

imo raytacing is the obvious future of graphics cards.

as an aside, a lot of game mechanics is dependent on raytraces for detecting collisions. now if you could use a raytracing GPU to handle that as well, you've offloaded yet more work from the CPU... :-)

Re:raytracing advantages

[BayBlade]

Just so we're clear, the current hardware raster techniques are also a very simple thing to parallelize in a number of different dimensions.

For a simple example, have 1 card render 50% of your polys, and another card the other 50%. Combining the output of one into the other runs O(n) where n is the number of samples on screen (pixels) since all you need to do is compare z-buffers.

For another simple example of parallelism, I point to tile-architecture techniques such as the one used by the KRYO II.

There are others.

Ray-tracing will never go away as it provides a very simple technique of rendering implementation, and also provides an excellent model for physics simulations of reflection/refraction, but it is seriously lacking compared to other techniques employed today. (wrt overall visual quality)

This hardware is cool because it lets RT happen faster, but I doubt it is ushering in the future of gfx cards.

Re:all aboard!!-Geek Orgy Express.

[BlueJay465]

As a geek myself, I was being sarcastic....

jeez...nerds have no sense of humor

/.ed

[aldeng]

Looks like they were running thier webserver off one of those cards. *rimshot*

SFA in melbourne

[cheekyboy]

Yeah, melbourne has nothing but tonnes of finance companies , call centres and medical/ lawer companies, no real research , oh and a .au registra.

Sure theres a handfull of gaming companies though to get in that line of work you already have to have been in a team that made a game or 2 or 3 and have a degree (how many degree people know gaming?) I know companies want quick results with no trainups, but comon, if someone already has done 3 games, then they are probably burned out tired from that type of work, get some newbies that are fresh and eager and have no hangups.
The rest are either writing crap games for casino machines or a handfull of defense type jobs that want the utmost of specific experience.

Unless someone has some cool techy jobs give me a call/email (10yr+ exp here itching for some tech inventing) My past efforts will impress you.

experienced in win32/mac/linux , including assem, embedded and end user pro-apps.

Back to hard labour.

Re:Then vs Than

[datafr0g]

Really, it may seem petty, but glaring grammatical errors like this are an immediate turn-off. I read stuff like this and immediately assume the author is a nitwit and don't bother reading further.

THAN I loaded up the post in my browser, THAN I saw something that was a more unnecessary post THEN usual... another bloody typo complaint. THAN I replied in a suitably smartarse fashion.

- A nitwit

PS5, Xbox Next II?

[KrackHouse]

I wonder if they're thinking ahead enough to consider a combination of the new Physx chip with a few of these things on a multicore chip. George Lucas just merged his game and movie production studios, seems to be a real trend.

Only ten years too late...

[nickovs]

It's odd that they think that this is news considering that Advanced Rendering Technology were building 3D ray tracing hardware a decade ago.

Re:Then vs Than

[bioglaze]

I'm annoyed with 'than'->'then' too. Almost as stupid as 'their'->'thier' that I see too often at /. Here's some more:

HQ RT Ray Tracing

[SnprBoB86]

As interesting and promising as this is, it is currently useless because it seems to produce low quality renders.

The screenshots on the site all show images that could easily be rendered with much greater quality and efficiancy using shadow maps or stencil shadows and manual matrix transformations with portal rendering for reflections.

When this hardware can render scenes on par with that of a professional software ray tracer in real time, then there will be some serious consumer demand.

Imagine a Beow-- err, I mean...

[John Pfeiffer]

As an animator, I'm stunned by the possibilites of something like this. But it also segues nicely into the conversation I was just having about a particular Japanese PC game developer, and their graphics engines.

For the last five or so years, Illusion has been making, what I can only describe as 'interactive anime porn'. (Save it, I never said I play them.) Any of you who watch TechTV have probably heard of one of their titles from 2003, 'Sexy Beach 2' (Featured on Xplay, much to everyone's respective amusement/chagrin)

Their graphics engines, while not spectacular in all aspects (Though they are improving), have offered near-cg quality characters... Impressive considering that their target platform is ~1.2ghz machines with a modest gfx card.

The conversation I was having was along the lines of 'Imagine if these guys developed an engine for 3+ ghz machines!'...well, hardware like this certainly ups the ante on that...not to mention computer animation in general.

Re:I seriously thought PS2/Emotion engine wud do t

[donglekey]

Polygons don't disapear with raytracing, you just raytrace polygons.

It takes more than a chip

[sacrilicious]

Within the last five years I worked for a company that made 3D rendering chips. The operation that was encoded in hardware was that of testing a ray against a triangle; on the chip produced by my former employer, this operation could be done in parallel something like 16 times, using only one or two clock cycles.

Once this functionality was achieved, there were some contextual architectural decisions to be made about what asic would include these gates. The company decided to implement these gates on a chip that had about 16MB of ram on it and its own execution unit (vaguely like one of the subchips in IBM's upcoming cell architecture, IIUC) and then to put arrays of these independent exec chips on daughter cards.

Many of these decisions were trying to solve the specific problems of raytracing, e.g. how do we get geometry info into the chips efficiently, how can we parallelize the running of shaders so they don't bottleneck things, etc. These problems manifested themselves quite differently than they did for zbuffering hardware, and there were lots of clever-yet-brittle constructs used which could be shown to work in specific cases but which had pot-holes that were hard to predict when scaling or changing the problem/scene at hand.

Rather than selling these chips themselves, the company decided that programming them was hard enough that the company itself would package up the chips into a "rendering appliance", which was essentially a computer running linux with a few of these daughtercards in them. For a software interface to rendering packages, the company chose Renderman. The task then became to translate rendering output from disparate sources (Maya, etc) into renderman expressions, and this was devilishly hard to get right. Each rendering package had to be individually tweaked in emulation, and some companies didn't help out much with info, and even those that did weren't able to supply all the info needed in many cases... my former employer ended up chasing un-spec'd features down ratholes.

The end result was really a disaster. Nothing worked quite right, which was problematic because these chips were marketed not just as fast but as faster drop-in replacements for existing software renderers.

I find it interesting how this entire tsunami of problems snowballed from the initial foundation of how raytracing algorithms (and therefore hardware) are different from zbuffering.

Re:It takes more than a chip

[gr8_phk]

You're quite right about the differences between rasterizing and ray tracing. In my RT library, polygon (and other object) intersection tests are not the limiting factor, not even close. Using a proper scene subdivision structure you generally only do a couple intersections per pixel, and then only one shading operation. This means a 1 megapixel display running at 60 FPS need only do 60M shadings per second (barring reflections etc). The bottleneck in my code is a recursive tree traversal. Unfortunately once you optimize that, you still have a very strange mix of tree traversal, intersection test, shading, and recursive rays. It's not a problem that makes for easy hardware pipelining.

Shameless plug: rtChess

The library is actually much faster now than that old release of the game. If moores law continues by giving us multicore chips, you'll have realtime raytrace FPS, and our chess game will be slugish with photon mapping both in about 7-8 years.

Re:It takes more than a chip

[jackbird]

Would the company in question be PURE/Renderdrive?

Re:It takes more than a chip

[sacrilicious]

Yes... although the incarnation of the product known as "Pure" came after my time there. You a user?

Not fast for a computer... but for a chip...

[phorm]

But depending on the actual graphics output, not too bad for a rendering device. You're better off to compare it to your video card than your desktop CPU. Even on my par 3Ghz machine though raytracing can be dog slow and certainly not near realtime.

I can't comment too much since we're suffering from the slashdot effect (can RTFA but the pics aren't loading), but depending on chip size one could imagine this being very useful on a handheld device or something similar. Perhaps a small integrated graphics tablet would benefit from this?

OK, actually now I've got JPEG's showing the renders, quality looks decent but as far as speed I'd like to see it in real action for realtime rendering.

Re:Not fast for a computer... but for a chip...

[91degrees]

Even for a rendering device, this is a pretty slow clock speed for a performance component. Unless this is targetted at handhelds, it seems strange. This sort of device can be pipelined easily, and a faster clock rate with a longer pipeline would seem to make more sense.

Obviously there's something I don't know since these guys made that design decision, and they probably know more about this that I do..

Re:Not fast for a computer... but for a chip...

[Atzanteol]

They're using an FPGA. It's a programable chip, and typically much slower than dedicated hardware.

Re:Then vs Than

[michaeldot]

You've got to be more tolerant, maybe? I just see it as the nature of the site, and the nature of the people posting.

Slashdot is a rapid-fire blog style comment forum. Most people "hear" the words they want to say and type phonetically.

Then very rapidly preview the post (if at all) so they can go flame some poor innocent Mac user. ;)

Grammar or correctly spelled homonyms play a distant second to getting your opinion across...

OS on the GPU

[michaeldot]

I wonder if there will ever come a time when it's actually faster to run the OS from the GPU rather than the CPU!

Yes, I know GPUs only suit selective, highly parallel image related operations and slow down with things like sin() and tan(), but they are still getting awfully fast...

Re:OS on the GPU

[aminorex]

When was the last time you ran into a call to sin() in the Linux kernel?

OpenRT + CELL

[Anonymous Coward]

Could CELL be programmed to do OpenRT as efficiently as this chip?

Re:OpenRT + CELL

[k0ft]

Could CELL be programmed to do OpenRT as efficiently as this chip?

Sure, as soon as a throw linux on a cluster of mac mini's stuffed full of cell procs on the their fire wire busses, using ipod's for storage.

I think i deserve a +5 for mentioning the slashfodder code words "cell processor", "mac mini", "cluster" and "ipod".

Example:
Immagine a cluster of mac mini's each with 5 20 gig ipods and 20 cell processors on their firewire busses rendering ray traced scenery in real time. Surely this must beat the proformance of a highly tuned application implimeted in hardware on an fpga.

Re:OpenRT + CELL

[polyp2000]

I was thinking exactly the same thing - Unfortunately I dont have an answer - but im also thinking that this is the kind of thing cell could do exceptionally well.

You can already buy this...

[JensR]

I don't know if anyone has mentioned it already, but there is RenderDrive ( http://www.art.co.uk/products.ihtml?page=rdriveove rview ). They are renderman compatible.

Cooling a 90Mhz chip

[mauthbaux]

So, the question is: Can these guys get ATI or nVidia to buy their chip?

I can't imagine either of these companies ignoring an oportunity like this. The speed at which it renders, and its clock speed make it a perfect cantidate for onboard graphics. AFAIK both companies are making motherboard chipsets and would love to have a silent solution for integrated graphics.

Unfortunately, with all the hype over clock speeds, I can also readily see them pointlessly increasing voltages and bus speeds all in the name of performance. In my mind, the real advantage of these chips is that with a low clock speed like that, they are much easier to keep at reasonable temperatures. Personally, I would love to have high-performance graphics that don't make my computer sound like a vaccuum cleaner, or require elaborate phase-change cooling systems.

Benefits?

[cgenman]

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?

Re:Benefits?

[aminorex]

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

Unlimited parallelism.

Re:Benefits?

[Viking Coder]

Unlimited parallelism.

Not true. The geometry still needs to be distributed to whatever it is that you want to parallelize - threads, processors, or computers.

That can be a rather severe limit on parallelism.

P.S. The exact same thing is true of polygon-based rendering - massive parallelism with a few limitations.

Re:Benefits?

[Viking Coder]

Hey AC,

I'm saying the problems with polygons and rays are the same, when it comes to parallelism.

What you just described is the same in ray tracing as it is in polygon-based rendering : you need geometry to do shadows (or reflections, etc.) That spoils parallelism, to a degree.

Re:all aboard!!-Geek Orgy Express.

[mrselfdestrukt]

So if there were no consumers, would there be any geek gear to play with? What would we all do with ourselves then?
Uuuhmm. Play with ourselves?

Raytracing vs "regular" 3D

[FooBarWidget]

How does raytracing differ from OpenGL/Direct3D-style 3D?

Re:Raytracing vs "regular" 3D

[SuiteSisterMary]

It's all about the light.

Regular 3d uses approximations; 'if we have a spotlight here, and an item here, the shadow will look more or less like *this.*'

Raytracing actually 'traces' the 'rays' coming out of the light source, and bounces them off of things. So you get shadows on shadows, diffuse edges, all sorts of neat stuff. But, it's computationally very expensive, as you're tracing photons bouncing over all sorts of stuff, and the approximations are usually 'good enough' for games and what not.

Re:Raytracing vs "regular" 3D

[cr0sh]

Raytracing actually 'traces' the 'rays' coming out of the light source

Minor nitpick - actually, raytracing software traces the rays from each pixel on the screen back to the light source. This has always (AFAIK) been the way it has been done - doing it from the light source to the view plane would involve an infinite number of rays to be cast out from *each* light source, with most of them never reaching the view plane. Going the "backwards" route you might still have rays that never get back to the light source (thus, a black pixel), but at least you minimize the number of rays cast to the number of pixels on-screen (which is what is cool about ray tracing - absolutely perfect object occlusion, with no need for object/plane depth sorting, etc - like is needed for regular rendering).

Re:Raytracing vs "regular" 3D

[SuiteSisterMary]

'Twas a very simplified explanation; I'm sure there are technical details for both approaches I left out. Shadow maps, point sources, and so on.

Re:I seriously thought PS2/Emotion engine wud do t

[Andy_R]

That's exactly what I was thinking when they announced the PS3 would have 4 cell chips, each with 8 vector processors. Is there anything other than ray tracing that's suitable for such a highly parallel architecture?

JHDL ? Virtex II ?

[fizze]

Interesting noone has looked into the hardware/software of this thing yet. (maybe I just blatantly overread it)

First thing: I noticed they used / are using JHDL. (java hardware description language) Now am I the only one that goes WTF there ?
I've been working with VHDL and some Virtex chips amongst others, and I only heard about some attempts of C-HDL's (or C-like at least), and they all are in their kinda early steps.
Verilog and VHDL are the way to go. Therefore I ask the question: why the hell do these folks use Java ?
I recognize these people are not amateurs, nor stupid (heh), but I just think its very very awkward.

Granted, it may be the reference implementation, and it may be too complicated, but from the hardware-developer-point-of-view it makes no sense, really.
There are modules, and even cross-compiler compatibility and the whatnot, so please write at least some modules in proper HDL.

Next thing that amazed me: they use one (maybe 2 somewhen) Virtex II 6000-4 units. These are not really up to date any more. So the tech demos they pull, are low-end, in fact.
The particuilar Virtex II unit they use supports up to ~70.000 logic cells. Nowadays, a Virtex 4 unit can hold up to ~200.000. So, talk of parallelism, eh ? ;)

I generally think this is a great approach for improving performance on less silicon. And smart improvements. Enough of simd units aka mmx,sse, 3dnow! and the whatnot. pull one of these cards in, attach loads of bandwidth.

Want to game ? upload ur openRT cores. need video acceleration ? use another core. repeat et al :)

Re:JHDL ? Virtex II ?

[fizze]

Within the next 10 years or so, we're going to have so many transistors available that filling an entire chip just using VHDL will be an awful lot of work.

Yeah, right.
As long as the hardware is WAY more expensive than manpower, your point is invalid.
Secondly, FPGAs are being used for prototyping, as in "rapid" prototyping, mostly. Some in very high-performance DSP applications, too.
Have you ever seen a sophisticated DSP application 's source code ?

Many of them still use assembler (yeah duh) for core loops.
Why ? Because the compiler just cant take it to a level a tricky engineer can.
And probably because the code isnt as stable.
Besides, theres no use to pay license fees for an insane bleeding edge optimizing compiler, too.
I could go on....

The point that something has been around for 10 years isnt really a strong one either. just take a look at what VHDL was like 10 years ago....

Awesome!

[dspisak]

I'm sure Bit Boys Oy! will incorporate this technology into their upcoming videocard design to come out Real Soon Now, now with Bleeding Edge Vaporware Technology (tm).

Re:Awesome!

[fizze]

haha, now its been years since i heard that name. rings lots of bells though. oy!

But i dont consider that OpenRT as vaporware, mere as a POC or tech-demo. Xilinx will be thankful (and Altera prolly too)

Any news from our finnish Oy's there, btw ? :)

Re:Awesome!

[SuiteSisterMary]

In other news, the release date of Prey and Duke Nukem Forever have been pushed back, to allow the programmers time to incorporate support for this new technology into the engines.

Could one Combine the two?

[Kaenneth]

Could use use both raytracing and rasterisation on the same scene?

for example

first, in parallel;

Rasterizer does the Z-ordering, deciding which polygons are in view of the camera(s) and reflections.
While a raycasting method determines where light is falling based on the light source(s) and reflections.

Then the shader uses those two data sets to color pixels.

Programer vs. Artist screenshots.

[Lerc]

So many people are dismissing ray tracing out of hand because the screenshots are not as pretty as some from the latest games.

Let me ask you. Why would you expect teams of electrical engineers/mathematicians/programmers be able to produce a prettier image than a team of extremely talented artists.

The job of the artist is to make it look pretty. The job of the guys making this chip is to provide features and to make it go fast.

So it's not fast enough yet. It's a prototype. When it can render decent resolutions at decent framerates then bring in the artists and see what they can do with it.

Didn't visit Saarbrucken

[Goonie]

I was basically on my way through to Luxembourg from Kaiserslautern, and the train doesn't go through Saarbrucken - so I can't comment on Saarbrucken itself. In general though, from an outsider's perspective it seems that Germans do tend to take pride in their cities, so an ugly German city is quite attractive by, say, American standards ;)

There *is* some nice farmland and forests there, and the rivers in the general vicinity are kind of nice . Luxembourg, across the river, is nicer again :)

Three cheers! It's about time!

[argent]

Raytracing is heavily parallelizable and is an obvious operation to build into a graphics card. It's about time someone managed to do a good job of putting the two together and doing realtime raytracing for games.

Re:Duh, you develop with FPGA. Then you make ASIC.

[Kiryat Malachi]

Reconfigurable hardware is rarely enough of a benefit to outweigh the large cost differential between an ASIC and an FPGA.

(I work for an ASIC design team for a living, so yes, I do know what I'm talking about.)

FPGA-Based Computing already being done

[Isao]

Take a look at StarBridge Systems, who have been advocating this approach for years. When they first came out (with claims of 100-1000 fold performance improvement of vector supercomputers for certain applications at 1/10 the price) they were the vaporware of the high-performance computing industry. I didn't believe in it either, but slowly we're all coming around.

Not the first

[EnglishTim]

ART VPS Ltd have been doing PCI raytracing cards for a couple of years now. I work at a post production facility and we were evaluating them two years ago. The cards are quite neat and the software takes RenderMan files as input. There were some things they were very good at - refraction, motion blurred shadows and the like that 'just worked' when compared to RenderMan. However, they didn't support RiCurve primitives or some of the RiProcedural stuff at the time (IIRC) which were were using heavily, so they turned out not to be practical for us although it's quite possible they've fixed that now. Neat stuff.

3-5 times faster then a Pentium4 CPU 30 times mhz

[oliverthered]

or, for anyone with a calculator.

FPGA is clocked at 90 MHz is aprozimatly as fast as a Pentium4 1GHz.

Given you can buy 4Ghz P5's off the shelf, who's going to be buying this chip.

I do FPGAs

[Quiet_Desperation]

I'm not sure why you don't think they are in the mainstream. That would be news to Xilinx or Altera. My Tivo has a Xilinx FPGA in it.

We had this debate here at my work last year. One guy wanted to solve a problem with DSP chips. He showed that he could get close to what FPGAs could do, but there was so much DSP arcana involved with parallel instruction sets and setting up the data *just* *so* that no one could really understand it, including the guy who was arguing for it. Lots of hand waving, know what I mean?

The FPGA solution involved VHDL code that a college new hire could whip up.

Okay great! Now maybe Linux Hardware acceleration?

[Shadow51]

Okay cool now we've got raytracing with FPGA's! But how useful is that to most of the geeks out there? Why don't they use FPGA's to accelerate linux in hardware. Maybe reprogram some of commonly used subroutines. Or does that already exists?

VHDL Available?

[nurb432]

Looking at their pages, but dont see it, yet.. Are they going to release the code for the rest of us to look at?

Pretty impressive when its still in a fpga..

End result

[phorm]

I think that what tells is the end result though. If a device running at 90Mhz could say, output 60Fps of raytraced video, it would be better (for that application) than my current GPU - which does fine at standard GL/D3D graphics but can't render attractive Ray graphics realtime...

Re:End result

[91degrees]

WEll, yes, but if it could be run at 180MHz it would be twice as fast.

But as the other poster pointed out, this is an FPGA, so I gather such speeds aren't possible.

you know what they say about assuming...

[Spy Hunter]

Why do you assume that I have not considered the "long view"? The previous post *is* my consideration of the "long view". My argument is not that it's too slow right now; my argument is that it will *always* be slower than polygon rasterization. Perhaps in the future more advanced techniques will be able to be implemented in realtime raytracers, but by that time rasterizers will be implementing even more advanced techniques, staying a generation ahead.

Re: 3-5 times faster then a Pentium4 CPU 30 times

[harrkev]

Let's see here...

1) Convert FPGA to ASIC - 2x speed increase. (Guessing here. may be more, may be less.)

2) I could not find out WHICH FPGA they are using. But it should be possible to incorporate between 2x to 10x as many units on an ASIC. Let's assume 6 times as many units. If ATI or nVidia tried, they could certainly do this. Radeons and GeForce chips hae a LOT of transistors.

So far, we have a 12X increase, if my assumptions are correct. But these are ball-park figures. The actual speedup could be 5X or 50X. Without more details, it is impossible to know.

But the point is this: if a big manufacturer (ATI, nVidia, IBM, Motorols) wanted to work on this, it will completely surpass even the fastes CPUs.

Re:Duh, you develop with FPGA. Then you make ASIC.

[Kiryat Malachi]

Cute. Enjoying life as an unemployed java developer, are you?

For what it's worth, if you buy a car in the next 8 years or so, odds are it'll use technology I helped develop.

Re: 3-5 times faster then a Pentium4 CPU 30 times

[oliverthered]

only a factor of ten out.

Damn...

[suitepotato]

...some people are really taking their POV-Ray interest way too far.

Limitations of Raytracing

[MnkyKnifeFghtr]

One thing I haven't heard people bring up is the limitations of the "look" of raytracing. In real time graphics right now, we are pretty stuck using the Blinn-Phong lighting model, which can be best summed up in the words of Red vs Blue: "We're in the future now. Everything is very shiny." Raytracing is, generally, the same. It does beautiful reflections and refractions, however diffuse surfaces are not nearly as convincing. I think it's great that we'll be able to run real-time raytracing...but not really that great. I think it's a lot of hardware work for almost no value-add to gaming. With the right shader in RenderMan you can make just about anything, so it's not like raytracing is useless, but I don't see this technology ever going anywhere. Just my opinion.

Re:Limitations of Raytracing

[t_allardyce]

Raytracing is fine the real issue is radiosity ie how light reflected from all objects shiney or dull interacts with other objects, maybe this does it well?

The next console

[Zape]

I'm sure it is WELL too far into the development of the next generation of consoles, but a true chip built with this technology would need a lot of speed improvement to look VERY good at 720p or 1080i and would easily walk all over anything the competitors could do until they implemented the same technology.

MOD Parent Up..

[MatthewNewberg]

Lots of good information, I really enjoyed that.

Easier said than done!

[Adrian Wrigley]

I founded Advanced Rendering Technology which created the world's first ray tracing chip (AR250, 1997). It's a lot easier said than done. But the potential is enormous.

I've been watching these guys' web site for a while, and it is great that they now have something decent to show for their work!

It's important to realise that going from a prototype to a real marketable product may take a *lot* of effort, particularly in this field. If you don't provide the highest quality and features, you'd have to compete mainly on speed. If you provide all the features and quality needed for rendering movies, you have a very complex product. It's not clear where this project is headed, but it seems to be mainly a research vehicle at the moment.

They say that Programmable shading, Parallel rendering and Global illumination are on their research agenda, so they're probably quite a way from a full-featured rendering system.

At Advanced Rendering Technology, we jumped in at the deep end! We took in over £14m of investors' cash to (try to) create a full-featured hardware ray tracing appliance. The products are still being marketed at http://www.art-render.com/, but the original company ran out of cash and has been liquidated. A brief explanation of what happened is below.

The business was created in March 1995 from the results of my Ph.D work at Cambridge University (UK). The chip, the AR250 was loosely based around the system described in my thesis "Real-time ray tracing on an advanced HDTV framestore", published in 1993 (not available online, but see patent).

The business was built on a shoestring at the start, getting early investment installments of just £50,000 ($75,000 then). With this funding, we set out detailed create proof-of-concept and a full business plan. The plan agreed was to develop and market a rendering appliance, based on:

A) A multi-million transistor graphics processor, comprising ray/object intersection pipeline, programmable shading coprocessor, and microprocessor-based control circuit.

B) Parallel processing accelerator boards with up to 64 processors

C) An embedded Linux system (we used Dec Alpha initially)

D) An efficient and robust RenderMan Shading Language Compiler

E) Rendering/driver software capable of accurate area lighting, motion blur, depth of field, volumetric effects, even for multi-million object scenes and resolution of 6k x 4k or higher.

F) A suite of application plug-in network RenderMan drivers, with support for 3D-Studio Max, Alias|Waverfront, Soft Image, as well as RenderMan direct

G) Throughput of "up to 1000x" existing software solutions on contemporary PC hardware

and once we had done all that lot, we'd shrink it to a single card and in due course move it to a real-time high-end visualisation solution.

Some "experts" said it was actually *impossible* to parallelize ray tracing in the way we had claimed! Others just said it was too ambitious.

Investors were *very* enthusiastic about the project, but demanded unrealistically short timescales with no slack. Process quality, management, testing and documentation went out of the window. They also demanded veto rights over any significant changes to the plan

To stick within the budget, we could only afford to employ one experienced chip designer (increased from the initial plan of nil(!)), and we couldn't have access to a full set of software tools either.

To stick within the schedule, we had to assume the chip would be "right first time", and would be saleable within months of receipt from the fab. The software systems would have to be built concurrently with chip design. There was no time or budget for fixing design issues with the chips. The first prototypes had to go to paying customers.

It became clear in 1996 that we needed access to an additional chip development tool not budgeted for. This led to a six month(!)

Re:Easier said than done!

[FortuitousDragon]

I work for ART VPS, the new version of Adrian's original company. Thanks for a great chip, Adrian! :-)

What you soon find when writing a renderer is that the ray intersection engine is the smallest part of it - productising takes almost all the work. There are renderers at all parts of the price/performance/quality cube. The ART VPS renderer is scalable - we have versions going from 8-36 chips, each of which has two of the ray intersection and shading cores.

The features of a renderer are all in the software, and we've been working hard to keep our features up to date and ahead of the competition.

I suspect we'll see more ray tracing hardware in the future as current realtime rasterisation algorithms start to get too expensive due to the geometry factor. I don't know how soon in the future as I think that there is still plenty of room left for ameliorating complexity without changing the visibility algorithm to ray tracing. As far as features go, NVidia Gelato shows that multi-pass methods can be used to produce arbitrarily complex rendering and shading.

However in offline rendering almost everyone is now doing ray tracing. PRMan 11 supports ray tracing, Mental Ray is now shipped with Maya (which already had its own renderer that supported ray tracing), etc. The ART VPS renderer using either PURE or RenderDrive is being constantly improved - we have to otherwise the competition would take the lead. And we still offer features and performance that the others can't match.

Matthew
Software Engineer
www.artvps.com

Make a journal article

[Morosoph]

Declaring an interest: I worked for Adrian's company.

It's a shame that you didn't post this earlier, but you could generate a little more interest by posting a journal entry about the events at ART, or even several, as the technology and business side of it are each worth independent focus. It might be worth re-posting your entries after you've aquired enough "karma" and "friends" to know that you actually have an audience.

The ART rendering system was/is excellent technology, especially for its day, and in terms of photorealism, no-one's even come close, especially at the speedups that ARTs rendering system was/is offering. Those were good days for me...

raycasting

[bored]

Wolf5k is a raycasting engine, this is diffrent from a ray tracing engine. Early first person view games used ray casting for hidden surface removal because the number of 'rays' cast were limited to the horizontal resolution of the screen. In other words 320 rays for early games like wolf3d. Many older game books have example raycasting engines. The problem was that extending the concept was difficult without loosing the performace. Later BSP trees pretty much removed the whole raycasting method in favor of just culling enough polygons to make a visually workable engine.

Re:I seriously thought PS2/Emotion engine wud do t

[bored]

Yes, "traditional" ploygon painter engines can be setup to work in quadrants. Hence SLI and similar technologies.

rtChess

[bored]

Thats cool, the rendering looks really nice, but it also looks a little '90s because there isn't any texture mapping on the pieces. Better yet, since texture mapping is sort of a hack, what you need are some really high polygon detailed chess pieces with individual rocks on the rook, faces on the pawns, or enough detail that the pieces look like they have been hand carved out of some substance.

Raytracing at its best

[doublebackslash]

Check this out. And if you like what you see and want to do some yourself, my very personal favorite tool: POV
This from 2001 blew the varous parts of my mind involved with detecting CGI artifacts away. Imagine what todays hardware can do...