Irrlicht Engine

Perhaps you missed my edit? It's all recent Nvidia cards.

Max texture count should be more flexible than simple '#define'. Anyway we can provide clamp to max fixed pipeline textures count when fixed pipeline is usage and clamp to max programmable pipeline textures count (texture image units) when shader is active.

Is there any harm in just making it 8? It's not as if the engine will assign to all the slots - the user has to do this. If they set 6 textures when only 4 are supported it would be their problem, yes?

As you say, there isn't technical problem to set max texture units to eg. 64 (it will cause just small memory lose, but it's not a problem in my opinion). Driver should detect how many texture slots are available for GPU and bind textures just to available slots. Without flexible (real-time) max texture count modificator, we should define 32 or 16 available textures. This modification is really easy and I hope that in v1.9 it will be available.

As I think the problem is not memory but speed I did a quick (and bad) test with an artificial test-scene. And as I feared it got slower just by increasing the define to 8. I can maybe do a better test with real scenes soon. This also means that there can be optimizations for scenes which use less than 4 textures.

As usual the engine should try to avoid breaking every application using Irrlicht. So rewriting it completely to control texture-layer access just for this is a bad. Just increasing to 8 is obviously also bad when it costs too much speed.

One option might be to have an additional bitset (or bool-array?) to disable texture layers. Or having a bool itself in the layer to disable it (nicer code, worse caching). Then comparisons could check for that flag first which would probably be faster already (though it means some more checks when all textures are used). Or if write access to that flag is controlled then it would also be possible to calculate valid ranges for layer-indices when the flag is set.

But that's all theoretical - no one should touch this without having real profiling data with some good tests for real scenes. And I haven't so far.

With properly implemented clamp system for binding active textures there will be no any perf drop. In current code we have some places which may be improved eg. 'COpenGLDriver::setTransform' where we apply texture matrix to all available slots, so with MATERIAL_MAX_TEXTURES = 4 we do only 4 steps, but with MATERIAL_MAX_TEXTURES = 64 it will be 64 steps. When we fix it everythink will works fine.

Flexible max texture count modificator will be nice, anyway in our situation as you said this isn't good idea from application compatibility POV, '#define' isn't flexible thats why we should set bigger value eg. 32. It'll cost just some more memory space.

The performance hit isn't about binding textures. I did not use any texture - just a larger define. All textures still set to 0. Like mentioned above my guess (without having profiled in more detail ... so can be completely wrong) is that it's the comparisons for checking if the renderstate has changed which get more expensive. All elements in the texture-layer are compared no matter if the layer is used or not. Which is necessary for now as the layer values can be used even if no texture is set.

My example above perfectly shows this case. Even if any texture isn't bind we perform operations related to texture matrices. What about render state changes? Current Irrlicht system (BridgeCalls between irr and ogl calls) improves performance a lot in that cases. Anyway we can improve current system to skip change states for unbinded texture slots (at now it's few 'if' calls).

Yeah, just a few comparisons, so rather surprising it matters. But my test had several thousand nodes and the comparisons are done for every node and every meshbuffer on each render-call, so I guess that's why it's getting more expensive.

It may be a reason, hovewer your test case will be useful when we'll optimize methods which I mentioned in my above posts If we'll implement 'clamp system' it properly we shouldn't notice perf drop. I can do that after I finish my current tasks.

Great to see progress here, thanks
On texture matrices uploading: that feature being rarely used (but we use it indeed, for animating textures), I think you should not upload it when the matrix is identity. Ideally I think you should detect when the matrix changed and just upload in that case...