Software renderer beating Radeon/GeForce

Nick

Veteran
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.
 
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.
 
Crusher said:
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 said:
:LOL: :oops: 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 ;)
 
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?
 
Nick said:
PC-Engine said:
:LOL: :oops: 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)
 
Nick said:
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!
 
Saem said:
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...
 
Thanks for the info, Nick. That's some really cool stuff.

I wonder what implications this might have if ported over to the PS2?
 
Saem said:
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).
 
RussSchultz said:
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.
 
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.....
 
london-boy said:
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? ;)
 
Back
Top