SwiftShader

SwiftShader is more than 50 times faster than Microsoft's reference rasterizer.

That sounds useful, so long as the results are identical.

Otoh:

SwiftShader has support for Vertex Shaders up to 1.1 and most Pixel Shaders instructions up to 1.4. Both Pixel and Vertex Shader 2.0-level support are under development, and a limited set of 2.0-level Vertex Shader instructions are already available. SwiftShader will also support stencil buffers in a future release.
 
Last edited by a moderator:
geo said:
That sounds useful, so long as the results are identical.
You mean as a complete replacement or just good enough conformance to run many applications correctly, on systems lacking certain hardware support?
 
Actually, I was thinking for quality checking purposes, but after the looking at the site some more I think I oringally seriously misjudged what the purpose of the product is.
 
davepermen said:
wohoow.. softwire at work, right? :D
Yes. The successor of SoftWire to be correct. It allows to generate close to optimal code with powerful and convenient C++ constructs. And there are already ideas for the next generation. :D
 
geo said:
Actually, I was thinking for quality checking purposes, but after the looking at the site some more I think I oringally seriously misjudged what the purpose of the product is.
Our primary purpose is to offer DirectX 8 emulation (shaders in particular) for low-end systems that don't support these features. For example my Dell Inspiron 500m laptop has an Intel integrated graphics chip that doesn't support pixel shaders at all. But several applications using simple pixels shader do run relatively fast on the Pentium M processor with SwiftShader (anything is better than nothing at all).

I do strive for high conformance with the reference rasterizer, but that's more of a requirement to render things correctly then a goal on its own. At least for the moment... If there's great interest in it we could focus on correctness. But since Microsoft decides what's the reference I'm not sure if we can ever provide an acceptable replacement.
 
Nick said:
Yes. The successor of SoftWire to be correct. It allows to generate close to optimal code with powerful and convenient C++ constructs. And there are already ideas for the next generation. :D

Hehe, can't wait. but it's not open anymore, i guess? well.. any new things you can share with us? any plans for dx9 soon, or other stuff first? because having it emulating dx9 would be great, as for my app, it's a minimum requirement (and as it's a raytracer, it doesn't bother about speed that much), and, well.. we have quite some hw not having ps2.0 around..)

oh, and running both on cpu doesn't bother me as well. they run on different cpu's.. :D
 
davepermen said:
Hehe, can't wait. but it's not open anymore, i guess?
No, but for hobbyists SoftWire is still very nice. Professionals will want SwiftAsm for it's improved code generation and debugging support (SwiftShader was impossible without it). The next generation might also start as an open-source project and evolve into a commercial product once it matures.
well.. any new things you can share with us? any plans for dx9 soon, or other stuff first?
We'll first wait on the reactions on the current release. If (potential) customers desire DirectX 9 more than OpenGL support then that becomes our priority. But there are also ideas for better performance and letting the GPU do the non-shader work. So there's tons of things to do and try but I have no idea yet what will come first.
because having it emulating dx9 would be great, as for my app, it's a minimum requirement (and as it's a raytracer, it doesn't bother about speed that much), and, well.. we have quite some hw not having ps2.0 around..)

oh, and running both on cpu doesn't bother me as well. they run on different cpu's.. :D
So it's some kind of distributed rendering? That's pretty cool!
 
Nick said:
So it's some kind of distributed rendering? That's pretty cool!

*shhhhhh*

my final wish-setup would be several pc's, all with dualcore .. uhm.. athlons at best. or turions, to be less powerconsuming. and each of them with an array of x1800 radeons in, running gpu versions of my rendering code.. and then, my notebook, over WLAN connected, somewhere else in the room, with your Dx9 renderer, connected to those renderclients, doing raytracing work, distributed over them. realtime, and in HDR, with your dx9 part to do the tonemapping. that way i don't need to use a notebook with dx9 support anymore. i have 2 notebooks, only one has dx9 support.

opengl support would work as well.. all i need is fp1.0, or ps2.0 support. for the tonemapping.
 
When I saw the Slashdot story about this earlier I wondered if this was your software Nick. It's nice to see someone take the step from hobby to product.

daveperman, when I first learned about remote desktop in XP a few years back I thought it would be cool to do what you describe. Sometimes I wanted to run a shader from my laptop which was DX7 via my desktop. I was bummed to discover that remote desktop wasn't totally remote and looked at the graphics capabilities of my laptop to determine what could be run. There've even been a few times I wanted to run 3ds max over the network to quickly look at something and I had to resort to the software renderer.
 
3dcgi said:
When I saw the Slashdot story about this earlier I wondered if this was your software Nick. It's nice to see someone take the step from hobby to product.

daveperman, when I first learned about remote desktop in XP a few years back I thought it would be cool to do what you describe. Sometimes I wanted to run a shader from my laptop which was DX7 via my desktop. I was bummed to discover that remote desktop wasn't totally remote and looked at the graphics capabilities of my laptop to determine what could be run. There've even been a few times I wanted to run 3ds max over the network to quickly look at something and I had to resort to the software renderer.

uhm.. i'm not working with remotedesktop or anything similar. i'm working on a raytracer that does distributed rendering over the network, similar to the work of www.openrt.de

and if you want to do what you planned, use RealVNC. but it's too slow to transport full images. but theoretically, i could play games on another pc with this.
 
Congrats on selling your tech! Well deseved.

A question, though: Isn't it a bit asinine to purge the old SoureceForge projects? With the license you previously used is not as if you can 'put the cat back in the bag', so to speak. Anyone could just upload them again, so what's the point?
 
Zaphod said:
Congrats on selling your tech! Well deseved.
Thanks!
A question, though: Isn't it a bit asinine to purge the old SoureceForge projects? With the license you previously used is not as if you can 'put the cat back in the bag', so to speak. Anyone could just upload them again, so what's the point?
We had to break with the SourceForge projects to prevent it from influencing the TransGaming products. Sure people can place the source code in a new project with the same license, but what's the point other than offering a backup? The SourceForge projects died about a year ago and nobody seemed to care. I never got any significant contributions even when they were under very active development. Taking things commercial was a natural evolution and the only way forward for this technology.
 
davepermen said:
uhm.. i'm not working with remotedesktop or anything similar. i'm working on a raytracer that does distributed rendering over the network, similar to the work of www.openrt.de

and if you want to do what you planned, use RealVNC. but it's too slow to transport full images. but theoretically, i could play games on another pc with this.
I understood you weren't talking about remote desktop, but rendering over the network and using components not in the terminal computer reminded me of that. I never did try VNC with my experiments, but it's even slower than remote desktop which is also too slow for video.
 
Back
Top