Software renderer beating Radeon/GeForce

[Nick]

Ok not performance-wise but...

I've created a software renderer which supports ps 2.0 shaders. Unlike the reference rasterizer, it is not an interpreter but an optimized JIT compiler using SIMD instructions. So it is dozens of times faster than refrast and beats hardware in flexibility. For one, it is no problem to go beyond the 32 texture instructions limit in ps 2.0 hardware, while still keeping things real-time.

You can read the details here: http://www.flipcode.com/cgi-bin/msg.cgi?showThread=COTD-swShader&forum=cotd&id=-1.

 

[PC-Engine]

How fast would your software run on a cpu that has 128 SIMD units relatively speaking?

 

[demalion]

Tsk, tsk, you naughty sensationalist!

 

[Crusher]

Got a demo we can download? I can't get the swShader project to compile in VC++ 6.0 in Win2k, and I don't see any demo executables in the zip file.

 

[gokickrocks]

once you compile it (i used vc++ .net), you can run the demo...

also, for those that cant get it to work, try whats mentioned below...

I forgot to mention in the Readme that you need the Processor Pack and Service Pack 5 for compiling with Visual C++ 6.0: http://msdn.microsoft.com/vstudio/downloads/tools/ppack/download.aspx

 

[Nick]

How fast would your software run on a cpu that has 128 SIMD units relatively speaking?

Relatively... 128 times faster?

 

[Nick]

Tsk, tsk, you naughty sensationalist!

I know, I know, but else if I put "sofware rendering" in the title absolutely nobody here is interested

 

[Nick]

Got a demo we can download? I can't get the swShader project to compile in VC++ 6.0 in Win2k, and I don't see any demo executables in the zip file.

This is an alpha version for developers only, people who know this is more than just a spinning teapot. It should compile and run correctly once you've installed the Processor Pack.

 

[PC-Engine]

How fast would your software run on a cpu that has 128 SIMD units relatively speaking?

Relatively... 128 times faster?

That's really fast! Let's say I get 10 fps now, does that mean I'll be getting 1280 fps with that cpu?

 

[Nick]

That's really fast! Let's say I get 10 fps now, does that mean I'll be getting 1280 fps with that cpu?

There are some other limitations like memory bandwidth, but this can be reduced by things like tile based rendering. If you can give me such a system I'll try it out for you

 

[Saem]

How adaptable is this to other architectures? I haven't had a chance to look at the code, but are things seperated off into math libraries, where one would just have to change their implementation and that would be about it?

 

[PC-Engine]

That's really fast! Let's say I get 10 fps now, does that mean I'll be getting 1280 fps with that cpu?

There are some other limitations like memory bandwidth, but this can be reduced by things like tile based rendering. If you can give me such a system I'll try it out for you

You would have to sign an NDA 8)

 

[darkblu]

I know, I know, but else if I put "sofware rendering" in the title absolutely nobody here is interested

*oops, blu realizes he didn't quite express his view on Nick's project the first time around*

congrats, Nick, for being the first person to implement this really great concept (i.e. JIT assembler as shaders)!
*blu virtually shakes Nick's hand*

to be able to come up with arbitrary shading techniques is one of the main reasons people come up with software rasterizers, and Nick has taken this idea to its appogee by making possible for vitually-unlimited shaders. my own rasterizer was partially aimed at this too, but it missed the consept of 'shaders', so implementing arbitrary shading techniques was way more cumbersome.

as a matter of fact, i think what Nick has produced will have quite an impact on the future development of 3d rasterizer trechnologies. again, kudos to him for being the one to actually step into the next level in rasterizers' tech!

 

[Nick]

How adaptable is this to other architectures? I haven't had a chance to look at the code, but are things seperated off into math libraries, where one would just have to change their implementation and that would be about it?

Currently it is targeted at x86 only and requires MMX/SSE. Just like any other JIT compiler, you'll have to re-write the code generator (SoftWire/Synthesizer) and translate ps 2.0 instructions into assembly code for your architecture (Shader/PS20Assembler). Since I only own a Celeron 1200 it's impossible for me to try this, but it's certainly possible and most architectures are simpler than x86...

 

[Saem]

Thanks for the info, Nick. That's some really cool stuff.

I wonder what implications this might have if ported over to the PS2?

 

[Nick]

Since it appears to be stable I have added an executable to the package in case you do not have Visual Studio: http://sw-shader.sourceforge.net. If you do have it I would appreciate it if you tried compiling it and reported any problems.

 

[RussSchultz]

Thanks for the info, Nick. That's some really cool stuff.

I wonder what implications this might have if ported over to the PS2?

PS2 might have some code limitations for the JIT compiler (I would think, anyways) since it is an embedded system with limited memory. Maybe not, though. (I'm just talking out of my arse and theorizing here).

 

[Nick]

PS2 might have some code limitations for the JIT compiler (I would think, anyways) since it is an embedded system with limited memory. Maybe not, though. (I'm just talking out of my arse and theorizing here).

I just tested a shader with 32 texture operations and 64 arithmetic operations. It's nearly 10 kB big, and my current caching system can store 256 x86 shaders, so that would be 2.5 MB. This is the worst case, and I'm planning a peephole optimizer which will reduce this. So 1 MB in average should suffice.

 

[London Geezer]

i think PS2 would lack blending modes to support anything that even compares to PS2.0..... but u never know, i might be wrong.... oh and let's not talk about performance.....

 

[Reznor007]

i think PS2 would lack blending modes to support anything that even compares to PS2.0..... but u never know, i might be wrong.... oh and let's not talk about performance.....

If it's in software, does it's video hardware matter at all?