[Public WebGL] Re: webgl/swiftshader

Liam Wilson [email protected]
Sun Feb 19 07:32:33 PST 2012


I think "software rendering is slow" is a bit of a self fulfilling prophecy. No one thinks it can be fast, so no one bothers to write a fast software renderer. So we then wind up drawing comparisons between unoptimised CPU renderers, and highly optimised GPUrenderers. Which then makes the performance gap look far worse than it actually is.

Liam
PS sorry about the top post, yahoo webmail now completely sucks at plain text email quoting.

PPS According to http://transgaming.com/business/swiftshader/technology/ Swiftshader is not just x86


________________________________
 From: Florian Bösch <[email protected]>
To: Patrick Baggett <[email protected]> 
Cc: [email protected]; Mark Callow <[email protected]>; public webgl <[email protected]> 
Sent: Wednesday, 15 February 2012, 20:16
Subject: Re: [Public WebGL] Re: webgl/swiftshader
 


On Wed, Feb 15, 2012 at 7:57 PM, Patrick Baggett<[email protected]> wrote:

I wouldn't say 100% of Win8 platforms will be WebGL capable, but honestly, if a > 3.0 GHz x86-64 machine stutters while using Mesa's LLVMshaderbackend (swiftshader is x86 only, and cannot be ported since it glues x86 asm together), then I imagine a 600MHz - 1GHz ARM chip running with power constraints would scarcely be able to render anything "interactively". When it comes to shaders on embedded hardware, it is basically GPU or die trying.
Well it's true that more complex usages would be all but hog-slow on CPUs. But if all you need is to draw a couple hundred triangles and some simple lighting, software rendering is a good alternative, say as opposed to missusing canvas2d to do 3d or rasterizing in pure javascript. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120219/df2f6bd6/attachment.html>


More information about the public_webgl mailing list