[vazel]

Originally Posted by Davros

wouldnt this be of benefit for those games which dont run properly (rendering errors) on modern cards + drivers
examples:
system shock 2
theif 2
crimson skies

edit:
Just tried crimson skies and it just doesnt run with swiftshader installed

This was the first thing I thought of when I saw this and was wondering about Crimson Skies too. I love this game so much I was seriously considering making my next card ATi to have it work properly. Only thing that troubles me is ATi cards don't have fixed aspect ratio scaling. Hopefully Crimson Skies will work in a future iteration of SS.

[AnarchX]

Very amazing project!

But your older version, with its high MMX-dependence, still seems to offer a higher per- clock/core-performance, if you use a CPU with usable MMX-implementation, like Pentium-M, Netburst-Pentium, Athlon XP, how some tests under 3DMark2001SE show:
http://www.forum-3dcenter.org/vbulle...d.php?t=267950
(from page 3 test with 2.0)

[Arun]

Originally Posted by AnarchX

But your older version, with its high MMX-dependence, still seems to offer a higher per- clock/core-performance, if you use a CPU with usable MMX-implementation

Read the FAQ - they clearly admit SwiftShader 2.0 only delivers 70% to 110% of the performance of previous generation software rasterizers for legacy code (also depending on the quality settings), and that matches those 3DMark01SE numbers very well.

Which brings me to a question I had: what's the internal shader precision for DX8 games? Is it also FP32 now?

[Davros]

vazel im sure they added that in a recent driver - best to ask one of the ati users

edit found it its in cats 8.3
- GPU accelerated digital panel scaling, with totally new "maintain aspect ratio" option to prevent distorted aspect rates'

check with an ati user to make sure its working or ati have doen something stupid and removed it in later drivers

[Jawed]

Originally Posted by Nick

The theoretical floating-point performance of modern CPUs is actually close to that of mid-range graphics cards (for multiply-add). So in my experience software rendering can handle pure arithmetic work really well. Texture sampling however requires a lot of instructions to implement.

Do you have a breakdown for address generation, decompression and filtering, say for simple 8bpc bilinear?

You could use RenderMonkey to compare the costs. I'd actually be quite interested in the results myself. Transcendental functions like log and exp also don't map directly to x86 instructions.

So I could install RenderMonkey, put the SS DX9.dll in the same folder and get some realtime execution stats from some simple shaders? Ooh, something to play with later...

Note though that it's never a bottleneck in the ALU:TEX sense of graphics hardware. There are no dedicated texture samplers that could be a bottleneck on their own. It's just a shift in what code is spent most cycles on.

Hmm, yeah I wasn't thinking clearly there, particularly having already discussed this concept in some detail with respect to Larrabee

Presumably, as a result of this, SS doesn't need to have many pixels in flight to hide texturing latency. But I imagine future CPUs' considerable bandwidth increases mean that you'll want to increase this count as time goes by. Does SS "self-calibrate" this count dependent upon detected bandwidth?

Jawed

[Nick]

Originally Posted by Voltron

Just curious Nick, if you can discuss this, whether you think there will be commercial interest in this version? Or is it more of a research thing until high performance software rendering is really viable.

Feel free to contact swiftshader@transgaming.com for official statements, but my personal view is that the current release has great value for the casual games market and desktop applications that use 3D. The casual games market is surprisingly large. If you look at the top game sales of the past few years it includes titles such as The Sims 2 (100 million copies - versus for instance 2 million for a game like BioShock), which don't demand high performance at all. From a rapid development perspective it's tempting for casual game developers to nowadays only have one code path and require Direct3D 9 support. And because they can't stay behind on eye candy completely they use advanced shaders more and more. The industry's determination to abandon the fixed-function pipeline and focus on HLSL rapidly makes Shader Model 2.0 a minimum requirement.

SwiftShader can also help reduce QA and support costs. It will generate exactly the same output on any system, and provides a fallback in case of hardware/driver/runtime issues. This is also why it can be useful for medical applications. It's important that every doctor around the world sees the same 3D images.

I'm totally aware that the CPU performance of systems without Shader Model 2.0 graphics hardware is limited, but I'm confident that it's sufficient to keep SwiftShader commercially interesting for our primary market of casual gaming. But the ambition doesn't stop there. New systems get equipped with ever faster CPUs while IGPs for 'office systems' only need to provide the bare minimum of performance. So I believe that they are slowly cathing up. A good analogy is sound cards. Fifteen years ago you needed a dedicated sound card to get anything more than bleeps. Then they were integrated into the chipset. And nowadays the vast majority of people are happy with a tiny analog chip and the actual processing being done in a software driver (thankfully making use of MMX/SSE). Despite hardware solutions still being vastly superior it's not cost-effective for most.

Of course graphics is far more complex than sound, and new applications keep pushing the limits further, but the range of applications that can run in software is steadily increasing. Today it's limited to casual games but tomorrow it might include popular games (think World of Warcraft) that don't really lose popularity despite what some may call 'outdated' graphics. So for SwiftShader 2.0 it was important to take advantage of multi-core and show future potential.

To conclude; I'm quite excited about making software rendering a viable alternative again in several years, while also being confident that it already has great commercial potential today.

[Nick]

Originally Posted by Davros

now that was uncalled for
/Davros cries - you'll never let me live it down will you, Im sorry i know my actions brought shame on B3d, i'll never do it again I promise........

Now, now, don't worry, I've already bought some extra drives and sent you the bill. It's some cheap 128 GB solid-state drives in RAID 6.

[Davros]

No No
im not crying because you have too little free space, but because I have too much
read this you'll understand
http://forum.beyond3d.com/showthread.php?t=47534
ps: if theres any of those you'd like me to test with swiftshader give us a holler...

pps: did you manage to look at crimson skies - there are a few b3d readers who would love to play it again

[Nick]

Originally Posted by vazel

Hopefully Crimson Skies will work in a future iteration of SS.

It appears to be a Direct3D 7 game, while SwiftShader is Direct3D 8 and 9.

Do you think there's a considerable market for supporting Direct3D 7 and lower? I remember 'Aliens versus Predator' being another game that no longer runs on current hardware but still having some fans...

[Nick]

Originally Posted by AnarchX

But your older version, with its high MMX-dependence, still seems to offer a higher per- clock/core-performance, if you use a CPU with usable MMX-implementation, like Pentium-M, Netburst-Pentium, Athlon XP, how some tests under 3DMark2001SE show:
http://www.forum-3dcenter.org/vbulle...d.php?t=267950
(from page 3 test with 2.0)

SwiftShader 2.0 defaults to higher quality. For starters it computes the mipmap LOD per quad instead of per polygon and uses higher precision perspective correction. I'm pretty sure that at equal quality 2.0 would perform equal or better than 1.0. And in the case some application would be slower it's quite easy to locate the bottleneck and revert to the old approach or find an even better solution. That's the beauty of software; we can tailor a version specifically for a client's application to make things significantly faster.

Per-polygon mipmapping has been disabled in this release (to allow dependent texture reads and gradient instructions), but some other performance/quality settings can be controlled with SwiftConfig.

[Davros]

To be honest i dont.
the guy who makes glidos http://www.glidos.net/ which lets people play dos glide based games (a much bigger market imho) claims to make very little money
Most dx7 and below games actually run fine
as for avp after 2 years of fans pleading with nvidia on their forums and being ignored
some guy turned up found out the problem and fixed it, the fix was later put into the official driver

the only other games which spring to mind are system shock 2 + theif 2 they run but they render the textures poorly

[Nick]

Originally Posted by Davros

No No
im not crying because you have too little free space, but because I have too much
read this you'll understand
http://forum.beyond3d.com/showthread.php?t=47534

Oh. Actually I have more disk space than you then: 74 GB + 200 GB + 500 GB.

ps: if theres any of those you'd like me to test with swiftshader give us a holler...

That's not really necessary, but thanks a lot for the offer. If you do find a game that doesn't run correctly any information is higly appreciated though.

[Davros]

Originally Posted by Nick

Oh. Actually I have more disk space than you then: 74 GB + 200 GB + 500 GB.

yes but you dont suffer the shame of not having it full up with gaming goodness

[Nick]

Originally Posted by Davros

To be honest i dont.
the guy who makes glidos http://www.glidos.net/ which lets people play dos glide based games (a much bigger market imho) claims to make very little money
Most dx7 and below games actually run fine
as for avp after 2 years of fans pleading with nvidia on their forums and being ignored
some guy turned up found out the problem and fixed it, the fix was later put into the official driver

Yeah, these driver issues are mostly only temporary, leaving little opportunity to offer an alternative, especially in the form of a software renderer.

[Davros]

i was refering to the market for a renderer for dx7 and below games as there are very few which dont work
dx8 and above is a different matter but i think your market is devs/publishers to bundle with their games not end users

[Nick]

Originally Posted by Jawed

Do you have a breakdown for address generation, decompression and filtering, say for simple 8bpc bilinear?

Sorry, the exact details could reveal IP. But you can probably imagine that each of these steps take multiple instructions to implement, versus a nearly 1-to-1 translation for add, mul, dot4, etc. With SSE5/AVX CPUs will even have fused multiply-add... Compared to that texture sampling is very expensive (though per-component shift and multiply-add do optimize address generation). Again, a gather instruction would be quite useful...

So I could install RenderMonkey, put the SS DX9.dll in the same folder and get some realtime execution stats from some simple shaders?

Sure. Press 's' to see the stats. By varying resolution you can get an idea of how much time is spent doing vertex processing and setup, versus pixel processing.

Presumably, as a result of this, SS doesn't need to have many pixels in flight to hide texturing latency.

Automatic prefetch and out-of-order execution do a great job as far as I'm aware. And Hyper-Threading also means that at a hardware level twice the work is "in flight".

[darkblu]

hey Nick, good stuff there! any plans for arbvp1/fp1?

[NeARAZ]

Just tried it on unit & benchmark tests we have for Unity...

Almost all rendering unit tests pass correctly (has some issues with attenuation of point vertex lights and a couple of other minor things)! SwiftShader 1.x demo used to crash on some of those, so 2.0 release is a huge step forward.

Performance wise, I only compared Core2Quad + Radeon 3850 versus same CPU with ShiftShader. Obviously it runs 30 to 100 times slower, but hey. Will compare same CPU with Intel 965 for something more in the same ballpark.

Color me impressed! Amazing work.

[Jawed]

Some performance and screenshot comparisons, using an 8500GT as a comparison.

http://www.pcgameshardware.de/aid,63..._CPU_berechnet

Jawed

[big4ared]

Nice job!!

I'm not up to speed on PC assembly, but are you taking advantage of any instructions similar to the VMX ops on the Xenon? If not, how much do you think it would help?

[big4ared]

Originally Posted by big4ared

Nice job!!

I'm not up to speed on PC assembly, but are you taking advantage of any instructions similar to the VMX ops on the Xenon? If not, how much do you think it would help?

Quick clarification...what I meant by the last statement is how much would it help performance if we had an instruction set standard to the Xenon's in all pcs.

[Mobius1aic]

Very interesting, but it'll take a much more powerful CPU to get results worth wanting.

[Davros]

just tried tribes 3 - vengance (uses unreal engine 2)
and get the following error


the game does run though but im getting i guess 5fps at most

[Nick]

Originally Posted by big4ared

I'm not up to speed on PC assembly, but are you taking advantage of any instructions similar to the VMX ops on the Xenon? If not, how much do you think it would help?

The equivalent for x86 processors is SSE, which SwiftShader already uses extensively. SSE has several extensions of its own, and SwiftShader supports up to SSSE3 (Supplemental SSE3 - introduced with Core 2 Duo). The most recent Penryn architecture based CPUs feature SSE4, and Intel recently released details about AVX, which extends the registers from 128-bit to 256-bit.

[wingless]

I wonder if Larrabee can be made to run SwiftShader to showcase how well it renders x86 3D graphics. I can't wait to see comparisons with Nehalem as well.