The javascript renderer was surprisingly fast.
I loaded the original JS raytracer seen and rendered it in 4.1 seconds (using Opera). But I guess there are lots improvements left in the JS engines, because Firefox and IE7 were many times slower.
As time goes on its becoming apparent that two types of hardware are needed on the desktop. The massively parallel world, and the low/single threaded world. Not everything is easy to run parallel and a mix of the two worlds is going to be essential.
At the moment Intel and AMD are pushing forward with more and more cores, but that is rapidly becoming useless for the desktop (the 8 virtual cores of the i7 is already too far). A reversal of that trend and complimenting it with a massively parallel chip, of which Larrabee is the first version, is going to give us the best of both worlds.
Niniane, are you by any chance the Niniane who worked on Lively? Explanation: it’s a somewhat unique name, in the context of a discussion about 3D, and as I’ve remarked on Twitter, female names are (unfortunately and sadly) rare enough on my blog that they’re frequently a sign of spam anyway.
Rick: For something like World of Warcraft, I bet this would work nicely and save them a lot of money
In theory yes, but in practice does Blizzard do this? No. And they make gazillions of dollars on WOW. That’s a pretty compelling argument, to me at least, that this complex software rendering fallback scenario just isn’t necessary.
Honestly, something like pseudo-3D delivered through the browser via Flash or Silverlight is more likely. Do casual gamers even need 3D?
Anyway, the more I think about this, the more I think that GPUs need to be on the same die as the CPU. I’m not sure radical architectural redesigns of x86 CPUs that can work as de-facto GPUs will be a successful evolutionary path. MHO of course.
On a related note, per that gamedev forum thread, looks like Intel bought Pixomatic…
One of the axioms of systems engineering is that you can optimise a system to do one (or a few things) really well but most others poorly; or you can optimise the system to do many things kind of OK, but none of them really well.
General purpose CPUs are fast enough to do very specific things like graphics kind of OK, but they wont ever be able to match the potential of a limited purpose PU like a GPU.
There are savings in chip production, but because you need to drive a general purpose processor much harder to match a designed for purpose processor the operating costs are higher. A classic example is that my $50 DVD player plays DVDs with nothing but a 1 inch inaudible rear exhaust fan while my $1k HTPC has a water cooling rig so I could watch a DVD without needing to set the volume to 11 to mask the noise of all of those fans…
I disagree with your conclusion.
The software game has no crystal balls; the things that will change in the future are in the tools farther down the waterfall than assembly. Pixomatic, with extremely fast, well written assembly code, has a long-term advantage… The things that will change over time are the DirectX libraries that they are trying to allow to process properly on-die.
In short, I think your ‘heroic coders’ are extremely capable and did extremely well for themselves. They had their company bought by Intel; and for a good reason. Intel wanted their ability to pull someone else’s core business into their core business’ realm of operation. Pure and simple.
AMD bought ATI; ever think about why? It’s just cheaper, as Moore’s Law takes individual processor power farther and farther beyond what a person can even imaginably need, to produce chips that have LOTS of power in relation to the features people want. You can reduce consumption by slowing things down, you can produce smaller stuff, but eventually you get to a point where a fast-responding laptop outperforms what people expect, and you need it cheaper.
Cheaper means less chips, less people involved in the manufacture, less shipping of individual parts around, less placement on boards and QA, and less packaging. How do you do all that?
CPU’s enough faster that GPU’s with enough backwards compatibility to make that 100$ drop in price mean more than the performance hit.
I’m not sure if this changed in Windows 7, but I do believe that the Abrash and Sartain code represents best possible performance. I don’t think you can do better, …
TANSTATFC
If you ever read Abrash, you know what that means.
Have you ever actually tried running a 3D game with the crap integrated graphics hardware 3D included on most laptops? It’s utter and complete shit.
The processors, by comparison, are usually pretty decent. Getting a fast CPU and no real 3D support is easy, getting a laptop with a good processor and good 3D performance is expensive. Bringing back a good software renderer for these machines makes all sorts of sense.
A couple of points:
The plan is for Windows 7 to support the full DirectX 11 standard. If the hardware doesn’t support an operation, then Win7 will do it in software. And on a sufficiently fast multicore machine, it’s already faster than some (all?) Intel integrated graphics devices.
Second, Intel’s admitted that when Larabee ships, it’ll be slower than the current ATI/NVidia cards. It’s better than what they have now, and it’s kinda neat, but it’s not a killer chip.
This comment thread is already very long, but I’d like to add one thing:
in his 2008 QuakeCon Keynote John Carmack said that he knows that Id Tech 5 (i.e. the Rage engine), is probably the last polygon engine that Id Software is going to develope. He said that the one guy he currently doesn’t want to be is the guy who, at a big game publisher, has to make the bet on what technology is relevant in 4 years for a next-gen game, because polygons, might be it, or not.
Intel is very much going into a direction where they add current-gen GPU technology to their CPUs so that the next generation of game engines can be build on Intel technology.
You can bet that nVidia is currently working on hardware that is optimized for raytracing and bezier curves, but I think that this comment thread framed the discussion in the wrong way.
That being said, there is another untapped application of these GPU/CPU-hybrids for streaming services like OnLive.
At least Larrabee may provide for fully open source graphics drivers for Linux on day one. Yeah, AMD is starting to move in that direction with thier newest cards as well.
What’s going to be really interesting is the nVidia Tegra, an ARM Core(s) bundled with nVidia graphics. ARM already has excellent open source support, and nVidia is better than AMD in that regard. Hopefully this can lead to a large group of consumers migrating away from Windows and actually using a system that’s secure and safe, yet has the power to do email and web browsing, as well as properly display the high definition videos they’ll want to consume. And of course, with lower power usage.
Pixomatic is HARDLY pointless. I hate to break it to you Jeff, but games are not the only applications that require real-time 3D graphics. For a business application with modest rendering needs, using a software renderer is an excellent way to make sure your app works predictably and reliably on every PC, at least with respect to the 3D graphics part.
Unfortunately, many years ago, I made the mistake of relying on Microsoft’s software renderer that was provided as part of DirectX. This was NOT the reference rasterizer. It was a go-as-fast-as-possible, don’t-get-too-fancy software renderer. It did everything I needed and then some. It was fast enough even on an old P166. It worked 100% reliably while the hardware accelerated renderer failed to start or would BSOD on all the dodgy machines/drivers out there. Once my app got out in the wild, it didn’t take that long for me to forget about the idea of the software renderer as a fallback. The ONLY viable option was to use it exclusively.
So then, what did MS do with this very valuable software renderer? Of course! They killed it off, offering no replacement. Now it’s impossible to run my app on 64-bit Windows without gutting the app to swap out the 3D engine or, more likely, doing a rewrite. (WOW64 doesn’t work on OS components like DirectX DLLs.) How ironic it is that MS is once again providing a software renderer that’s actually meant for real work.
If I had gone with a third-party software renderer like Pixomatic, my app would still be working on every modern computer running Windows. So when you call Pixomatic utterly pointless, I think you’re not seeing the whole picture. It’s about using the right tool for the job, and dependencies and their consequences. Decisions here can easily make or break a company.
One thought I have not yet read: If Intel runs with this in a large enough (read: market altering) way, the market will shift to a set of x86 extensions for which AMD does not have a license. Of course, if Intel drags it’s feet and only utilizes this in a few niches, that will give others the time needed to come up with a similar but possibly better extension set, as we’ve seen before…
You’re using the business perspective to view the effort of writing the software renderer.
I’d wager he did it mostly because someone said it can’t be done.
Also, there are still assembly hacks out there that will beat what the compiler outputs. Writing something in assembly, or at least reading it in my case, maintains the programmer’s awareness of the translation between high level language to assembly.
I’m a bit surprise at how Jeff completely misses this. I always enjoy hearing people saying that learning assembly / C / C++ is useless, while they’re using tools that are written in it.
I’d benefit from that. I estimate I would use a GPU maybe 5% of the time. Far far more cost effective for me to buy dual CPUs.
It’s worth noting that (IIRC) Abrash started that work because the incompatibilities between different cards’ nonstandard OpenGL extensions were such a nightmare. It’s telling that he found it worthwhile to give up a generation or two of performance in order not to have to write code that is half #ifdefs (I don’t know if cross-card OpenGL programming has improved in the ~3 years since I did it, but this was typical then).
Also, as a couple of people already pointed out, there is plenty of software that isn’t performance-bound but still uses state-of-the-art graphics calls for the visual effects (Spore comes to mind, as well as certain data visualization software, and lots of kids’ games). Something like Pixomatic is perfect for these (back in the day, I used Mesa for the same purpose).
Fun fact: the Intel open source drivers on Linux are nerfed. They don’t support OpenGL 2 due to the patent encumbered S3TC texture compression scheme required by the spec.
Thus, most games which require S3TC freak out and crash. UT2004 detects it’s absence and falls back on a (~30 FPS) slower texture compression method. Performance wise, Software rendering is on par with UT’s aforementioned fallback mode when judging by FPS. Software rendering is better than the fallback mode at higher resolutions, because the fallback mode will pause for a millisecond every second or two, while software mode does not.
I’m trying to grok your point, Jeff.
Are you saying that Michael Abrash is extolling the virtues of Larabee because it plays to the strategy behind Pixomatic? And if so, you are saying it doesn’t matter, that it is a failed strategy at the top because video cards do it way better?
Jeff, I don’t understand how Pixomatic or Larrabee is utterly pointless.
Abrash’s articles imply that the Pixomatic effort produced deep insight into how to parallelize and super-optimize a pure software 3D rasterizer. By working with the Pixomatic team, Intel was able to distill these results into an instruction set and architecture that remains pretty general purpose but powerful enough to match GPUs.
Why is this pointless? It will only take the next hot game to include a feature that’s not feasible on a GPU or typical CPU and suddenly the Intel team will be vindicated.
Hmm… maybe I missed your point.
I think the best way to introduce a machine of this power has got to be through video games - specifically written for the system at hand.
There are some commenters above who don’t quite realise that to run ‘normal’ software won’t work. Parallel processing is a style of codeing in it’s own right, using a HAL is all very well but take best advantage of a system code needs to be written specifically. One can’t just take code written for an x86 and expect it to run super quick on a parallel processor machine.
I do suspect that if Nvidia worked with the open source community they could come up with a new console that would make today’s game consoles look like zx-spectrums
on my machine, this took 1.98 seconds in Chrome to render the Original JS RayTracer scene at 320x200.
(make SURE you turn off the display image while rendering option!)
A bit disappointed, today’s Chrome on a much faster machine than 2009 renders the same scene in 1.046 seconds – “only” 1.88x faster.
Also Intel’s Larrabee was cancelled. Pretty sure GPUs killed it stone cold dead.