Sort solids primarily by type, secondarily by texture

For r4232

Hm, I write mostly old style apps and think I rarely can use EMT_SOLID (the other material-types are way more important if you _don't_ use shaders). But anyway - I don't think this would hurt much as last time I tried optimizing anything by changing that sorting I simply didn't get measurable improvements. But there is also something more important than speed - which is correctness. I still have some problems with the transparent sorting on my todo, although I'm not yet certain if those are fixable at all with just node-based sorting (might need polygon-based sorting). But maybe there is some chance to allow custom sorting? We wanted to add that to array::sort anyway (I have even a patch for that although I'd have to go over it once more probably). Not certain if it makes sense here - but would be more interesting than optimizing for another special-case (if it's possible to add custom-sorting without accidentally losing speed - might be time to add my profiler patch first.. .which also needs some time to go over it once more).

Well - just my ideas, I won't complain if this gets added as a quick workaround, although I would prefer to see some profile information for patches about speed. I've experienced just too often that profile results didn't agree with seemingly obvious optimizations - and any change is foremost something that potentially breaks an application out there.

I think the chance this patch breaks anything is very small. After all, the draw order does not matter for solids due to the depth buffer.

I agree with Hendu that we should update sorting for SOLID materials. Of course customizable sorting method is the best idea, however for default behaviour MaterialType should exist before Textures.

I just gave it another try (as I'm currently optimizing a game) - but again couldn't find any improvement with this code. If any change then it got slightly worse (but within a difference that might have been random).
As this is about reducing state-changes I tried then another solution where I copied the whole material and did:

bool operator < (const DefaultNodeEntry& other) const
{
if (Material.MaterialType != other.Material.MaterialType)
return (Material.MaterialType < other.Material.MaterialType);

if (Material.AmbientColor != other.Material.AmbientColor)
    return Material.AmbientColor < other.Material.AmbientColor;
if (Material.DiffuseColor != other.Material.DiffuseColor)
    return Material.DiffuseColor < other.Material.DiffuseColor;
if (Material.EmissiveColor != other.Material.EmissiveColor)
    return Material.EmissiveColor < other.Material.EmissiveColor;
if (Material.SpecularColor != other.Material.SpecularColor)
    return Material.SpecularColor < other.Material.SpecularColor;
if (Material.Shininess != other.Material.Shininess)
    return Material.Shininess < other.Material.Shininess;

return (TextureValue < other.TextureValue);

}

But again made no measurable difference (got again slightly slower but within random margin).

Test was with my racer in a real scene (4 different shaders and ~25000 polygons).

So the question here is - did you measure a speed improvement in a real scene with this change? Or is this more the kind of - it should get faster in theory...

I mean I even agree that it should get faster in theory and expected that. But so far the only measurable result I got was that it got slightly slower with this patch. So please don't apply without profiling and finding at least one scene where it actually improves the speed.

You need more than 4 materials for gain performance boost, eg. slow CPU (you can lower frequency), 30+ mesh buffers and 10+ materials should be enough to show a differences. You can check this slides (slide 18-21):
http://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead
We want to move from aproach from a slide no. 18 to approach from a slide no 19. In the next slides you can find perf results etc.

Compare light colors is useless. You can check perf in your game when you will do something like that:
bool operator < (const DefaultNodeEntry& other) const
{
if (Material.MaterialType != other.Material.MaterialType)
return (Material.MaterialType < other.Material.MaterialType);

if (Material.BlendFactor != other.Material.BlendFactor)
return Material.BlendFactor < other.Material.BlendFactor;

if (Material.BlendOperation != other.Material.BlendOperation)
    return Material.BlendOperation < other.Material.BlendOperation;

if (Material.ZBuffer != other.Material.ZBuffer)
return Material.ZBuffer < other.Material.ZBuffer;

return (TextureValue < other.TextureValue);

}

However for the best performance we should allow users to use custom method for sorting, because this process is very much depend on a game.

I got many more different SMaterial's - just only 4 material-types using them. The comparisons I added had been those which are different in my game (I don't work with different blend operations for the same material-type, same for ZBuffer settings).

I don't say this is wrong in theory - I had rather expected it to get a little faster. The problem is that I did not get a measurable difference (except maybe a slight loss of speed). And profile results are the only thing that matters in optimization. So maybe there's a reason why it doesn't get faster which isn't obvious (there often is) - or the scene was not representative enough (always hard to tell). All I'm asking is - show that it actually improves things before this is applied - otherwise it's pointless.

If you only had four types, did you check if the sort order made a difference? Ie, did you have something that shares a texture, but has different shader?
It's about cpu overhead and the number of nodes causing expensive state switches; the polycount is irrelevant.

I definitely saw less cpu overhead and less state switches in apitrace. The scene had around 20 shaders and a lot of nodes.

Changing the light params is not heavy at all as Nadro said.

If you tested and measured it then I'm fine with it anyway. I just don't like theoretical improvements which are un-tested and it wasn't clear to me so far if anyone actually had gotten any measurable improvements out of this. Helps when patches come with tests ;-)