Hello!
My previous application[1] turned out to be a total failure, hence making a completely different one. My proposal this time goes as follows: Write various D3D tests, mostly focusing on ones that can be later re-used for dxdiag in one way or another. Along with writing a tool that would allow users to easily test if d3d and wgl / opengl work & are set up properly.
Info about me (copied over from [1]):
My name is Gediminas Jakutis. I study Informatics Engineering [bachelor / undergraduate] at Kaunas University of Technology, second year. I wish to try out GSoC for the first time by helping to improve Wine. My primary programming language is C. I am self-taught in C, but I believe my knowledge is good enough. I am quite familiar with Wine - I use it and experiment with it for many years now. I am subscribed to and read wine-devel for more than a year. I browse through Wine's source code once in a while out of curiosity. Thus, I have some knowledge of its structure. Sadly, I have not written any patches for Wine yet. Mostly due to lack of confidence.
[1] http://www.winehq.org/pipermail/wine-devel/2013-March/099213.html
Thank You for Your time Gediminas Jakutis
-- LDK Varčiai www.varciai.lt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-04 22:52, schrieb Gediminas Jakutis:
Hello!
My previous application[1] turned out to be a total failure, hence making a completely different one. My proposal this time goes as follows: Write various D3D tests, mostly focusing on ones that can be later re-used for dxdiag in one way or another. Along with writing a tool that would allow users to easily test if d3d and wgl / opengl work & are set up properly.
There is some merit to the proposal, but it needs a lot more detail. We already have a lot of d3d tests (see dlls/{ddraw,d3d8,d3d9,d3d10core,dxgi}/tests/) . Those already provide a way to test if opengl works ok, to some extent - those tests are fairly strict and only pass on nvidia and r600g.
Extending dxdiag (and adding the information dialog) might be a good idea. I think there have been some projects concerning that in the past, I recommend to do some research.
Lastly there are some bug reports which need tests, e.g. 10164 and 29052. Bug 29052 should provide a nice introduction into ddraw/d3d programming in Wine, but those two bugs do not provide enough work for a full gsoc project. Some additions will be needed. However, Alexandre has stated that writing tests for the tests sake (i.e., no application that uses the testsed behavior) is not a good idea. Picking any number of apps which have bugs that are not understood yet and attempting to fix them is a bad idea as well because you don't know how long it'll take you to fix them until you have some idea what the actual problem is.
On Fri, Apr 5, 2013 at 10:08 AM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-04 22:52, schrieb Gediminas Jakutis: There is some merit to the proposal, but it needs a lot more detail. We already have a lot of d3d tests (see dlls/{ddraw,d3d8,d3d9,d3d10core,dxgi}/tests/) . Those already provide a way to test if opengl works ok, to some extent - those tests are fairly strict and only pass on nvidia and r600g.
Good day!
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). 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. i.e. a user-friendly tool for, uhm, simple users. Something related to what wine crash dialog is: I bet many "simple" users were not much aware of Wine's debug output and bug reporting. Meanwhile the crash dialog was something like - "Hey! Something crashed! Take this info and report it if it's a bug!". So yes, the idea idea of the "if works" test is to make a user-friendly GUI tool. I believe that would be a great help in cases for some reason opengl [and along d3d] breaks for a user, so it could be easily identified early, thus helping to avoid situations where the user looks into other possible causes / asks around for quite some time before realizing opengl w/ d3d broke. Also, that might help avoid possible invalid bug reports that would caused by a broken opengl / d3d, yet reported without the user checking that properly.
Extending dxdiag (and adding the information dialog) might be a good idea. I think there have been some projects concerning that in the past, I recommend to do some research.
I suppose when making those dxdiag-orientated tests, working with built-in dxdiag a bit might just come naturally.
I hope that makes my intentions for GSoC a bit more clear. And, sorry - I should've gone with more detail on previous letter, indeed.
-- Gediminas Jakutis LDK Varčiai www.varciai.lt
-----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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-04-09 13:01, schrieb Stefan Dösinger:
I'm also running some of those tests
That sentence got cut off: I'm also running some of those tests on a nightly basis to monitor Wine's performance.
-
Gediminas Jakutis -
Stefan Dösinger