Slashdot Mirror
Add Another Core for Faster Graphics
Dzonatas writes "Need a reason for extra cores inside your box? How about faster graphics. Unlike traditional faster GPUs, raytraced graphics scale with extra cores. Brett Thomas writes in his article Parallel Worlds on Bit-Tech, 'But rather than working on that advancement, most of the commercial graphics industry has been intent on pushing raster-based graphics as far as they could go. Research has been slow in raytracing, whereas raster graphic research has continued to be milked for every approximate drop it closely resembles being worth. Of course, it is to be expected that current technology be pushed, and it was a bit of a pipe dream to think that the whole industry should redesign itself over raytracing.' A report by Intel about Ray Tracing shows that a single P4 3.2Ghz is capable of 100 million raysegs, which gives a comfortable 30fps. Intel further states 450 million raysegs is when it gets 'interesting.' Also, quad cores are dated to be available around the turn of the year. Would octacores bring us dual screen or separate right/left real-time raytraced 3D?"
Need a reason for extra cores inside your box? No :)
-- "Genius is 1% inspiration and 99% perspiration" - TAE --
What about 2 cores for the OS (one for the system idle process and the other for the working processes) , and 5 other cores (4 cores dedicated to the first 4 applications I launch and the other for misc. activities)?
Who needs extra cores when you've got free hardcore?
why we all use GPU? Graphic card is the addictional CPU to handle all our graphic needs.
We all know that extra cores that will be in our processors in near future are for running malware/spyware while we do our work on main core.
Lemme see, at this rate I'll need: 9 cores for the raytracer, 7 cores for the physics simulation, 5 for the AI, 3 for the OS, and of course
;)
One core to rule them all
One core to find them
One core to bring them all
And in the darkness bind them
A polar bear is a cartesian bear after a coordinate transform.
There are already ray traced games. :O
http://graphics.cs.uni-sb.de/~morfiel/oasen/
F.A.N. released a real-time raytraced demo at breakpoint back in 2003. It does no more than 10 fps on my lowly 1GHz P3, but I'm sure it runs quite smooth on a nice modern CPU (though I don't think it's multithreaded).
Error: password can't contain reverse spelling of ancient Chinese emperor
Each core is already capable of doing 100 million raysegs and you talk about quad cores. So I think you mean
450 million raysegs not 450 raysegs.
Slashdot: Tabloid for the nerds. Stuff that doesn't matter.
Take a look at the proceedings from any graphics conference in the last three or four years, and you will see several papers which involve ray-tracing on a GPU. Actually, not so many recently, because it's been done to death. The most impressive one I saw was at Eurographics in 2004 running non-linear ray tracing. As the rays advanced, their direction was adjusted based on the gravity of objects in the scene. The demo (rendered in realtime) showed a black hole moving in front of a stellar scene and all of the light effects this caused.
I am TheRaven on Soylent News
Wouldn't it be possible to write a raytracer that used the GPU core(s) instead of the CPU? Raytracing is pretty much entirely vectors isn't it? That's what GPUs do best.
NB: The only raytracer I've ever written was in PHP and it managed about 0.01 frames per second with very basic geometry and no textures, so I'm probably very, very wrong.
http://twitter.com/onion2k
If i remember it correctly from my days of playing with POVRay (free raytracing app), the time it took to raytrace an image depended on things like the presence (or not) of semi-transparent, semi-reflective surfaces and on the number of light sources.
If this is still the case, then going from the current rendering techniques in games to raytracing would result in images with more realistic reflections and lighting but, due to performance tradeoffs, few reflective surfaces and light sources.
Besides, at the moment what games need the most is beter AIs and procedurally generated content, not yet another layer of eyecandy that requires gamers to upgrade their hardware (again).
FTA
"Oh, blast. Rabbit, I seem to have forgotten my pocketwatch. May I borrow yours?"
Rabbit: I'm late, I'm late, I'm late...
---
anyway, if these technology becomes a reality in the 3-5 years and if I read the article right, the whole graphics architecture would change, there would only be a need for a super graphics processor and less need for too much memory and those graphics pipeline/shader thingies...
The reason that they might want it in a CPU is that, why have a separate add on GPU to handle the job while the CPU could do it alone by that time. You would then only need a "basic" video card that would just do the display.
Hmmm... could this be one of the reasons why ATI and AMD merged?
Just found that game using raytracing - Quake 3: Raytraced./
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter
Rumors are there's a q4 version on the way.
My apple only has one core... -Taylor DISCPLAIMER - By apple i mean a piece of fruit grown from a tree, often referred to as an apple tree. I do not own an Apple computer, and am not referring to one in this post. I simply wanted everyone to know that my fruit is relatively normal in regard to the number of cores it contains. Also, it is not very good at raytracing, so maybe the talk of multiple cores really is better for that...
Worldwide Military budgets: $2100 billion. Worldwide Space Exploration budgets: $38 billion. Really, world? Really?
Hey, everybody, dont be surprised to know how easy to cheat human eyes and mind. I still recall games in pseudographics with beep sounds - and thats was really cool.
hehe, it would lead to a complete failure of current graphic card manufacturers, as the need for 3d acceleration would drop to zero immediately
on the other side, cpu cores or addons specialised for linear mathematics would rise quickly to enhance this even further - we still could use a lot of work there despite sse2/3dknow/altivec
also this is one of the things, where the cell will burn into the world when used appropriately, as the raytracing data can be easily fed into it as stream and be parallised easily
I wonder how much this research relates to Intel's renewed desire to become a graphics player.
If they're having trouble, for staffing or other reasons, producing good GPU designs, then it would be pretty clever of them to revolutionize the industry AND capitalize on their CPU strengths in a single move. More power to them, I say. (More power = about 120 watts, I'm guessing.)
Found this link a while ago: http://graphics.cs.uni-sb.de/SaarCOR/
Methinks it would be pretty cool when there's a 'graphics' card that could do standard raster-based graphics, raytracing and physics. Most of the calculations are the same anyway, so a general purpose processor that is very good in floating-point vector calculations would be necessary. The API's would be mostly implemented in the driver (OpenGL, OpenRT, etc.)
The current crop of "raster based" games don't look so bad to me. I doubt that ray tracing would add very much to a FPS.
No sig today...
No, ray tracing is all about searching databases for ray-object intersections. That's what GPUs can't do at all.
No sig today...
It's not just the sheer number of FP calculations that can be the problem. Once you get away from the first (or perhaps even second) level of rays, you end up losing coherence between neighbouring rays which causes memory page/cache thrashing. This is not a nice thing on a GPU.
It's extremely unlikely that anything will go anywhere with raytracing in the near future. Raytracing takes a tremendous amount of power - apps that demonstrate it in realtime usually run quite choppy, and they're very minimalistic to boot; ugly textures, very simple geometry, very confined areas...
The main benefits of raytracing in games would be:
1) Shadows; they'd be Doom 3-like. Several games have full stencil shadows and that's just how raytraced ones would look: sharp and straight. The difference? Raytraced ones would take a ton more power and time to compute.
2) True reflection and refraction. We can "fake" this well enough - for example, see the Source engine's water, incorporating realtime fresnel reflections and refractions. Though Source's water's "fake" refraction/reflection aren't pixel-perfect, and are only distorted by a bump-map, it certainly looks great.
Honestly, considering the small gain in visual quality (although a major gain in accuracy) - it's like going after a fly with a bazooka. Sure, once we get to the point where there's enough processing power to deal with this well enough in realtime, it will happen - but don't expect it soon, and don't expect that huge a difference. Nicer reflections and refractions (which already look good today) and pixel-perfect shadows (looking just the same as stencil shadows in some newer games).
Ray tracing also suffers terribly from "jaggies". Edges look bad because rays can just miss an object and cause really bad stepping on the edges of objects. To eliminate jaggies and do anti-aliasing, you need to do sub-pixel rendering with jitter (slight randomness) to produce an average value for the pixel. So you might have to trace 4 or more rays in a pixel for acceptable anti-aliasing. Effects like focal length, fog, bump mapping etc. cause things to get even more complex. Most pictures rendered with high quality on Blender, POVRay etc. would take minutes if not hours even on a fast / dual core processor.
The only way you'd get 30fps is if cut your ray trace depth to 1 or 2, used a couple of lights, cut the screen res down and forgot about fixing jaggies. It would look terrible. Oh and find time for all the other things that apps and games must do.
A ray-tracing problem can be solved simultaneously using a moment method that incorporates physical optics. I wrote my Master's thesis a long time ago that did precisely that for 2-dimensional situations. Of course, this required solving massive linear systems that, at the time I wrote it, took hours on a 433MHz Alpha to do a single frame, and it was written in FORTRAN77, but hey, we've come a long way since then :)
But when we get into presentation-quality raytraces (at least with Povray), my P4-2.4HT takes 3-4 minutes per frame. And that's on lowest quality. High quality takes a matter of days.
Would multicore processing help out here as much as it would with high-speed raytraces?
I make websites and stuff. Buy one.
I've seen the topic of realtime ray-tracing and hardware accelerated ray-tracing come up countless times over the past 15 years. In the 80's and 90's, a realtime ray-tracing acceleration chip was always around the corner. Some products did actually emerge, but never quite caught on. The reason for this is not because "commercial graphics industry has been intent on pushing raster-based graphics as far as they could go". Quite the contrary; it's much more elegant algorithmically (and hence 'easier') to implement a ray-tracer than a scanline based renderer. However, there's a fundamental limitation of ray-tracing that make it unappealing performance-wise. Cache coherence for ray-tracers suck.
All rendering algorithms boil down to a sorting problem, where all the geometry in the scene is sorted in the Z dimension per pixel or sample. Fundamentally, scanline algorithms and ray-tracing algorithms are the same. For primary rays, here's some simpliefied pseudocode:
foreach pixel in image
trace ray through pixel
shade frontmost geometry
The trace essentially sorts all the geometrty along its path.
A scanline algorithm looks like this:
foreach geometry object in the scene
foreach pixel geometry is in
if geometry is in front of whatever is in the pixel already
shade fragement of geometry in pixel
replace pixel with new shaded fragment
As you can see, the only distinction is the order of the two loops. For ray-tracing, traversing the pixels is in the outer loop, and the geometry in the inner loop. For scanline rendering, it's the opposite. This has huge consequences in terms of cache coherency. With scanline methods, since the same object is being shaded in the inner loop, and neighboring fragments of the same object are being shaded, cache coherency tends to be extermely high. The same shader program is used, and likelyhood of the texture being accessed from cache is very good. The same can't be said for ray-tracing. You can shoot two almost identical rays but touch wildly different parts of the scene. Cache coherency relative to scanline rendering is abysmal.
This one performance side-effect of ray-tracing is the only reason we haven't seen any serious ray-tracing for realtime applications. Even in offline rendering, scanline rendering dominates even though software ray-tracing has been available from the beginning of CG. For ray-tracing to become viable, we need more than just more CPU cores. We need buses fast enough to feed all the cores in situations where we have an extremely high ratio of cache misses. Unfortunately, the speed gap between memory speeds and compute power seems to be increasing in recent years.
Extra, extra! This just in! Report from CPU vendor discovers that you should spend more money on your CPU and less on your graphics card!
Shocking, I tells ya. Shocking.
Read my blog.
It's nice that people are working on ray traced games, but please note the following:
...
Oasen is based on "OpenRT" --- which is entirely proprietary, and is NOT open source. Their FAQ explains that clearly.
I'm sure that I'm not the only person annoyed at their use of "open" to mean "closed".
Time to look for an open-source raytracing engine designed for interative use
This makes sense, and I've been saying this since details about designs like the Cell processor were announced. Not specifically for raytracing, but also for normal 3D rasterization. In time, I predict GPU's will disappear entirely, and CG will move back to software rendering. Most people find this ridiculous as they only remember software rendering from Quake 2-generation engines, and software rendering looked awful compared to hardware rendering back then. But there is no reason at all why a CPU couldn't produce the exact same quality rendering as a GPU, its just too expensive at the moment.
Think about it: if a Cell-like CPU with N cores can be programmed efficiently to use (e.g) N/4 cores for rendering, and be able to scale image (AA/filtering/NURBs tesselation/etc) quality with the number of cores, and have enough power left for physics and logic, what's the future for GPU's? If the solution is slower then a current GPU, the number of cores will grow eventually and at one moment surpass GPU performance. At that point software rendering would be more attractive then hardware rendering, as it is much more flexible/upgradable and scalable than a (more or less) fixed-function GPU. For example you wouldn't need special/extra hardware to be able to play both software rendered as well as software raytraced games, as both just run on some of the CPU's cores.
Raytracing - something involving complex mathematics and considerable computing time, performed by the CPU - actually goes faster when you add more horsepower? It "scales" with more processing power? Peter Griffin says: NO FREAKING WAY!
Four 3.2 GHz CPUs gives:
//0xFE
3.2 * 1,000,000,000 * 4 = 12,800,000,000 Hz
Assume resolution 640x480 and framerate 30:
640 * 480 * 30 = 9,216,000
OK, now let's see how many cpu cycles we're gonna have for each ray:
12,800,000,000 / 9,216,000 = ~1388.89
Conclusion:
Can you complete a raycast in one and a half kHz? Not a chance.
And even if you could - there would be _nil_ cycles left for sound, game mechanics etc etc...
The reason to add extra cores is that, with our current processors made for single-tasking, with their only stack and set of registers - hyperthreading is the exact same thing, with only 2 stacks and register sets - programs (threads, processes, whatever) are supposed to be run one on each processor. Let's change that, first. Let's put, say, a whole lot more registers, drop the hardware stack and use a software one - make everything software-based, reduce the instruction sets, use WAY more powerful SIMD, and add numerous cores. THAT is the design we NEED since forever. As for GPUs, RPUs, and so on - let's just drop it. They offer nothing really valuable. Raytracing has been The One True Way since forever. Now we have the CPU power to use it in real-time. Why has no one ever thought of using numerous general-purpose chips (68000s?) on additional cards to do only raytracing? Because it would be BETTER? Raster graphics have always sucked.
Making laws based on opinions that stem up from false informations leads to witch hunts.
Surely an advantage of Raytracing would be that you could have exact shapes. e.g. Instead of approximating a cylinder by an octagonal prism, you could just have a real cylinder. What's more, the pure shapes like cylinders, sphere etc, would take up less memory than their approximations.
1) Static Objects Only. The huge majority of computation time is traversing a spatial subdivision structure. It happens that K-d trees offer the best characteristic (typically, fewest primitive per leaf for a given memory limit). However, these are really heinous to dynamically update. You can cheaply re-create it with median partitioning, but your trees are crappy. You can do a much nicer SAH (surface area heuristic), but to do this per frame blows out your CPU budget.
2) Bandwidth. Even if you could update your subdivision structure very cheaply, that structure still needs to be propogated out to all the CPUs participating in the raytrace. For the 1.87 MTri model they list on page 6, their spatial structure was 127 MB. Say you have a bandwidth of 6 GB/s, it takes 20ms just to transfer the structure (and there are other problems here). So your ceiling is 50 Fps before you trace your first ray.
3) Slower than a GPU. Even though they give you some little graph showing that raytracing (a static model, with static partitioning) beats a GPU at a MTri in the frame, this is very deceiving. The GPU pipeline works such that zillions of sub-pixel triangles simply can't get into pixel shaders fast enough, and force the pixel shader to be run many times extra. Double the resolution, however and the GPU won't take a cycle longer... with raytracing, performance will halve. So they found a bottleneck in the GPU which is totally unrepresentative of a game in every single sense, and said LOOK! BETTER! (in theory).
4) Hey, Where's my Features? All the cool things about raytracing (nice shadows, refraction, implicit surfaces, reflection, subsurface scattering) all get tossed out the window to make it real-time! What's the point, then? Given all the pixel shader hacks invented to make a GPU frame look interesting, the quality that can be achieved in a real-time raytrace is sadly tame. Especially when you consider that quality is the supposed advantage of raytracing.
And c'mon. It's Gameplay that counts anyway :P
The Cell Processor
Three or four people have brought up the idea that problem would work well for the cell processor. But I don't think anyone has really seen the (rays of) light on the issue. The Cell is perfect for this. Some facts:
1) Raytracing is highly vectorized. The Cell's many processors are optimized for vector calculations.
2) Raytracing scales linearly with the number of cores. The Cell has 8 (at least in its current manifestation).
3) The Cell is already available as a PCI-Express add-in card (that even runs linux!) which sounds awfully like what a GPU is... 4) The Cell is a bitch to program. But then, so are GPUs...so maybe it's not that ridiculous to see the future of the GPU...from IBM.
How ironic it is that Intel is now pushing this technology...
It has been a nervous year, with people beginning to feel like Christian Scientists with appendicitis.
SGI had a ray tracing demo at Siggraph 2002. On the show floor, a 128-processor SGI box ran demos at around 20hz at about 512x512 pixels.. html
http://www.sci.utah.edu/stories/2002/sum_star-ray
They make some good points about geometric complexity increasing much faster than displayed pixels, so there are fewer graphics primitives per pixel, so scan-line-based algorithms will make less sense.
So in 2002 it took 128 processors to run at 20Hz at 512x512 pixels. And now we think quad-cores will be enough to render today's complex environments? That math doesn't add up to me. I think scan-line algorithms are the mainstream answer for a long time coming...
This month's edition of Scientific American had a good article on Ray Tracing. Basically, how it can be more feasible with the faster/better hardware we have today. The article is available here, but unfortunately, you have to pay for it. The article focused on new software and hardware techniques for Ray Tracing being developed at Intel. They say that Ray Tracing is "poised to replace raster graphics" because it "scales well with hyper threading and multi-processor configurations.". Also the "cache hierarchy associated with CPU's is very effective at managing the external memory bandwidth requirements". With multicore processors entering the mainstream, they may have a point.
I wish I could remember more from the article, but I read it some time ago.
Vivin Suresh Paliath
http://vivin.net
I like
I did RTchess a few years back (a link would kill my friends server). The core RT code has been pulled into a library and improved significantly since then. I was actually meaning to write an artice making the same point as the one in the summary. Multi-core will make realtime ray tracing common in a five years, and then there will be no use for the GPU. Why rasterize when you can ray trace instead? Ray tracing scales exceptionally well with polygon count (log n). Why add a second chip? Not to mention the geometry needs to be present in the CPU anyway when you do physics. Why maintain all the geometry data in 2 places?
The Intel guy has some funny stats about ray-somethings per second. Intersection tests are irrelevant. Generated rays per second is too. There is already a "Benchmark for Animated Ray Tracing" called BART. Frame rates on those animations are much more important. Unfortunately I haven't even had time to patch that code together with mine to get numbers. It's down there on the to-do list. Is Intel hiring? If someone could pay me to work on it, things would come together quickly.
That's an interesting calculation (part of what I was trying to estimate from the article; I'm trying to reconcile "30 fps!" with "But Povray/Bryce/Maya can take _hours_ per frame"). So you need to cast rays (calculate colors) for 9.6 million pixels every second.
But what I'm wondering about is, the more relevant number may be the number of intersections you have to calculate. If you have 100 shape objects in your scene, you need to test each ray against 100 intersections. You really probably need thousands of shapes to make a decent scene. (How many polygons are in an average scene in a modern 3d game? For raytracing, you don't need to break everything up into polygons...but it still requires a lot of shapes.) Then, you still need to worry about reflections, oversampling, light sources, and transparency. (For accurate shadows, you'd have to trace each ray back to each light source rather than choose a static color.) These effects make raster graphics more difficult, too - but they seem to have addressed them.
Plus, it's not clear...are they describing raytracing using full floating-point arithmetic? Or are they using fixed-point integer arithmetic? I've always seen people use floating-point for raytracing since a fixed-point algorithm is much messier and subject to inaccuracies, but I suppose fixed point could be done.
... would be a FPGA that sits on a core. For those who are not familiar, a Field Programmable Gate Array is essentially a peice of hardware that can be "programmed" to perform specialized tasks, especially sequental ones, at faster speeds than software on a general purpose CPU. Imagine a fully programmable coprocessor with blazing access to RAM and a hypertransport to the general purpose cores for more complex functions that are hard to script in hardware.
I have seen comparatively weak, 1M gate FPGA's encode OGG Theora at 1280x1024 at almost 30fps (http://www3.elphel.com/en/products), imagine what a FPGA with a far greater number of gates, communicating at processor speeds could do.
Sure it would need to be reprogrammed for every task it needed to perform, however if I'm doing video encoding or decoding, I wouldn't mind reprogramming it. Game designers could even use the FPGA to accelerate tasks from AI to raytracing to whatever.
It may not be as fast as a coprocessor built for a single task, but it would be a heck of a lot more versitile. And it could be reprogrammed if any bugs are discovered.
Sometimes the best solution is to stop wasting time looking for an easy solution.
Just imagine the possibilities. Imagine moving your ship among asteroids that aren't just outlines, but fully texture-mapped bump-mapped gloss-mapped anti-aliased anisotropic-filtered self-shadowed pixel-shaded, and with lens-flare and bloom effects to boot. And rendered in HDR too!
I smell a winner. Let's now flood the review sites with 120 screenshots (see, in that one there are _two_ large asteroids)and we could have a bestseller.
A polar bear is a cartesian bear after a coordinate transform.
I'll let the other posters comment on the wrongness of your idea that raytracing doesn't scale with scene complexity. There was a nice SciAm article about it, if you need more convincing. Instead, I'll talk about something in the article that the other posters didn't mention. Raster Processing may scale with scene somplexity, but creation doesn't. Raster graphics must be tweaked at creation to make an object look realistic while still rendering quickly. With ray tracing, you just create an object and forget about it. It just looks right without any tweaking.
What costs game designers more: hand tweaking every object, or you buying a better computer so you can ray trace their un-tweaked objects? Now guess which way 3D graphics are gonna go...
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
There is a good article about this in August's Scientific American by W Wayt Gibbs. It's only a couple pages but worth picking up a paper issue, or if you have one of their digital subscriptions here: http://www.sciam.com/article.cfm?chanID=sa001&arti cleID=000637F9-3815-14C0-AFE483414B7F4945
E pluribus unum
Add to that the fact that the site hasn't been updated since mid-2005, and I'd say it's dead.
I'm a doctor, not a programmer...
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Parent is correct.
Cache coherency is what happens when you have multiple processors, and you have to keep the cache coherent between the two processors if they're working on the same data. i.e. processor A and B are working on a dataset. Processor A modifies variable X, and processor B wants to modify it, but it has to 1) know X is in A's cache and 2) get X from A's cache. Then you get into fun little things like shared cache, write-through operations, etc.
Cache locality is affected by random reads, hence the previous comments comparing ray tracing to databases. Normally, we expect to access the same data more than once (temporal locality), because we frequently use a variable in more than one calculation. We also expect to access data near other data (spatial locality), because we store objects as groups of data and we access multiple members of an object for some calculations.
:(){
Not only that, but also bear in mind that
1. GPUs are already massively parallel things. If you think of way back in the days of 1 pipeline GPUs and cards, each extra pipeline is, in a way, like an additional core. We're already at the point where cards act like a 16 or 24 core chip, for all practical reasons. (Or 4x that if you run two 7950 GTXs in SLI.)
Graphics problems are by definition massively parallel. They're essentially doing the same (simple) set of operations on many many pixels. Unlike CPUs where "multiple pipelines" means you get to split a single stream of instructions across them, while "multiple cores" means actually executing several threads at the same time, GPUs don't have that distinction. Each pipeline processes one "thread": that for one pixel.
I.e., as "multi-core" hype goes, the GPUs are actually ahead. I don't need to wait for Intel's 8 core chips sometime in the future, when Nvidia can do 96 cores right here and now, and do that cheaper. Partially _because_ they don't have to also be a general-purpose CPU, applicable to everything from games to databases. So they can pack more specialized units per square inch. They've also sold whatever issues of concurrent access, caching, etc, are involved in graphics problems.
2. GPUs can and do also solve a lot of problems via dedicated hardware, rather than having to program them to even find the pixel in a texture. There are programmable things like pixel and vertex shaders, yes, but also a lot of things like texturing or filtering or T&L nowadays are solved _much_ faster by hard-wired dedicated units. They're units which just have to do one thing well and quickly, and actually do it, churning one pixel per clock cycle.
Even if we move to raytracing, I'd expect much the same to apply. Sure, instead of building an image starting from the triangles, we'll start from the screen pixels and find the triangles they intersect. But conceptually it's still the same kind of operation that's (A) massively parallel, and (B) can have many parts that are hard-wired for maximum speed.
E.g., finding the intersection of a pixel with a surface, and finding out what pixel value is there, is basically one such operation which can be served just as well by a fast hard-wired unit. Reflections and refractions? Ditto. You don't _need_ a user program running on a general purpose CPU to do those.
So basically on the whole, while I can understand why Intel is searching feverishly for a reason why you'd want 8 cores in your home computer, I can't understand why would any end-user actually want to move those operations back onto the CPU. The GPUs do that stuff better, and will keep on doing that stuff better.
A polar bear is a cartesian bear after a coordinate transform.
Just another step in the well known Wheel of Reincarnation. At least well known to all three of us who don't completely ignore computer history ;-)
It actually scales exceptionally well with the amount of geometry O(log n) where GPUs suck. Read the linked article. Also, the spatial index used in ray tracing is a non-trivial data structure which is not handled well on a GPU. I've also found that ray tracing works better (fewer/no artifacts) with double precision floating point which is not available on a GPU. In a few years, the CPU will be quite capable of realtime ray tracing, so at that point, the GPU becomes a truely redundant part. And in spite of all the "GPGPU" hype, they still don't run word processors or other useful app. When you can use either chip for graphics, but only one of them can do all the other things, which one do you think will get dropped?
BTW, compositing windows can be done on the CPU today, so why all this talk about using the 3D card for it? Have people forgotten how to write fast graphics code? (unless it's GPU assembler of course)
>>> ' A report by Intel about Ray Tracing shows that a single P4 3.2Ghz is capable of 100 million raysegs, which gives a comfortable 30fps'
Thats a bogus comment, as raytracing time (hence framerate) is totally dependent on the complexity of the scene being rendered.
E.g. A few simple cubes would raytrace MUCH faster than a forest scene with reflective water and multiple trees, leaves, and blades of grass etc.
Unfortunately, for gaming, the latter scenario is much more likely.
It still makes sense to offload rendering/raytracing to a dedicated graphics processor ( read GPU ) as it has closer ties to video ram. If done by the CPU, you'd swamp the sytem bus with billions of (slow) graphics memory writes. Also it leaves the CPU free to do other stuff like game AI, speech recognition, physics, dowloading pr0n etc.
The question this article should have asked is if real-time raytracing is so doable, when will nVidia/ATI start using raytracing in their GPU's and drivers? Don't forget even an average GPU still kills even the best Intel CPU in terms of floating point operations.
You expect someone to RTFA? This is slashdot, where everyone can be an expert. As long as no one reads TFA. Get with the program!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Dedicated RayTracing hardware has been available for several years. The first commercially successful one was http://www.artvps.com/ (Advanced Rendering Technolgies (ART) in the UK)
They demo'd their prototype render engine back about 6-7 years ago at SIGGRAPH (99, I believe...I was there.)
But to use it for realtime work (even the PURE card they sell) it would have to be heavily optimized for speed, rather than 'prettiness'. That would be a major re-tooling of the design.
Raytracing for games is becoming a possibility...but it is not nearly where it needs to be to be affordable and efficient.
GPUs do NOT run raytrace algorithms well. But that is because they aren't designed to. If nVidia and ATI/AMD decide to start including some silicon real-estate on the chips for dedicated ray-intersection testing and a linear equation solver unit.....things might accelerate in that direction faster.
Until then, its just a lot of academic theorizing and 'best-case' numbers.
How about some real world use. My Athalon 64 3600 conks out when trying to show and transcode a simple HDTV programming from the local PBS station transmitting at 1080i. In mplayer it drops frame here and there and remember mplayer is one of the best out there.
You mean that as a joke, but it is not entirely without merit. On any system with 192MB of RAM or more I generally do not use a swap partition, since it is not needed as long as you dont go bonkers and try to load up the GIMP and a VM and OO.o and all the default active services or daemons.
Some apps will not run without swap space - not that they actually use it - just that they refuse to run without some. Create a 2MB swap ramdrive, and problem solved - just to make the programs happy.
I mostly use a laprop retrofitted with a Hitachi microdrive in place of the hard disk to save power. It sips power, is dead quiet, and produces almost 0 heat, but is slow as ice melting. Program loading is almost bearable, but once loaded everything's fine. Hitting swap on it would be disastrous.
If I need to use a memory hungry app (huge image editing, etc) I use a different machine.
Swap is for n3wbs.
If a boom does finally start in ray traced realtime engines, which I somehow doubt, Microsoft won't like it. They have spent a whole lot of money to make DirectX a monopoly and thereby control the games market. this would push the whole effort overboard, with time. Microsoft would have to make their DirectXRayTrace the sole API before they'd be happy again.
I don't know that povray rendering time is necessarily a good indicator of the maximum performance of a real-time ray tracer. From Ray Tracing News:
Not that I'm disparaging povray; it has many interesting features and a wonderful programmer-friendly scene description language. However, I don't think rendering speed is necessarily its strong point.
I'm saying purely from a "geekiness" standpoint that I'd like to download and mess around with this engine. It looks like fun. It is painfully obvious that, aside from the bump maps and real-time lighting, the game actually looks worse...but that's understandable.
The lighting has actualy served to highlight the small amount of polygons in the player model (750, to be exact). The good thing is, as people have been stating all through this thread: processing requirements for raytracing go up with the log of the polygons. So, upping this model to 7500 polygons (more than used in Doom 3 models) would only double the processing requirements, which shows a bright future for rayracing.
Look at it this way: ten years ago, real-time raytracing was a pipe dream. Right now it is very much a reality on high-end hardware, albeit with reduced features and benefits. In another ten years, I will be surprised if raytracing is too difficult for mainstream hardware.
Man is the animal that laughs.
And occasionally whores for Karma.
I don't get all this "won't happen" bah humbug. We have ray tracing - heck, we have real time ray tracing, and it's about to go open source: http://blogs.zdnet.com/OverTheHorizon/?p=10