Finally, a DirectX 10 video driver for Irrlicht

[Granyte]

what do you mena by other vertex type?

[zerochen]

all types that the fixedfunctionrenderer use
eg
EVT_STANDARD
EVT_TANGENTS
EVT_2TCOORDS

[Nadro]

I applied a patch to branch. The last time a DX11 has been strongly improved

[Mel]

I am wondering, are you implementing any type of renderstate cache or the like?

[Nadro]

I think that like D3D9, D3D11 have built-in states cache, but I may be wrong. Maybe Zerochen or Granyte can tell you more in this case.

[Granyte]

After chequing nethier dx9 nor dx10 have render cache state

[Mel]

No, DX9 doesn't have a renderstate cache on its own. It has an interface for some sort of renderstate management system, but not strictly a built in cache. Nor DX11 i guess, so, currently, while the driver is being built and tuned, it would be a good idea to add it also a renderstate cache system.

[Granyte]

Yes we should but i have no idea how to implement this and becasue my system is not working i cannot cheq it

[zerochen]

hi, i m currently not sure what you mean by renderstate cache.

do you mean to save Sample, Rasterizer, Blend and so on? because that it already implemented
each state is saved in a map structure.

ps:
- OpenGl text is broken in example 11
- i ve another little patch (just clean up)
cleanup.patch

regards
zerochen

[Nadro]

Yep, OGL in FVF need some small fixes related to states cache merged to this branch from trunk.

I'll apply patch tomorrow (today I don't have a time for even check it).

What mean renderstate cache? Save eg info about blending on/of or current active textures, shader etc to simple variables (bool, int etc) and call API method only when state/variable was changed. You can check COpenGLCallBridge how it works (I think that D3D has built-in similar states cache, but it will be nice to check it), but I think that states saved in map structure works exactly in the same way, so other additions in this case aren't important for D3D11?

[Mel]

Well, you know, when you set a material, it sets a lot of render states, i was talking about a system that prevented that a state that doesn't change from a material to other didn't get actually changed. That goes for anything that requires a call to the runtime, FVF setting, texture filtering changes, and so on. For instance, changing a texture is unavoidable but maybe that both textures use the same filter settings, and those can be kept from one to other. That sort of things i was talking about.

[zerochen]

ok dx11 works a bit different. you dont have to call for every state a function like in dx9.

you have often a struct with the states. with that you create consant state that will be passed through the device.
currently the constant states are saved in a map so you dont have to recreate them

the only thing that can be optimized is that you dont have to set the constant state if it is already set but i think internally dx does the some (as nadro said)
i will test that next week

[Mel]

Ah, cool, it was sort of odd that if DX9 had so severe stall problems, they didn't make anything to solve them.

[Nadro]

I applied a patch

In example no. 10 we can see problems related to depth write by transparent objects.
In example no. 11 when we rotate a camera in some places, some artifacts are visible (bad tris are connected with gui I think, it's good visible in diffuse mode).

@Mel
This is open source project, so everyone can prepare a patch for optimize D3D9. We have limited resources.

[Mel]

I was referring to Microsoft i aknowledge the great effort you guys are doing.