Hi all, I'm proud to present you SwiftShader 2.0. Please download the demo and give it a try with every DirectX 9 game you've got. [cool] Feel free to share your thoughts! Nicolas

Quote:Original post by Tom
I would definitely check out the demo if I didn't have to give you a bunch of personal information.

Thanks for bringing that up as an issue. We'll be looking at how to make the registration process less of an obstacle (likely we'll add at least a privacy statement).

If anyone has already tried the demo with a few games I'd love to hear about your experience!

Here's a few suggestions of applications you might want to give a try (a selection of my personal favorites). I've included links to the download pages for your convenience:
- 3DMark03, 3DMark05, and 3DMark06
- Half-Life 2
- TrackMania Nations
- ATI Demos (in particular the 9700, 9800 and X800 ones)
- RenderMonkey
- OGRE Demos

Hi Nicolas,

Good to hear you've continued improving this product. Although I appreciate your effords, it seems that it isn't particulary usable for any modern directx9 application;

System specs:
2.4Ghz Intel core2duo
4GB 667Mhz memory
ran everything at a resolution of 1,024x768

The ATI demos which run with 1 - 10 fps

I also tried running Call of duty 4 with lowest detail settings, but it was unplayable at 1- 2 fps.


3dmark 2003 results:

3DMark Score 370 3DMarks
CPU Score 170 CPUMarks
3DMark Score - 370.0 3DMarks

Game Tests
GT1 - Wings of Fury 9.55 FPS
GT2 - Battle of Proxycon 3.13 FPS
GT3 - Troll's Lair 2.3 FPS
GT4 - Mother Nature 2.04 FPS
CPU Score - 170.0 CPUMarks

CPU Tests
CPU Test 1 16.65 FPS
CPU Test 2 3.43 FPS

Feature Tests
Fill Rate (Single-Texturing) 78.42 MTexels/s
Fill Rate (Multi-Texturing) 110.01 MTexels/s
Vertex Shader 2.14 FPS
Pixel Shader 2.0 6.5 FPS
Ragtroll 2.02 FPS

The performance seems to be about the same as with the last release of SwiftShader (which ran PS2.0 demos with the same performance on a much slower cpu)... It seems to be limited by memory latency/bandwidth?

Any ways, keep up the good work!

Martijn

Hi Martijn,

Thanks for testing!

Please note that SwiftShader 2.0 is not actually aimed at running these recent games, but instead at running casual games and other desktop applications that need a reliable Direct3D 9 fallback. Running advanced games like Call of Duty 4 is just meant to prove that full Shader Model 2.0 level support is provided. Hence, casual game developers can now use Shader Model 2.0 as a minimum requirement, plus they save on QA and support.

Quote:The performance seems to be about the same as with the last release of SwiftShader (which ran PS2.0 demos with the same performance on a much slower cpu)... It seems to be limited by memory latency/bandwidth?

Are you sure that was at the same resolution and quality?

Running the DolphinVS DX8 sample that came with the SwiftShader 1.0 release I'm getting 70 FPS at best. The same sample in the SwiftShader 2.0 release package reaches 155 FPS for a single thread, while also using bilinear filtering instead of point filtering, accurate mipmapping instead of per-polygon, and higher presicion perspective correction!

It's possible that bandwidth limitations stop it from reaching even higher performance, and some applications will be more sensitive for that than other, but I'm fairly confident that SwiftShader 2.0 is a significant step forward in both features and performance.

Quote:Any ways, keep up the good work!

Thanks!

Hi Nicolas,

You're right, I looked up your old demo and compared it with the new one:

Demo        old fps   new fpsDolphin     60-70     220-230EffectEdit  130-140   190-200CubeMap     60-65     70-80

At transgaming they mention you use dynamic recompilation as a technique. Do you use LLVM as an underlying framework for that?

The advantage of a software renderer is ofcourse its flexibility. On current cpu's it's only practical for simple applications/games like you mentioned, but with new technologies comming up, like Intel's labberree it might become an obvious choice to do (some parts) using software rendering again. Would ShiftShader be able to take advantage of such architecture (offloading to different backends)?

Quote:Original post by bitshit
At transgaming they mention you use dynamic recompilation as a technique. Do you use LLVM as an underlying framework for that?

No, SwiftShader uses SwiftAsm, which is an advanced version of my SoftWire run-time code generator. LLVM targets mostly 'traditional' code generation, while SwiftShader requires access to all the advanced x86 instruction extensions.

Quote:The advantage of a software renderer is ofcourse its flexibility. On current cpu's it's only practical for simple applications/games like you mentioned, but with new technologies comming up, like Intel's labberree it might become an obvious choice to do (some parts) using software rendering again. Would ShiftShader be able to take advantage of such architecture (offloading to different backends)?

I don't know if Larrabee is going to allow running application code. But I'm definitely looking forward to new CPU architectures and supporting their new instruction set extensions. There might also be some opportunity for (embedded) systems with non-x86 CPUs. Writing new backends wouldn't be too much of a problem.

Quote:Original post by C0D1F1ED

Quote:Original post by bitshit
At transgaming they mention you use dynamic recompilation as a technique. Do you use LLVM as an underlying framework for that?

No, SwiftShader uses SwiftAsm, which is an advanced version of my SoftWire run-time code generator. LLVM targets mostly 'traditional' code generation, while SwiftShader requires access to all the advanced x86 instruction extensions.

I thought LLVM is used exactly for such specialized purposes? See for example:
http://zrusin.blogspot.com/2007/09/today-were-going-to-talk-about-shaders.html
http://llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf

How would SwiftAsm exactly differ from LLVM targetted at using SSE etc?
(http://llvm.cs.uiuc.edu/pubs/2006-06-15-VEE-VectorLLVA.pdf)

Quote:Original post by C0D1F1ED

Quote:Original post by bitshitThe advantage of a software renderer is ofcourse its flexibility. On current cpu's it's only practical for simple applications/games like you mentioned, but with new technologies comming up, like Intel's labberree it might become an obvious choice to do (some parts) using software rendering again. Would ShiftShader be able to take advantage of such architecture (offloading to different backends)?

I don't know if Larrabee is going to allow running application code. But I'm definitely looking forward to new CPU architectures and supporting their new instruction set extensions. There might also be some opportunity for (embedded) systems with non-x86 CPUs. Writing new backends wouldn't be too much of a problem.

I understand memory latencies & bandwidth are the main bottleneck for software rendering nowadays, which haven't seem to be improved as much over time like cpu speed and features. Do you know if there are plans to change this in the forseeable future (like with Intel's Sandy Bridge)?

Anyways, time for you to write some new tutorials on devmaster, revealing some of those state-of-the-art rasterization tricks! ;)

Quote:Original post by bitshit
I thought LLVM is used exactly for such specialized purposes? See for example:
http://zrusin.blogspot.com/2007/09/today-were-going-to-talk-about-shaders.html
http://llvm.org/devmtg/2007-05/10-Lattner-OpenGL.pdf

How would SwiftAsm exactly differ from LLVM targetted at using SSE etc?
(http://llvm.cs.uiuc.edu/pubs/2006-06-15-VEE-VectorLLVA.pdf)

Sure, LLVM can be used to generate SIMD code. But it still can't compete with hand-tuned SSE code sequences. SwiftAsm allows access to each and every x86 instruction, while also offering register allocation functionality, optimizations, and other abstractions that make it easier than writing plain assembly code. LLVM is primarily intended as a GCC backend, while SwiftAsm is fully tailored for the needs of SwiftShader (and potentially other performance-critical applications).

Quote:I understand memory latencies & bandwidth are the main bottleneck for software rendering nowadays, which haven't seem to be improved as much over time like cpu speed and features. Do you know if there are plans to change this in the forseeable future (like with Intel's Sandy Bridge)?

As far as I know memory latency and bandwidth are not the main bottlenecks. It's still all relatively low resolution and low framerate, so it doesn't need the massive bandwidth of modern graphics cards. Caches, automatic prefetching and out-of-order execution also allow a lot of latency tolerance. SwiftShader's performance scales quite well with increased clock frequency and extra cores, meaning increases in computational power have a major influence (while bandwidth and latency are almost the same). If you get the chance, try underclocking your RAM and see whether SwiftShader's performance decreases linearly.

Anyway, as performance increases I do expect the bandwidth and latency to become a bottleneck if they're not improved. But architectures like Nehalem and Sandy Bridge promise significant advancements so I'm really not worried.

Quote:Anyways, time for you to write some new tutorials on devmaster, revealing some of those state-of-the-art rasterization tricks! ;)

I obviously can't reveal intellectual property, but I promise I'll keep contributing to the community whenever possible!

The SwiftShader 2.01 update is now available for everyone from the website. It improves performance on AMD processors, and includes several fixes for rendering issues.