Summer of Code applicant with ambition!

[Roderick Colenbrander]

On Wed, Mar 31, 2010 at 12:13 AM, John Koelndorfer
<jkoelndorfer at 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