http://bugs.winehq.org/show_bug.cgi?id=11674
--- Comment #22 from Norbert Lataille nonal@freesurf.fr 2009-06-02 07:42:59 ---
This struck me as very interesting. As we all know, WoW's OpenGL performance in Windows is a lot poorer than when using DX. It would make sense that the threading for DX is better written.
Well, I am not sure.
DX11 will bring better multi threading granularity to programmers, but Wow is not using this API...
I assume that wow code is modular with a DX or GL backend, non-mutlithreaded in both cases. To be confirmed. We need to check if when see 2 threads on Windows these are: 1/ display driver and 2/ Wow main thread. Running WoW in DX mode on wine would also show it.
However there is an option I would like to explore next. What I have seen on traces is that main thread (MT) hands over control to another thread (ST), and waits for completion of ST before continuing, and drawing next frame. There could be an implementation bug here (wine implementation of SetEvent/ClearEvent/WaitForxxx being too synchronous) but I doubt it.
I love the idea of threading opengl.dll.so. It makes sense as to why we're getting such slowdowns when in high performance environments.
GL is quite asynchronous. Most issues are coming from data/arrays you are sending to GLcore (you need to copy/use them before they are changed by the application), but VBO helps a lot here. In general I don't understand where this "pseudo-optim" to disable VBO came from (crappy ATI drivers ?)... For my tests I enable VBOs, it is far more efficient to indicate what data is (where, data size, give management options to the application for non-deformable vertex arrays !).