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

Re: [Public WebGL] Shaders, glReadPixels and speed

On 1/3/2010 9:00 PM, stephen white wrote:
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.

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?

Are the calls that Gregg outlined above actually showing up as a bottleneck? If they are, that's a performance bug that I'm pretty sure we'll all be very motivated to fix; geometry shaders don't really replace much of that work, and emulating them in software and/or trying to do a bolt-on to GL ES seems like a bad way to fix these problems. As Ken mentioned, the best thing to do is to send along some benchmarks showing bottlenecks that we can jump on.

For Firefox, we're moving to hardware compositing for WebGL in the next month or so (hopefully next few weeks actually, depending on when some patches land), and I have some patches in the queue that should significantly speed up all WebGL calls and the WebGL array types. But again, any benchmarks/testcases showing problems would be very welcome.

    - Vlad

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: