Our primary market is currently the casual games. They are starting to use the Direct3D 9 API and even simple shaders. This allows for faster development, with more eye candy and more creativity. First DirectDraw got removed from the DirectX SDK, and now also the fixed-function pipelines are rarely used. This is certainly a good evolution but unfortunately not everybody has the proper hardware yet and for casual games this is the most critical.
This is a new market, for new games. Pixomatic has little to offer here because it is limited to fixed-function processing with only two textures (which even the most crippled graphics solution is capable of). SwiftShader has almosts complete Direct3D 8.1 support, Direct3D 9 features are under development, and it's performance is best-in-class.
Regarding Direct3D 9 shaders versus Direct3D 8.1 shaders, yes, they can be significantly longer and more complex. But they don't have to be. We see a trend where every game starts using shaders, even if they could have used the fixed-function pipelines. For the simpler games, SwiftShader can provide adequate performance.
So Quake was irrelevant, not acceptable at all? The fact is that nowadays the PCU is almost a hundred times more powerful, and can run the effects of the previous generations of games. Max Payne for example was very popular and in those days used the most advanced 'hardware' features, but now runs smoothly on SwiftShader. And for our current main market, the casual games, it's more than adequate. These games, which were previously mostly limited to 2D (greatly because of the lack of proper 3D hardware on the systems of the target end-users) can now be written using the popular and powerful Direct3D API.
You're right that currently the main Direct3D 9 specific features are not supported yet (although vs 2.0 is except branching instructions don't work properly). But complete support is under development and, depending on demand, could see the daylight sooner than you might expect. Performance-wise you also don't have to worry that it will run at 0.01 FPS. DirectX 8.1 shaders run at highly interactive framerates for modest applications and there's no reason why DirectX 9 shaders will decimate performance.
Of course, I certainly don't expect Unreal Tournament 2007's long shaders to run smoothly yet. But let's look at that again after 2007. Of course I fully realize that the CPU will always be much slower than the GPU. But I expect some nice things to happen with SwiftShader's technology in the future, although I can't discuss that in public.
SwiftShader is valuable with or without comparing it to the reference rasterizer. I don't think I used it as an argument here. It's a fallback for when no hardware support is available and it offers the best performance possible on a CPU.
I can confirm that ONS-Torlan is quite slow compared to medium and small sized maps. We primarily used DM-Ranking for performance analysis. I also saw rendering errors, but different ones than yours. By setting MaxPixelShaderVersion=0 they were gone. So you can probably also get correct results by altering the settings. Performance might also vary significantly depending on a few critical settings.
Please note that we never had any contact with the UT2004 development team, so ensuring good compatibility was hard and there hasn't been any rigorous testing with all settings. Since UT2004 already has a software renderer it was never our highest priority. Of course with new clients we make sure everything works flawlessly, and by working closely together we can quickly locate and fix bugs.
While the casual gamer might not care much about shader effects itself, if the application uses it and his hardware doesn't support it he can't run it. That he does care about. And nowadays even simple kid's games start to use shaders, just because it's easier to develop. A Voodoo 3 does not support pixel shaders, neither does a Geforce 2.
SwiftShader won't need a subsription as far as I know. Game developers buy a license for a particular game and distribute a copy of SwiftShader with it. The people buying the game probably won't see any difference in price, or even a lower price, because SwiftShader is intended to reduce support costs for game companies. Anyway I don't know the details. If you're interested please constact sales@transgaming.com.
A Quadro FX 3000 is DirectX 9 class hardware (and very expensive) so it's no surprise it runs the DirectX 8 EffectEdit sample fine. A better comparison is my laptop's integrated Intel Extreme Graphics 2, which doesn't support pixel shaders so two of the effects are not displayed correctly.
SwiftShader already supports HLSL, as long as it can be compiled to ps 1.4 or vs 1.1. It has no restrictions on instruction count and register access by the way. Support for ps/vs 2.0 and higher is definitely planned. I haven't seen any shader support for Pixomatic yet.
Performance-wise almost all integrated graphics will be faster. But some features are not supported by the hardware and then SwiftShader is automatically the winner.:-)
Ah, you've got a point there. I wasn't aware that the reference rasterizer can't be freely redistributed. Still, SwiftShader is aimed at game developers, so I think it's useful to have the comparison. For example the EffectEdit sample only runs on the reference rasterizer and SwiftShader totally on the CPU, but SwiftShader is way faster. I realize that the reference rasterizer was never intended to be fast, but still, it's a lot nicer to see the samples run on SwiftShader than on the reference rasterizer. It just proves that a software renderer with modern features doesn't have to be terribly slow.
Pixomatic has a Direct3D 9 interface but it's very limited. It doesn't support pixel shaders, vertex shaders, cube maps, texture compression, vertex blending, etc. It actually maps to the underlying Direct3D 7 class features of the Pixomatic rendering core. It certainly is fast at this but I wouldn't call it Direct3D 9 emulation. SwiftShader has almost complete Dirct3D 8.1 support and will get Direct3D 9 features in the not so distant future.
The generated code heavily relies on MMX and SSE instructions, which are relatively well suited for pixel and vertex processing. Mesa makes very little use of these instructions, and doesn't have dynamic code generation at all as far as I know.
Indeed SwiftShader can function as middleware to solve hardware rendering problems (mostly missing features). It's not exactly ideal, but game developers generally aim for quite high graphics requirements. Sometimes because they want the game to look good on modern hardware, but also because the latest API is easier to use. Unfortunately, checking hardware capabilities and providing alternative rendering paths is very hard, especially since they work under a lot of time pressure. For games that actually don't need incredible fillrate to be playable, SwiftShader can be a reliable fallback.
Of course you're totally right that most gamers will still want to invest in upgrading their graphics hardware. But in the situations where this is not desired or impossible, SwiftShader opens up new possibilities.
The key here is that the generated 'pipelines' are cached. A game typically uses only a couple hundred render states/shaders. So the code is only generated when it's not yet/any more in the cache.
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.
It's Nicolas Capens;)
Just to confirm: yes, SwiftShader is based on swShader (and SwiftAsm is based on SoftWire). Both open-source projects got licensed by TransGaming and I started working for them. Never regretted it. TransGaming's founder is a great visionary and he gave me the optimal opportunity to turn swShader into a commercial quality product. Much of it has been rewritten and we've reached goals we hardly could imagine several months ago. And this is really only the beginning...
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...
1. Yes, the target market is pretty small when looking at the total graphics industry. But it exists and it's big enough for a company like TransGaming. There are many systems out there (mainly laptops) with powerful processors but graphics chips that don't support for example pixel shaders. SwiftShader is also a fallback for when hardware rendering is unreliable or fails (driver issues, broken DirectX installation, etc). For these situations it can fill the needs without getting thousands of support calls.
2. Slashdot is all about technology isn't it? And from that point of view SwiftShader is ground-breaking. Other high performance software can benefit a lot from dynamic code generation. I'm thinking physics processing, sound and image processing, etc. This is only the beginning.
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 definitely a market for this. Yes, it's small, but even a tiny fraction of the low-end graphics industry is huge for a company like TransGaming. SwiftShader certainly can't replace -current- integrated graphics solutions, but it can defeat older dedicated hardware, mainly in features, but sometimes also in performance. And it's software, so it's an easy upgrade, and when bundled with a game it can be very cheap.
You're definitely right that it has limited application now. But we're only just getting started with this technology and with the next generation of CPUs it might become a real alternative for integrated graphics. It's not going to be the ultimate way to play the newest blockbuster game, but I do see great potential for market growth.
Please try the demos. You will see that they run at pretty impressive performance for software rendering, often many times faster than 50 times the reference rasterizer.
The comparison with REF in the press release is just to indicate that SwiftShader is way faster than the only other alternative for Direct3D 8/9 emulation.
One of the biggest problems with DirectX and OpenGL hardware rendering is managing the graphics card's capabilities. You never know on what hardware your application will be run. With SwiftShader, you get a fixed set of features so your application is guaranteed to work correctly on all other systems. It's a reliable fallback with the best performance you can get from your CPU. That's not enought for Doom 4 or Half-Life 3, but it's definitely useful for casual games.
And this is only the beginning. The features will be extended to DirectX 9, and DirectX 10 once it's out. So it can function as a fallback for many more applications. Performance-wise it will also improve a lot over the next few years. Multi-core CPUs based on the Pentium M architecture will provide the performance for a whole new class of applications.
There were two main reasons why hardware rendering became highly popular: performance, and standardized features. Today SwiftShader makes a gigantic leap forward in terms of software rendering features. You're no longer limited by having one, maybe two textures, but get nearly the whole DirectX 8 feature set. On the performance level, the CPU and GPU will also converge a little, because GPUs are hitting the same physical limits now, and CPUs have only just started increasing thread parallelism.
Unreal Tournament 2004 is a DirectX 8 game so it was never intended to run in DirectX 9 mode. Either way, is will be easy to fix.
I have a Pentium M 1.4 GHz and get 16 FPS average in UMark for the DM-Rankin map using 2 bots. That's at 640x480 with bilinear filtering on. The lightning shaft doesn't get rendered when the framerate is below a certain level (dynamic LOD). But you should definitely get better performance than 5-8 FPS average and then you'll see it. I have never encountered any texture issues like you describe. Could you tell me what map this was in and which version you have? Both the demo version and v3355 work fine for me.
Thank you for your feedback.
Please note that the reference rasterizer scales very badly, while SwiftShader actually becomes more efficient with more features enabled (e.g. sampling two textures instead of one doesn't halve the framerate). This is because of the dynamic code generation. Only the actual operations being performed are written as binary code and executed. The setup costs is almost constant, so using longer shaders results in relatively little extra code being generated. So for more complex scenes SwiftShader can perform much better than 50x the reference rasterizer.
The reference rasterizer is the only other software renderer with DirectX 8/9-class features, so the 50x is just to ensure you that when you need shader emulation there is no better alternative.
That's true, but not everybody is willing to go buy a new graphics card just to play a casual game. Many don't even know how to open their computer case. And for laptops it's often not possible to upgrade at all. So here SwiftShader can be a valuable fallback.
Slashdot Mirror
Our primary market is currently the casual games. They are starting to use the Direct3D 9 API and even simple shaders. This allows for faster development, with more eye candy and more creativity. First DirectDraw got removed from the DirectX SDK, and now also the fixed-function pipelines are rarely used. This is certainly a good evolution but unfortunately not everybody has the proper hardware yet and for casual games this is the most critical.
This is a new market, for new games. Pixomatic has little to offer here because it is limited to fixed-function processing with only two textures (which even the most crippled graphics solution is capable of). SwiftShader has almosts complete Direct3D 8.1 support, Direct3D 9 features are under development, and it's performance is best-in-class.
Regarding Direct3D 9 shaders versus Direct3D 8.1 shaders, yes, they can be significantly longer and more complex. But they don't have to be. We see a trend where every game starts using shaders, even if they could have used the fixed-function pipelines. For the simpler games, SwiftShader can provide adequate performance.
And I just meant to say hi...
So Quake was irrelevant, not acceptable at all? The fact is that nowadays the PCU is almost a hundred times more powerful, and can run the effects of the previous generations of games. Max Payne for example was very popular and in those days used the most advanced 'hardware' features, but now runs smoothly on SwiftShader. And for our current main market, the casual games, it's more than adequate. These games, which were previously mostly limited to 2D (greatly because of the lack of proper 3D hardware on the systems of the target end-users) can now be written using the popular and powerful Direct3D API.
You're right that currently the main Direct3D 9 specific features are not supported yet (although vs 2.0 is except branching instructions don't work properly). But complete support is under development and, depending on demand, could see the daylight sooner than you might expect. Performance-wise you also don't have to worry that it will run at 0.01 FPS. DirectX 8.1 shaders run at highly interactive framerates for modest applications and there's no reason why DirectX 9 shaders will decimate performance.
Of course, I certainly don't expect Unreal Tournament 2007's long shaders to run smoothly yet. But let's look at that again after 2007. Of course I fully realize that the CPU will always be much slower than the GPU. But I expect some nice things to happen with SwiftShader's technology in the future, although I can't discuss that in public.
Say hi to Daniel Rohrer for me.
SwiftShader is valuable with or without comparing it to the reference rasterizer. I don't think I used it as an argument here. It's a fallback for when no hardware support is available and it offers the best performance possible on a CPU.
Thank you for the details!
I can confirm that ONS-Torlan is quite slow compared to medium and small sized maps. We primarily used DM-Ranking for performance analysis. I also saw rendering errors, but different ones than yours. By setting MaxPixelShaderVersion=0 they were gone. So you can probably also get correct results by altering the settings. Performance might also vary significantly depending on a few critical settings.
Please note that we never had any contact with the UT2004 development team, so ensuring good compatibility was hard and there hasn't been any rigorous testing with all settings. Since UT2004 already has a software renderer it was never our highest priority. Of course with new clients we make sure everything works flawlessly, and by working closely together we can quickly locate and fix bugs.
While the casual gamer might not care much about shader effects itself, if the application uses it and his hardware doesn't support it he can't run it. That he does care about. And nowadays even simple kid's games start to use shaders, just because it's easier to develop. A Voodoo 3 does not support pixel shaders, neither does a Geforce 2.
SwiftShader won't need a subsription as far as I know. Game developers buy a license for a particular game and distribute a copy of SwiftShader with it. The people buying the game probably won't see any difference in price, or even a lower price, because SwiftShader is intended to reduce support costs for game companies. Anyway I don't know the details. If you're interested please constact sales@transgaming.com.
A Quadro FX 3000 is DirectX 9 class hardware (and very expensive) so it's no surprise it runs the DirectX 8 EffectEdit sample fine. A better comparison is my laptop's integrated Intel Extreme Graphics 2, which doesn't support pixel shaders so two of the effects are not displayed correctly. SwiftShader already supports HLSL, as long as it can be compiled to ps 1.4 or vs 1.1. It has no restrictions on instruction count and register access by the way. Support for ps/vs 2.0 and higher is definitely planned. I haven't seen any shader support for Pixomatic yet. Performance-wise almost all integrated graphics will be faster. But some features are not supported by the hardware and then SwiftShader is automatically the winner. :-)
Ah, you've got a point there. I wasn't aware that the reference rasterizer can't be freely redistributed. Still, SwiftShader is aimed at game developers, so I think it's useful to have the comparison. For example the EffectEdit sample only runs on the reference rasterizer and SwiftShader totally on the CPU, but SwiftShader is way faster. I realize that the reference rasterizer was never intended to be fast, but still, it's a lot nicer to see the samples run on SwiftShader than on the reference rasterizer. It just proves that a software renderer with modern features doesn't have to be terribly slow.
Pixomatic has a Direct3D 9 interface but it's very limited. It doesn't support pixel shaders, vertex shaders, cube maps, texture compression, vertex blending, etc. It actually maps to the underlying Direct3D 7 class features of the Pixomatic rendering core. It certainly is fast at this but I wouldn't call it Direct3D 9 emulation. SwiftShader has almost complete Dirct3D 8.1 support and will get Direct3D 9 features in the not so distant future.
Yes, I am the author of swShader and SoftWire, and the lead programmer of SwiftShader and SwiftAsm.
It's probably best to just e-mail sales@transgaming.com for making such inquiries.
The generated code heavily relies on MMX and SSE instructions, which are relatively well suited for pixel and vertex processing. Mesa makes very little use of these instructions, and doesn't have dynamic code generation at all as far as I know.
Indeed SwiftShader can function as middleware to solve hardware rendering problems (mostly missing features). It's not exactly ideal, but game developers generally aim for quite high graphics requirements. Sometimes because they want the game to look good on modern hardware, but also because the latest API is easier to use. Unfortunately, checking hardware capabilities and providing alternative rendering paths is very hard, especially since they work under a lot of time pressure. For games that actually don't need incredible fillrate to be playable, SwiftShader can be a reliable fallback.
Of course you're totally right that most gamers will still want to invest in upgrading their graphics hardware. But in the situations where this is not desired or impossible, SwiftShader opens up new possibilities.
The key here is that the generated 'pipelines' are cached. A game typically uses only a couple hundred render states/shaders. So the code is only generated when it's not yet/any more in the cache.
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.
It's Nicolas Capens ;)
Just to confirm: yes, SwiftShader is based on swShader (and SwiftAsm is based on SoftWire). Both open-source projects got licensed by TransGaming and I started working for them. Never regretted it. TransGaming's founder is a great visionary and he gave me the optimal opportunity to turn swShader into a commercial quality product. Much of it has been rewritten and we've reached goals we hardly could imagine several months ago. And this is really only the beginning...
Max Payne, Unreal Tournament 2004, Max Payne 2, and 3DMark2001 SE work very well (sorted from fast to slower).
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...
1. Yes, the target market is pretty small when looking at the total graphics industry. But it exists and it's big enough for a company like TransGaming. There are many systems out there (mainly laptops) with powerful processors but graphics chips that don't support for example pixel shaders. SwiftShader is also a fallback for when hardware rendering is unreliable or fails (driver issues, broken DirectX installation, etc). For these situations it can fill the needs without getting thousands of support calls. 2. Slashdot is all about technology isn't it? And from that point of view SwiftShader is ground-breaking. Other high performance software can benefit a lot from dynamic code generation. I'm thinking physics processing, sound and image processing, etc. This is only the beginning.
At the moment it's single-threaded, but there are definitely plans let it use make use of dual/multi-core technology once it becomes common.
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 definitely a market for this. Yes, it's small, but even a tiny fraction of the low-end graphics industry is huge for a company like TransGaming. SwiftShader certainly can't replace -current- integrated graphics solutions, but it can defeat older dedicated hardware, mainly in features, but sometimes also in performance. And it's software, so it's an easy upgrade, and when bundled with a game it can be very cheap.
You're definitely right that it has limited application now. But we're only just getting started with this technology and with the next generation of CPUs it might become a real alternative for integrated graphics. It's not going to be the ultimate way to play the newest blockbuster game, but I do see great potential for market growth.
Please try the demos. You will see that they run at pretty impressive performance for software rendering, often many times faster than 50 times the reference rasterizer.
The comparison with REF in the press release is just to indicate that SwiftShader is way faster than the only other alternative for Direct3D 8/9 emulation.
One of the biggest problems with DirectX and OpenGL hardware rendering is managing the graphics card's capabilities. You never know on what hardware your application will be run. With SwiftShader, you get a fixed set of features so your application is guaranteed to work correctly on all other systems. It's a reliable fallback with the best performance you can get from your CPU. That's not enought for Doom 4 or Half-Life 3, but it's definitely useful for casual games. And this is only the beginning. The features will be extended to DirectX 9, and DirectX 10 once it's out. So it can function as a fallback for many more applications. Performance-wise it will also improve a lot over the next few years. Multi-core CPUs based on the Pentium M architecture will provide the performance for a whole new class of applications. There were two main reasons why hardware rendering became highly popular: performance, and standardized features. Today SwiftShader makes a gigantic leap forward in terms of software rendering features. You're no longer limited by having one, maybe two textures, but get nearly the whole DirectX 8 feature set. On the performance level, the CPU and GPU will also converge a little, because GPUs are hitting the same physical limits now, and CPUs have only just started increasing thread parallelism.
Unreal Tournament 2004 is a DirectX 8 game so it was never intended to run in DirectX 9 mode. Either way, is will be easy to fix. I have a Pentium M 1.4 GHz and get 16 FPS average in UMark for the DM-Rankin map using 2 bots. That's at 640x480 with bilinear filtering on. The lightning shaft doesn't get rendered when the framerate is below a certain level (dynamic LOD). But you should definitely get better performance than 5-8 FPS average and then you'll see it. I have never encountered any texture issues like you describe. Could you tell me what map this was in and which version you have? Both the demo version and v3355 work fine for me. Thank you for your feedback.
Please note that the reference rasterizer scales very badly, while SwiftShader actually becomes more efficient with more features enabled (e.g. sampling two textures instead of one doesn't halve the framerate). This is because of the dynamic code generation. Only the actual operations being performed are written as binary code and executed. The setup costs is almost constant, so using longer shaders results in relatively little extra code being generated. So for more complex scenes SwiftShader can perform much better than 50x the reference rasterizer. The reference rasterizer is the only other software renderer with DirectX 8/9-class features, so the 50x is just to ensure you that when you need shader emulation there is no better alternative.
That's true, but not everybody is willing to go buy a new graphics card just to play a casual game. Many don't even know how to open their computer case. And for laptops it's often not possible to upgrade at all. So here SwiftShader can be a valuable fallback.