[Bug 11674] Dual-core not being correctly supported in World of Warcraft (WOW)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=11674





--- Comment #22 from Norbert Lataille <nonal at 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 !).

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.