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

Re: [Public WebGL] Shaders, glReadPixels and speed

On Jan 3, 2010, at 9:00 PM, stephen white wrote:

> On 04/01/2010, at 5:24 AM, Kenneth Russell wrote:
>> What browser and operating system are you using? Safari on Mac OS X
> Mac OS X 10.5, which probably lacks the hardware composition in the browser (despite being nightly). It is good to know that all browsers are moving towards hardware compositing to address this bottleneck.

The WebKit nightly does do hardware compositing. The problem is that you are reading back the pixels, which is slow in all GL implementations. Are you doing this because you need to use the image as a source for some other operation (like 2D rendering)? If there were some way you could avoid that read, your content would run much faster.

>> needed but the raw speed of sending down floating point numbers via
>> WebGLFloatArray is already pretty good.
> I was referring more to the step by step nature of needing to feed variables through, which leads to this kind of analysis:
> Gregg Tavares <g...@google.com> writes:
>>> 1 call to for each matrix you want to pass to the shader (usually 1 to 4 matrices)
>>> 1 call for each color parameter ( for phong the minimum would be 2, color
>>> and shininess though most phong shaders have 5, emissive, ambient, diffuse,
>>> specular, shininess)
>>> 1 call to setup position vertices
>>> 1 call to setup normals
>>> If it's textured you'll need another call to supply UVs
>>> 1 call to finally draw the object
>>> and then possibly a few calls to restore GL state.
>>> That a minimum of 5 calls and in this case a maximum of 13 per object, per
>>> frame. JavaScript is going to have a tough time doing that for more than a
>>> few objects and keep 60 or even 30hz.

I don't agree with this analysis. GLES is a very efficient API. 13 calls per primitive is an extremely small number. I have seen demos with at least a couple thousand calls per frame making over 50fps in WebKit. We should do everything possible to reduce that, so things like native matrix calls and geometry shaders are good suggestions for the future. Another big win I think is the use of uniform buffers, which is a proposed GL extension. This allows a set of uniforms to be sent down in one call. It would be pretty easy to emulate in software and still get the benefits of reducing the JS overhead.

> Rather than having a custom engine like O3D, it seems less controversial to add in a standard GL_ARB_geometry_shader4 so that WebGL is capable of displaying and animating 3d graphics to an equivalent level.
> The shaders have the vector and matrix functionality that is a painful library in Javascript, so is there a way of pushing the code across to that domain? Use a fragment shader and render vertex data to a texture?

We've discussed both a native matrix library and geometry shaders as future additions to WebGL. The first needs test cases to prove that matrix math and transfer is a bottleneck. The latter needs to wait for OpenGL ES to add them.


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