[Deprecated feature] IVideoDriver + Texture Matrices

[CuteAlien]

I still hope you try (aka measure!) first if it is worth breaking the interface for that. Will removing a matrix-copy really make a noticable difference in speed? As Hendu said - there are users of this feature and this will break their applications. I can't tell if it's worth that without having any profiling numbers ... that's why I'm neutral.

[luthyr]

I still hope you try (aka measure!) first if it is worth breaking the interface for that. Will removing a matrix-copy really make a noticable difference in speed? As Hendu said - there are users of this feature and this will break their applications. I can't tell if it's worth that without having any profiling numbers ... that's why I'm neutral.

It made a measurable difference removing it when we optimized for PS4, though I don't have the numbers anymore. I'm not sure it is just the copy, but the allocation/deallocation as well. We had previously added vectors for Scale/Translation/Rotation to the material that were used in the shader instead of a matrix, so we didn't need it.

[Nadro]

Fixed size of ETS_TEXTURE_n is the most problematic, because in near future we'll need 32 enums just for textures (we can use ETS_TEXTURE+n solution, but we should remove ETS_TEXTURE_0-ETS_TEXTURE_7). IMO opinion this interface was designed for fixed pipeline, when only 4-8 texture units was available.

For IVideoDriver::getTexture we can apply a workaround and mark this feature as deprecated:

Code: Select all

driver->getCurrentMaterial().TextureLayer[x].getTextureMatrix()

We can't apply similar workaround for IVideoDriver::setTransform workaround.

When we'll solve issue with low value of _IRR_MATERIAL_MAX_TEXTURES_ we'll have folowing penalty:
[small scene with 30 nodes per screen, each node has just one meshbuffer/material, our gpu support up to 32 texture image units]
30*32 unnecessary calls of matrix copy per frame, maybe it's not a big value, but this scene isn't big.

[bigger scene with 100 nodes per screen, each node has two meshbuffers/materials, our gpu support up to 64 texture image units]
100*2*64 unnecessary calls...

For more advanced scenes we'll have a more wasted calls. On hi perf CPU it's ok, but on low end CPU (like in PS4) it may decrease performance.

[hendu]

You're referring to setMaterial setting each texture matrix, correct?

How about a new API to say it's not needed? IVideoDriver::ignoreTextureMatrices(bool), allowing compat with old API, but no speed penalty for apps that don't need them.

[CuteAlien]

Calls can mean something sometimes, but then again you can call something 500 times and it will be as fast as 2 calls in another place which blows the cache. I'm not saying that is the case here, probably rather the opposite, but it's an example why this doesn't tell enough. There is one golden rule of optimization - start by measuring times. Unless you use a profiler and reproducible test-scenes you will optimize the wrong stuff (still happens even with testing - but then at least you know it).

And yeah, I get the urge to optimize everything. But it often has disadvantages. Breaking API's being on of the worst for libraries. But sometimes there are also costs in complicating the architecture and/or code readability which means the next guy working on it will no longer be able to maintain the code (see software renderers - those have both been highly optimized with lot's of micro-optimizations like ceil32, but by now those functions are just causing bugs and no-one finds the time to clean it all up).

[Nadro]

@hendu
Yes, I'm referring to setMaterial. I think that " IVideoDriver::ignoreTextureMatrices(bool)" is good solution, I think that we may even prepare somethink like a setTextureCreationFlag just for rendering pipeline eg. setRenderingPipelineFlag, because I think that it may be usefull in future.

@CuteAlien
I understand your statement. I'll try to profile my projects and prepare some report in this case, however it may be not require if we'll apply hendu's solution.