Call overhead stats

[Mel]

But, isn't it posible to apply the same optimizations to DirectX?

[Granyte]

and i guess that if anyone was to optimise the dx driver the patch would only go to the land of the forgoten patch

[zerochen]

hi,

are these really improvements?
i made a quick test and this are the results. can anybody confirm this? it seems that shaders are much slower


regards
zerochen

[ACE247]

Actually that's not a real good way of testing. You'll need a proper analysis tool to trace program execution and test what parts of a program take how much time.
Also Irrlicht examples are graphically very simple, so performance improvements are not very reliably noticeable and only really show themselves in more complex scenes.

[Mel]

Don't take the examples as good benchmarking samples because their behavior isn't completely predictable on one side, and the optimizations may produce side effects on simple scenes as those of the examples, that derive on the loss of FPS, while on more complex scenes, the optimization is noticeable. Perhaps an unified benchmark to run all the optimizations would be a good idea..

[Nadro]

@Mel
I am not too much familiar with DX, so I can't replay on Your question about compatibility OGL optimizations with DX.

@zerochen
Do You use Intel GPU? On my platform I see performance boost in all Irrlicht examples. I think that problems may be related to changes in 2D rendering interface (I removed deprecated stuff). It looks like a drivers are bugged, because from hardware side an current calls overhead is much smaller than before, so less calls = better performance. As I said only changes in 2D rendering stuff may be more expensive on Your platform. For example remove text nodes from examples no. 10 and 11 and check again a performance, but without text drawing.

[zerochen]

no nvidia. after i tried release mode as well deactivated trillian in game chat the performance is better with the latest rev. so it was my fault. sry

[ACE247]

Actually @nadro, have you seen my post in SVN Bug reports thread? How might that relate to the recent changes in 2D/other rendering you made?

[Nadro]

Thanks for info (it's related to changes in 2D rendering - I have to improve lines rendering).

[Mel]

But the current system seems to encapsulate the open GL calls into a frontend that later translates or not into glCalls when necesary, can't that be translated to directX somehow? or am i mistaken?

[Nadro]

In theory yes, but some cache methods works like an OGL works (some settings are bound to objects, some to environment, some to active TIU etc.), so some changes may be require. If someone have some DX experience should translate current OGL bridge to DX, but it will be not me (I don't have required experience and I hate MS API).

[Mel]

Hate isn't a good working partner, you never know when your enemy will become a...working tool... Still the way the optimizations are performed seem very similar to both API's I will take a look. No promises, though

[Nadro]

I shouldn't use this API in near future - 5 years (I'm 99% sure) I need cross platform solutions, thats why I hate DX, but EOT

BTW. I heared that simple DX call is more expensive than OGL call in many things, maybe DX calls have some internal cache system?

[Mel]

Their catch is that they imply a user/kernel context switch within them, hence the penalty, even though much of the DX9 code in the runtime has been already moved to the user mode. GL works only in user mode, so it is even more important to have DX calls well cached. And yes, there is already an interface for DirectX calls manager in the API, but not much people implements it, they rather custom managers, such as the "bridge" solution proposed for Open GL here.

[hendu]

Ah good, I was going to nuke the glBegin calls myself later. Good that they're gone now.

Re Intel vs low-end Nv:

No surprise, as PCI-E 16x is slower than RAM. There may be other factors involved like the intel card having better/more vert units than a gt630.

Hate isn't a good working partner, you never know when your enemy will become a...working tool... Still the way the optimizations are performed seem very similar to both API's I will take a look. No promises, though

They're very different like nadro said. DX works with objects, so it should already just ignore it if you set something to the same value.