On Wed, Mar 31, 2010 at 12:13 AM, John Koelndorfer jkoelndorfer@gmail.com wrote:
I've done a little bit of research on Direct3D. Having seen how easy the tutorial at http://www.directxtutorial.com/ is, I think I'd like to propose the following: a 3D benchmarking program that would allow users and developers to determine what aspects of WineD3D are the slowest so that they can be improved.
My high level idea is that a user would be able to set graphics options (similar to a game -- or maybe automatically test many configurations) and a 3D "demo" would run. It would time D3D function calls so that we can get an idea for which functions need optimization, report FPS at points in time, and whatever else makes sense as I learn more about it.
Note, I don't want to discourage you but I'm not sure if we should write any benchmark app to be bundled with Wine. When a game is slow it can be due to a lot of factors: - quality of the display drivers, basically only Nvidia's drivers (though AMD is catching up) are well optimized - opengl extensions supported by the display driver, not all drivers support functionality like FBOs, GLSL and other stuff which is needed to run games at good speeds - behavior of the app, if unlucky the app makes calls which are inefficient to emulate (on newer cards, modern opengl extensions can remove some of the limitations and we use such extensions where we can)
So when you encounter a 3D performance issue, it is not necessarily a Wine issue. Profiling using a tool like oprofile/sysprof can shine some light on the problem. Typically it is not that a huge part of the time is spent in a specific Wine call though. A lot of CPU time might be spend in display drivers. Whether that is because we are using it in an inefficient way or whether the driver is not well optimized is hard to say because typically drives don't contain debug symbols.
I think that a Wine 3D demo is not sufficient to properly test for performance issues. If you want to work in this area, perhaps a more generic 3d testing framework is a better project which uses real games (or demos). Codeweavers uses I believe cxtest to monitor performance regressions in 3dmark 2003, half-life 2 and other apps. I have no idea how robust this framework is. Perhaps it can be improved (or rewritten). We have some basic fps dumping code using WINEDEBUG=+fps which could be used if a game doesn't provide a way to retrieve results. Nvidia (perfkit/perfhud for NV) and AMD drivers offer performance counters which give indications on how busy parts of the GPU are. Perhaps that stuff could be used to improve results.
Roderick