TransGaming Releases Fast Software 3D Rendering
gavriels writes "TransGaming has just released SwiftShader, an ultra-fast software-only 3D renderer that supports Vertex and Pixel Shaders. SwiftShader dynamically compiles the geometry and rasterization pipelines to produce code that exactly matches the graphics features a game or application is using. Demo download and tech details can be found on their website."
Ad-posts such as this one, wouldn't be as offensive if they would just come out and say that they're an ad-post. I.e., instead of "on their website", say "on our website". And make some sort of comment that, yes, the poster does have a vested interest in the content of the post.
Here's the meat of the article for those who can't be bothered.
TransGaming's SwiftShader technology provides the world's fastest pure software 3D renderer with DirectX 9.0 class features, according to the company, including support for Pixel and Vertex Shaders. SwiftShader is built to provide the same APIs that developers are already using for their games and applications. This makes it possible to directly integrate SwiftShader into applications without any changes to source code. Direct3D 8 and Direct3D 9 compatible APIs are available immediately, and OpenGL-compatible APIs are also under development. Vertex Shader 1.1 and Pixel Shader 1.4 features are currently supported, along with the majority of features used by most developers when producing 3D games and applications.
SwiftShader can perform over 50 times faster than Microsoft's Direct3D Reference Rasterizer in tests with sample applications, and can rival the performance of low end hardware 3D graphics solutions in some cases. SwiftShader achieves this unprecedented level of performance by dynamically compiling highly optimized code specific to an applications 3D rendering needs.
SwiftShader is currently available for x86 CPUs with Intel's SSE multimedia instruction set extensions. SwiftShader runs on Microsoft Windows 98 and higher, and on Linux through TransGaming's Cedega portability technology.
OpenGL is an API, which programmers use to describe a set of graphics primatives.
SwiftShader is a renderer, which draws things.
You would, in fact, program your code in Direct3D or OpenGL, and then use SwiftShader as the renderer, the same way today you would program in Direct3D or OpenGL, and then use your ATI X800 as the renderer. They even mention, in the article, that "OpenGL-compatible APIs are also under development".
The only difference is that, compared to an ATI X800, SwiftShader will be very slow, and compared to the SuperImageCrazyMagic 9000 VGA+++ graphics card in my crappy laptop, SwiftShader will be quite fast.
Obviously I realise that a lot more is needed before desktop Linux taxes off, but if someone could capitalise on this we could have a decent GUI utilised without pissing all over Linux's reputation for not taxing hardware too heavily. (Personally I prefer an understated GUI which uses no resources, but obviously there is a market for eye candy.)
My 3D Texturing Skinning work (under construction)
I realize that I'm just a humble AC, but let me say this: I'm not certain I understand the point here. Casual gamers are exactly that, casual. They're more interested in online play like Java Applets or MIDP Applications for phones than they are in Gee Whiz Bang games that they must install to their computers. So from that perspective, I really don't understand what market TransGaming plans to attack with this new software.
Even if we assume that casual gamers are looking to install games onto their computers, it's hard to say that such gamers wouldn't have at least a basic 3D card to play games on. Even the Intel Integrated Graphics (about as bad as you can get) has decent 3D support. Are the Gee Whiz features of DX9 really all that important to these players?
Formerly known as slow rendering.
With no free licensing for personal and/or academic use available, I don't see that happening. Furthermore, it's only supported on Win 98 and up and Linux. One of the principal strengths of OpenGL is that it works on all Windows flavors, Linux, Unix, Solaris, Mac, ... -- Paul
OpenSource.MathCancer.org: open source comp bio
...saying that it performs up to 50 times better than the Microsoft Reference Rasterizer you're actually calling it slooooow. The REF driver exists with absolutely ZERO optimizations explicitly for the purpose of discerning if a problem is in your code or is in the video card's device driver. Maybe they're confused about the old RAMP and RGB devices you could use to render in software. 50 times faster than REF is pathetic to be honest.
Loading...
...an uber ultra-fast fixed-point math library!
Stating on Slashdot that I like cheese since 1997.
I'm sure that creating this engine was an interesting challenge .. but .. why? 2D only graphics cards don't really exist anymore. It doesn't exist for non-PC platforms so it doesn't really aid portability (though they say in the FAQs it could if someone wrote a "SwiftASM" thing for the target CPU) either.
Is it just a fun toy? Or have I missed something?
http://twitter.com/onion2k
Sure, it *may* be faster than other software rendering solutions, but it still only approaches (that's such a broad term) the performance of low-end cards: "can rival the performance of low end hardware 3D graphics solutions in some cases." Sounds pretty iffy to me. It'll be good in some cases; however, as it is, I doubt it will replace dedicated hardware cards for many people (it's not like low-end cards are very expensive. You can find decent (albeit older) graphics cards for under $20.
I'm not saying this technology isn't useful, it just has limited application in its current state.
This looks like it is meant to compete with Pixomatic from RAD Game Tools. ( http://www.radgametools.com/default.htm ) Perhaps it's cheaper or faster, but pixomatic is not overly pricy and I trust Mike Abrash *now at RAD) has a little bit of experience writing fast renderers :)
-- Too lazy to get a lower UID.
Can it split the rendering load between your GPU and your CPU if your GPU is capable of some of these features? I couldn't find an answer on their website.
Believe it or not, but integrated graphics hold the lion's share of the PC graphics market. Nvidia and Ati are both pretty far behind Intel in terms of install base. This could be very bad for the other vendors: the main reason for the popularity of integrated graphics is cost - Intel itself only holds about a $5 premium on gfx-enabled chipsets over discrete chipsets.
What happens when Microsoft licenses this tech and integrates it into Windows? Suddenly, all anyone needs is a RAMDAC to output framebuffer to VGA, so Intel doesn't need to develop GPUs anymore, and overnight gets a massive performance boost and full DX9 support....
------- "From bored to fanboy in 3.8 asian girls" ----------
Earlier this afternoon, the CEO of TransGaming was found on his office floor with two broken knees. Witnesses observed a pickup truck with the word "nVidia" printed on the side leaving the scene.
I, for one, welcome our new karma-whore sig writing overlords
Anyone have time to, say, download this driver and fire up UT2004 or somesuch and test the framerate using software rendering vs their 3d card (with all other settings being equal)? Of course, this wouldn't be particularly scientific, but it would at least give some idea about how well this thing performs and whether it's useful.
...is what demogroup they were before they went commercial, because that's the only crowd I can see with the drive and desire to create something like this. One of my group's coders still gets a stiffy for software rendering, and I know he's not the only demoscener that does.
The site is /.'d, so I can't rtfa.
Swiftshader is based on the sw-shader project, which produced very good quality output very quickly using SoftWire to compile the rasterizers. A lot of other software 3D implementations only optimize the most common cases and fall back on very slow, general purpose rasterizers to do the rest, often using giant switch statements or function pointers in their innermost loops to handle the countless combinations of blending, lighting, and raster options available. Even precompiling them all with a generator script or clever use of macros is infeasable due to the number of combinations, and just one of those will slow any 3D rendering to a crawl, which is the problem that sw-shader solved, by optimizing all cases.
What's good is that the project is once again under active development, and it's no longer windows-only. The downside is that it's gone commercial. With so few contributors other than the original author, that sort of thing can happen to an OSS project. He put a lot of hard work into it though, writing a substantially complete DirectX 9 replacement based on his library. Transgaming actually had to purchase two projects for this, because sw-shader depends on SoftWire.
SwiftShader code seems to be directly based on SoftWire and swShader, which used to be both SourceForge projects.
--
What you're suggesting is that Microsoft might license tech from a company whose main product is a re-implemenation of the Microsoft Windows SDK for *NIX. If this happens, I'll either eat my hat or die of laughter. Oh the irony.
Claiming that it's 50 times faster than some other software renderer is like claiming your racecar is 50 times faster than any other racecar that has no wheels.
What's the point?
Pull the other one, it's got bells on. You expect us to believe that the slashdot editors actually edited a submission?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Can it take advantage of multiple processors?
For years, some analysts claimed that ordinary processors would eventually obsolete 3D accelerators, because they would be fast enough to handle all of the rendering in software. Since graphics processing can usually make pretty good use of parallelism, then perhaps a package like this along with multiple CPUs is the "wave of the future"?
Obviously not now... but in 20 years?
I wonder if this is possibly a take off of an open source project called swShader (its on source forge.) I've had some contact with the author of swShader, Nicholas Cappens(spelling likely incorrect), we discussed the unique approach he has taken to polygon filling/texturing. swShader also has DX 8 & 9 interfaces and a dll which could stand in to interface with regular DirectX games. While its an interesting piece of work, I hate to see when an OSS project, particularly one with one primary author(the owner if you will) gets taken and then commercialized becuae I'm sure he'll never see a penny, despite having written most of it. I don't know that thats the case here or not, but I hope it isn't. I guess its part of the deal when you open it up to OSS but it would still stink. Then again, maybe he's commercialized it himself or got hired to produce it, which I would be all for.
Vertex shaders, sure. In fact, DirectX does just that. If you lack hardware vertex shaders, DirectX will happily do them in software. It's not as fast, of course, since it hits your CPU, but it works. However other things can't be done, at least not yeat. Pixel shaders would be an example. They are later in the chain, after the graphics card has done it's work, even if it's a simple one. So that either requires doing it all in software, or sending data from the graphics card back to the CPU, doing more work, then back to the graphics card.
With AGP it's right out. PCIe makes it a remote possibility, the bus would work, but it's still not a real solution. It would end up being too slow to matter. The thing is you can get a cheap 3d card that WILL do it, though slow (any Radeon 9200 or above), but faster than software.
So I don't know about killer app. Certianly not for Windows. As it stands, DirectX does this to the extent that it's useful. Things that can be done in software to a reasonable speed will be, if necessary. Things that can't are simply excluded. It's probably the best compramise from a consumer standpoint.
Actually shaders as used on graphics hardware and the dynamically generated code used by SwiftShader share a lot of resemblance. The biggest difference is that the GPU is designed specifically to run shader code, while to make it run on the CPU we need to translate it to MMX and SSE instructions. The GPU also has many more pipelines and dedicated texture samplers. Other than that there's a convergence in technology as graphics hardware gets more programmable and reuses the same units for different threads (i.e. unified architecture).
So, to answer your question more directly, I doubt that any of the technology used in SwiftShader can further improve hardware rendering performance. But I do see an evolution in CPU thread parallelism...
There is no OpenGL interface yet, but I expect that Doom 3 will be nearly playable on a powerful CPU at low detail. Even shadows might be possible, because stenciling requires very little operations per pixel and MMX allows to process up to eight pixels in parallel.
Anyway, it's not our immediate goal to support the latest games. The people playing Doom 3 really know they need a powerful graphics card. But once it becomes feasible to run it on the CPU, we'll let you know...
Not all systems come with good hardware rendering. And even though an upgrade is relatively cheap, not everyone is willing to pay that price for casual gaming, tons of people don't know/care how to do a graphics card upgrade, and many systems simply can't be upgraded (laptops in particular). TransGaming is all about portability. Whether from Windows to Linux, Mac to PlayStation, hardware to software... I can hardly imagine a better company for releasing a product like SwiftShader.