Submitting patches

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Submitting patches

Post by hendu »

Perhaps you missed my edit? It's all recent Nvidia cards.
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Submitting patches

Post by Nadro »

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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
mongoose7
Posts: 1227
Joined: Wed Apr 06, 2011 12:13 pm

Re: Submitting patches

Post by mongoose7 »

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?
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Submitting patches

Post by Nadro »

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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Submitting patches

Post by CuteAlien »

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.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Submitting patches

Post by Nadro »

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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Submitting patches

Post by CuteAlien »

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.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Submitting patches

Post by Nadro »

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).
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Submitting patches

Post by CuteAlien »

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.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Submitting patches

Post by Nadro »

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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Funto
Posts: 17
Joined: Tue Feb 21, 2006 2:29 am

Re: Submitting patches

Post by Funto »

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...
Post Reply