-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-05 10:54, schrieb Gediminas Jakutis:
This was discussed on the IRC a bit. The idea is to write [performance?] tests that are to be used for dxdiag. (I suppose that includes that funny spinning dx logo cube test found on the native dxdiag).
I think performance tests for dxdiag won't work, but a related idea might: In the past, I have written a number of microbenchmarks for various d3d operations like drawing, changing stream sources, changing vertex shaders, etc. You can find the code at https://84.112.174.163/~git/perftest (self-signed cert). I'm also running some of those tests
The overall idea is to use such microbenchmarks to optimize single operations, in the hope that those optimizations stack up and improve real games. Most benchmarks have a GL version to find out if there's a difference between the GL and d3d drivers, or the Windows and Linux drivers.
Adding more benchmarks to this collection and investigating spotted performance differences would be a useful gsoc project imo.
Regarding the way of testing if opengl works - I was thinking in the lines of: Making a GUI tool that would let simple users test if d3d and opengl works along with providing info on current wine-specific d3d / opengl settings / specs and similar thing.
There are tests like that in CrossOver, and my experience with them is that they don't provide too much value. The warnings if libGL.so doesn't load, or if direct rendering is not available are helpful, but all other tests go unmaintained over time and become irrelevant.
Wine prints some info like that on the winediag debug channel. Showing a window instead could be a usability improvement, but that's not enough work for gsoc.