webgl renderer has gotten very slow?

[mrdoob]

webgl renderer has gotten very slow?

[mrdoob]

Is that with the master branch or the materials branch? (We started a materials branch recently because we had some refactoring to do with materials)

[tbuser]

I've only been using the master branch. I think I tracked it down to this commit that added multiple light support to webgl: 1c35d90 Even if I comment out all the lights, it still crawls for me. The commit right before that is super fast.

[mrdoob]

Didn't notice any slow downs on my setup. What graphics card do you have? Have you tried on another machine?

[tbuser]

I just tried it on my iMac at work, same significant slow down. For instance the example at: http://mrdoob.github.com/three.js/examples/geometry_large_mesh.html gives:

canvas ~30 fps
webgl ~1 fps

OS X 10.6.4
2.8 GHz Core 2 Duo
4 GB ram
ATI Radeon HD 2600 Pro
Chrome 9.0.572.1 dev

[tbuser]

I just tried Minefield 4.0b8pre and it is getting the same bad performance on webgl.

[mrdoob]

That's impossible... Maybe you're getting confused with the color of the selected option. Yellow means selected (I've seen other people get confused with this too, I'll fix). I can't believe that the canvas renderer is rendering 100k polys at 30fps ;)

[tbuser]

haha I think you're right, sorry. I can't get that example to be more than 1 fps here at home using either webgl or canvas, so I setup my own test as an example:

OS X 10.6.4
2 GHz core duo
2 GB ram
ATI Radeon X1600

Minefield 4.0b8pre

http://replimat.com/thingiview/examples/
old three.js webgl - 100 fps

http://replimat.com/new_thingiview/examples/
new three.js webgl - 30 fps

The only difference between those 2 urls is the version of three.js.

[tbuser]

Oh and using regular Chrome at either url using canvas - 60fps, twice as fast as Minefield using webgl on the new version.

[mrdoob]

What's weird is that none of them work in Chrome here :/

However:

Ubuntu 10.10
2.53 GHz Core 2 Duo
4 GB ram
Nvidia GeForce 9400M

Firefox 4.0beta7

Both of them run at 100fps, until I interact, then it goes down to 60fps.

I'll ping alteredq, to see if he knows what's going on.

[tbuser]

Yeah, I'm not sure why Chrome stopped working with webgl in either version, it works with canvas and used to work with webgl. I'm not sure if it's a bug or something I'm doing yet, but I think it started failing after I added my own web worker loader.

[alteredq]

So, I tried it on my setup:

Windows 7 64bit
2.4 GHz Core2 Duo
4 GB RAM
ATI Mobility Radeon 3650

And it runs like this:

Both old and new version do not show anything in Chrome (latest dev channel 9.0.576.0 and canary 9.0.583.0).

In Firefox 4 beta 7 they both run at more or less the same speed, e.g WaltHead low poly is about 110-120 FPS when autorotating and ~63FPS after interaction.

Given your description of when this slowdown started to appear and your system specifications I suspect what what could be going on:

A) for your particular system configuration (GPU + OS) new shader got too complex and it somehow started to trigger software rendering (on the level below WebGLRenderer like browser/OS/GPU driver).

Though this is unlikely, you probably wouldn't be getting even 30 fps with SW rendering (unless the numbers you mention are for some simple scene, like default cube. For which object are your 30/60fps numbers in WebGL/Canvas?)

Also I know nothing about OSX rendering backend, can it use SW rendering for OpenGL? I think at some point in WebGL history some browsers used Mesa SW renderer as fallback, that's why I thought this could be going on.

B) new version of shader rubs your GPU driver in some bad way which results in slowdown. Did you try to update your GPU drivers?

I used to have horrible problems on my system when I used old drivers (latest one given officially by notebook manufacturer Lenovo, while the latest one from GPU manufacturer ATI have been working flawlessly).

Welcome to the hell of HW acceleration on multiple OSs / GPUs :S

[alteredq]

One more thing I realized when going through my multi-lights commit which triggered this slowdown: how did you comment out the lights? Were the for loops in shaders still in place?

This is somehow contentious area as for multilights I use uniforms as loop boundaries. This is supposed to be supported in GPUs only since some time (which was already pretty long ago, but both your GPUs are pretty old).

I may anyways have to change the implementation as it seems this feature will eventually be prevented at shader validation phase:

http://code.google.com/p/angleproject/issues/detail?id=48

[tbuser]

After doing more testing on multiple other machines (both Macs and PCs), it seems as though the only one having this problem is my old MacBookPro with an ATI Radeon HD 2600 Pro (which unfortunately happens to be what I do most of my development on at home).

So far as I know, the only way to get Mac video drivers is through Software Update, which means I have the latest drivers.

I had commented out the code that added lights to the scene thinking the multiple lights I had was causing the problem, I didn't change anything in three.js itself.

So I'm guessing this is just an issue with that particular GPU.

[alteredq]

Thanks for the report and tests. With so many possible combinations of HW and SW you never know what effects you will get.

I'll eventually refactor WebGLRenderer to use only fixed size loops for multiple lights, but it may take a while and it will probably go just in materials branch.

If you commented out lights in the scene, shader will be compiled to handle default of 1 directional + 4 point lights (which will be empty, but code may be executed anyways). It may be better to use e.g. just one directional light instead of zero lights.

About drivers: ATI historically used to have worse OpenGL drivers than NVidia (while for DirectX situation was reversed). You had to pay extra for FireGL versions of their cards to get decent OpenGL performance.

I don't know how is situation for Macs, but for Windows notebooks, there is usually huge delay between officially sanctioned drivers by notebook manufacturers and drivers by GPU creators (in my case it's more than 1 year and difference was big - many things were broken or crashing with obsolete drivers).