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

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

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.


>  -- Steve

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