John Koelndorfer wrote:
I've again gone over the list of possible projects on the Summer of Code page and one that particularly piqued my interest was "Direct3D - Conformance / Performance / Interactive tests". This seems like it may be a good fit given my lack of previous experience in the Wine codebase. I haven't written any code for 3D-ish games but I can't imagine that would be a huge setback. Maybe Dan Kegel or someone else who has worked on D3D can comment here?
(Correction: I've never worked on D3D :-)
Offhand, if you're not already a 3d person, that might be kind of hard? Although maybe the "get dxdiag working" task might be easy enough. (The only problem with that is it involves committing someone else's code, which isn't a good focus for a GSOC project.)
If that is not feasible, I think I would be a strong candidate for the "Test Suite" project since my scripting-fu is fairly strong.
Sure, you could find and fix tons of problems that way, I bet. - Dan
(Correction: I've never worked on D3D :-)
Fair enough, I just noted that you were listed as a possible mentor for that project so I figured you'd be the person to ask.
Sure, you could find and fix tons of problems that way, I bet.
Well that's good to hear. If that can help the Wine hackers work faster and it's a low-grade learning curve then we might have a winner. Of course, I am still open to other suggestions if there are any.
On Tue, Mar 30, 2010 at 11:04 PM, John Koelndorfer jkoelndorfer@gmail.com wrote:
(Correction: I've never worked on D3D :-)
Fair enough, I just noted that you were listed as a possible mentor for that project so I figured you'd be the person to ask.
Sure, you could find and fix tons of problems that way, I bet.
Well that's good to hear. If that can help the Wine hackers work faster and it's a low-grade learning curve then we might have a winner. Of course, I am still open to other suggestions if there are any.
One useful project could be to finish the DirectShow/Gstreamer work. You would have to ask Edward Hervey about it. A few days ago he mentioned on IRC that he was planning to check the status of the code again and he had suggestions for future work about a generic dshow/gstreamer wrapper. This area is a challenging area though but I think there is not that much porcelain you can break.
Roderick
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.
As I mentioned before, I haven't really done anything w/ 3D but in my endeavors as a student I've taken up through calculus 4 (including linear algebra) so I think that will give me a leg up here. I plan to do some research on D3D before SOC begins.
Does this sound like it would be useful to work on? Working on 3D sounds like a particularly fun project to me and I don't think I'd mind spending some extra hours on it if need be.
Sorry for hitting the list so hard -- SOC was only recently suggested to me and I am really set on contributing to Wine if that's possible.
Again, thanks for your support and suggestions.
John
On Tue, Mar 30, 2010 at 4:13 PM, 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.
Ideally that would be part of wine's dxdiag.exe. Windows' has 'Test DirectDraw' and 'Test Direct3D' options, which would be useful to do in wine as well.
See also http://bugs.winehq.org/show_bug.cgi?id=14118.
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
<snip thread>
Sorry this is a little off topic from D3D but maybe what the OP is looking for.
I'm not sure how easy it is but .net 3.5 sp1 is currently a blocker for several high profile games that would otherwise work well with Wine, and many others that may work. .net needs to install correctly and function well enough so that generic .net game lunchers run and (importantly) Games for Windows Live runs and authenticates. GFWL is what many of these games rely on and it is currently blocked by .net so it's unknown how well it runs under Wine but it does install properly.
This maybe suited to a GSoC project and in my opinion would have the greatest positive outcome for gamers.
Edward
On Tue, Mar 30, 2010 at 6:11 PM, Edward Savage epssyis@gmail.com wrote:
<snip thread>
Sorry this is a little off topic from D3D but maybe what the OP is looking for.
I'm not sure how easy it is but .net 3.5 sp1 is currently a blocker for several high profile games that would otherwise work well with Wine, and many others that may work. .net needs to install correctly and function well enough so that generic .net game lunchers run and (importantly) Games for Windows Live runs and authenticates. GFWL is what many of these games rely on and it is currently blocked by .net so it's unknown how well it runs under Wine but it does install properly.
This maybe suited to a GSoC project and in my opinion would have the greatest positive outcome for gamers.
Edward
Edward seems to know what I'm after. :-) As I mentioned originally, I'm a gamer and so that's where I'd like to lend my coding arm. If .net is doable, I'd certainly look into that too.
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.
I certainly agree here 100% -- however, my own previous experiences have led me to conclude that there are Wine performance deficiencies *somewhere* (maybe not necessarily D3D, but it seems the likely candidate). See e.g. Warcraft 3 and World of Warcraft. Both of these games have Direct3D and OpenGL modes. Running each game in Wine (at least in my testing from several months to a year ago) D3D was anywhere from 40-60% slower than OpenGL mode. I'd be happy to test with the latest Wine, too. The point is, all things being held constant, calls that had to go through WineD3D were much slower. That's where the spirit of my proposal came from, anyways.
Now, you might say "does Wine need some sort of benchmarking?" That's debatable. Maybe it could be a part of dxdiag? My goal for this proposal was to create something that developers could use to assess performance deficiencies, or that end users (maybe) could use to figure out what type of effects ought to be turned off/down on their systems. Essentially, answer the question "what's making my FPS drop?" Is it AF, AA, specular lighting, HDR?
There's been a lot of feedback so far (thanks!) So far, the projects I'd like most are roughly:
* Get .net 3.5 working * Implement dxdiag * DirectShow/Gstreamer * The "Direct3D - Conformance / Performance / Interactive tests" given @ http://wiki.winehq.org/SummerOfCode#head-8d0895f237c9c3579ffe4282412bbbf2c8c...
Again, many thanks for all the helpful feedback. I look forward to (hopefully) being able to work with you all in the near future. :-)
John
One of the most useful GSOC project for gamers would be to implement DInput with XInput2.
Vitaly sent some hackish patches in Bug 6971
It could be a good start to begin to code.
A+
David
On Tue, Mar 30, 2010 at 6:11 PM, Edward Savage epssyis@gmail.com wrote:
<snip thread>
Sorry this is a little off topic from D3D but maybe what the OP is looking for.
I'm not sure how easy it is but .net 3.5 sp1 is currently a blocker for several high profile games that would otherwise work well with Wine, and many others that may work. .net needs to install correctly and function well enough so that generic .net game lunchers run and (importantly) Games for Windows Live runs and authenticates. GFWL is what many of these games rely on and it is currently blocked by .net so it's unknown how well it runs under Wine but it does install properly.
This maybe suited to a GSoC project and in my opinion would have the greatest positive outcome for gamers.
Edward
Edward seems to know what I'm after. :-) As I mentioned originally, I'm a gamer and so that's where I'd like to lend my coding arm. If .net is doable, I'd certainly look into that too.
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.
I certainly agree here 100% -- however, my own previous experiences have led me to conclude that there are Wine performance deficiencies *somewhere* (maybe not necessarily D3D, but it seems the likely candidate). See e.g. Warcraft 3 and World of Warcraft. Both of these games have Direct3D and OpenGL modes. Running each game in Wine (at least in my testing from several months to a year ago) D3D was anywhere from 40-60% slower than OpenGL mode. I'd be happy to test with the latest Wine, too. The point is, all things being held constant, calls that had to go through WineD3D were much slower. That's where the spirit of my proposal came from, anyways.
Now, you might say "does Wine need some sort of benchmarking?" That's debatable. Maybe it could be a part of dxdiag? My goal for this proposal was to create something that developers could use to assess performance deficiencies, or that end users (maybe) could use to figure out what type of effects ought to be turned off/down on their systems. Essentially, answer the question "what's making my FPS drop?" Is it AF, AA, specular lighting, HDR?
There's been a lot of feedback so far (thanks!) So far, the projects I'd like most are roughly:
* Get .net 3.5 working * Implement dxdiag * DirectShow/Gstreamer * The "Direct3D - Conformance / Performance / Interactive tests" given @ http://wiki.winehq.org/SummerOfCode#head-8d0895f237c9c3579ffe4282412bbbf2c8c...
Again, many thanks for all the helpful feedback. I look forward to (hopefully) being able to work with you all in the near future. :-)
John
Hi,
I think writing (yet another) D3D benchmark isn't going to help a lot, there are already numerous benchmarks out there.
I have built a very hacky set of cxtest and php scripts that run a bunch of benchmarks and games(3DMark, Half Life 2, UT 2004, Team Fortress), store the results on a server and generate some graphs with gnuplot. Extending this and making it easier for others to run would be more useful than implementing another benchmark.
If you want to get familiar with the D3D code writing tests is a good start. If you want to implement some small new functionality, maybe Nvidia's Depths Bound extension( NVDB, see http://aras-p.info/texts/D3D9GPUHacks.html ) might be a possible weekend project.
Btw, the above webpage might have some other d3d9 "extensions" that are more work could be suitable for Gsoc projects, maybe DF16, DF24, INTZ, RAWZ, NULL and ATOC.
Optimizing wined3d is certainly an idea as well, but it's not an easy task. We're beyond the point where you can get reasonable performance gains from simply fixing a loop or two. Some performance issues are known bugs(sRGB switching, sRGB write correction in HW, thread synchronization), others require tedious debugging to find out what specific 3D drivers don't like about our GL calls.
On Wed, Mar 31, 2010 at 11:56 AM, Stefan Dösinger stefandoesinger@gmx.at wrote:
Hi,
I think writing (yet another) D3D benchmark isn't going to help a lot, there are already numerous benchmarks out there.
I have built a very hacky set of cxtest and php scripts that run a bunch of benchmarks and games(3DMark, Half Life 2, UT 2004, Team Fortress), store the results on a server and generate some graphs with gnuplot. Extending this and making it easier for others to run would be more useful than implementing another benchmark.
If you want to get familiar with the D3D code writing tests is a good start. If you want to implement some small new functionality, maybe Nvidia's Depths Bound extension( NVDB, see http://aras-p.info/texts/D3D9GPUHacks.html ) might be a possible weekend project.
Btw, the above webpage might have some other d3d9 "extensions" that are more work could be suitable for Gsoc projects, maybe DF16, DF24, INTZ, RAWZ, NULL and ATOC.
Optimizing wined3d is certainly an idea as well, but it's not an easy task. We're beyond the point where you can get reasonable performance gains from simply fixing a loop or two. Some performance issues are known bugs(sRGB switching, sRGB write correction in HW, thread synchronization), others require tedious debugging to find out what specific 3D drivers don't like about our GL calls.
Perhaps the long talked about fixed function vertex shader replacement could be an option though. It would fix vertex blending but it might also improve performance (some people were complaining about poor GL T&L performance http://forum.winehq.org/viewtopic.php?t=7975). Further it might be more efficient for modern drivers anyway, especially open source DRI ones since they are mostly investing in shaders.
Roderick
-
Austin English -
Dan Kegel -
Edward Savage -
John Koelndorfer -
paulo lesgaz -
Roderick Colenbrander -
Stefan Dösinger