[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] some samples and a question about looping




On Jan 6, 2011, at 2:42 PM, David Sheets wrote:

> 
> On Thu, Jan 6, 2011 at 1:32 PM,  <steve@sjbaker.org> wrote:
>>> If these GPUs are deployed in devices with sub-1GHz CPUs, I have a
>>> hard time believing that these devices will ever run WebGL content
>>> acceptably due to JavaScript's inherent inefficiency.
>> 
>> I have been surprised at how much you can do with a sluggish CPU and
>> JavaScript (using very ancient PC hardware and super-low-cost netbooks).
>> 
>> By pushing as much work as I can down into the GPU and up into the Server,
>> I've ended up with an engine that doesn't really need a whole lot of CPU
>> horsepower.   My biggest performance holes are generally in fill rate and
>> the time consumed by compositing operations when they aren't being done in
>> the GPU.   My hope is that on phone-based hardware, the small screen size
>> will generally compensate for GPU fillrate issues.
> 
> Without floating point output texture support, sustainably pushing
> game processing to the GPU is ludicrously cumbersome and unnecessarily
> brittle (JS is pure float, GPU is pure float, ES specs ints in and
> ints out with helpful clamping and NPOT (255!) division). The vast
> majority of our Javascript processing load is spent doing motion
> interpolation that could trivially be mapped to WebGL shaders given
> adequate feedback support. Javascript simply isn't efficient enough to
> perform large numbers of geometric computations at acceptable rates.
> These are the algorithms that get written in C and C++ in traditional
> desktop games. These are the inner loops that get concentrated
> profiling and cache-locality optimizations.
> 
> If CPU processing is doomed to the performance of a loosely-typed
> scripting language (even JITted and on multiple cores), we must be
> able to take advantage of the full capabilities of the GPU. Whether we
> like it or not, WebGL has the distinguished role as the first native
> code standard for the web. Forcing this native code to comply with
> archaic restrictions on shader capabilities is misguided and spoils
> our most valuable numeric resource. WebGL must be built for the
> future, not the past. Every concession that is made to support devices
> that will soon be obsolete and hampers full GPU utilization is another
> competitive loss to other, more liberal 3-D technologies.

Patience, grasshopper and all shall be revealed. In other words, this is just the first release of WebGL. There will be others, as well as extensions to move with you into the future.

-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------