Originally posted by Dukenukemx
View Post
Announcement
Collapse
No announcement yet.
Gallium3D Direct3D 9 For Wine Revived, Again
Collapse
X
-
Originally posted by Dukenukemx View PostIt goes to show that a lot of people want Linux to be able to play their games, so they can move away from Windows for good. That's why it's just a heated discussion. If you can improve the frame rate by even 1 fps, then you better believe people want you to go for it. But the state tracker can improve that performance by a significant magnitude, and that's just enough to turn this thread into a flame war. Even though the Command Stream D3D Patch can probably produce nearly equal performance.
The D3d state tracker, if properly developed, could eliminate translation (d3d->ogl) overheads and provide the same or even faster performance using the SAME HARDWARE RESOURCES as Windows
Command stream on the other hand, can provide the same performance, but by using MORE HARDWARE RESOURCES than Windows. At least one cpu core more...
It is not the same. D3D state tracker could be much, much more efficient. The only downside is that it is available only for gallium...
Comment
-
Originally posted by curaga View PostUmm, 3d graphics cards were made for CAD and visualization originally. SGI and Iris GL. http://www.codingunit.com/the-history-of-opengl
SGI products were meant for servers and workstations, not home computers.
Comment
-
Originally posted by TemplarGR View PostThere is a difference between a d3d state tracker and command stream patches:
The D3d state tracker, if properly developed, could eliminate translation (d3d->ogl) overheads and provide the same or even faster performance using the SAME HARDWARE RESOURCES as Windows
Command stream on the other hand, can provide the same performance, but by using MORE HARDWARE RESOURCES than Windows. At least one cpu core more...
It is not the same. D3D state tracker could be much, much more efficient. The only downside is that it is available only for gallium...
Comment
-
Originally posted by TemplarGR View PostThere is a difference between a d3d state tracker and command stream patches:
The D3d state tracker, if properly developed, could eliminate translation (d3d->ogl) overheads and provide the same or even faster performance using the SAME HARDWARE RESOURCES as Windows
Command stream on the other hand, can provide the same performance, but by using MORE HARDWARE RESOURCES than Windows. At least one cpu core more...
It is not the same. D3D state tracker could be much, much more efficient. The only downside is that it is available only for gallium...
I am glad that people understand the 90% of the truth. The other 10% is that the D3D state tracker is not only for gallium. A simple gallium patch, can allow to gallium it self to connect with closed drivers, and we can use the state tracker. Closed drivers can use Mesa libraries on Linux, Windowz and OSXxx, and the connection points are known for years. Closed drivers are not that far from Mesa as you thing they are.
Comment
-
Originally posted by stefandoesinger View PostOk, now that the flamewar has toned down a bit let me join the party
I stand by my statement that writing a Mesa-specific d3d implementation is inferior to improving the platform independent code as long as the platform independent code has room for improvement. That statement has been discussed ad nauseam, so let's have a look at the wine patch that integrates gallium-nine:
The integration is done by exporting an IDirect3D9-like interface from Mesa. This has the advantage that the interface between Mesa and Wine is quite simple and I guess relatively stable, but it won't do any of those things:
- Support ddraw or d3d8
- Properly handle window messages (wined3d_device_acquire_focus_window and device_process_message in wined3d)
- Allow IDirect3DSurface9::GetDC to work
- Report resolution changes properly to the application (another message handling fun)
- Swapchain window overrides
- Any of the new Win32<->d3d9 interaction features in d3d9ex.
Also the code writes directly to the top level X11 drawable. If the application renders to a Win32 child window (e.g. the StarCraft II map editor), the GDI elements on the Window will just be overwritten by the gallium rendering output. This is difficult to fix because child windows are not X11 windows - they're just managed by Wine itself due to window management differences between X11 and Win32.
There are plenty of applications that work fine without any of those things, but there's a whole set of applications that will never work without a major redesign. And with that redesign you open up an entirely new can of worms. You'll have to think about a common interface for all d3d versions and how to mix different Mesa and Wine versions.
Don't get me wrong - Christoph Bumiller knew what he was doing when he wrote this thing. It avoids many pitfalls some of the "hello world" d3d and ddraw implementations out there have. But he also knew what he was doing when he made this a proof of concept research project.
I welcome any efforts to maintain this code and make it run more games. Even if we don't include it in Wine anytime soon it is a useful benchmarking and debugging tool. And it allows users to choose and use whatever fits them best.
If I can help by answering questions about the technical details of Direct3D I'm more than happy to do so - just contact me directly or mail wine-devel. If I may make a suggestion for the way forward: Try to make Wine's d3d9 tests work. Some of those tests may seem like they're testing unimportant details, but all of those were inspired by real application behaviors and debugging the tests is way easier than debugging binary blobs. Furthermore, making those tests run is the perfect way to show you mean business.
Note that we don't believe that there are legal issues with this code. Those problems were about the d3d10/11 pipeline implementation attempt. The d3d1x authors used confidential headers from the Windows DDK to code their software. This is not the case for gallium-nine to my knowledge.
Comment
-
Originally posted by stefandoesinger View PostOk, now that the flamewar has toned down a bit let me join the party
I stand by my statement that writing a Mesa-specific d3d implementation is inferior to improving the platform independent code as long as the platform independent code has room for improvement. That statement has been discussed ad nauseam, so let's have a look at the wine patch that integrates gallium-nine:
The integration is done by exporting an IDirect3D9-like interface from Mesa. This has the advantage that the interface between Mesa and Wine is quite simple and I guess relatively stable, but it won't do any of those things:
- Support ddraw or d3d8
- Properly handle window messages (wined3d_device_acquire_focus_window and device_process_message in wined3d)
- Allow IDirect3DSurface9::GetDC to work
- Report resolution changes properly to the application (another message handling fun)
- Swapchain window overrides
- Any of the new Win32<->d3d9 interaction features in d3d9ex.
Also the code writes directly to the top level X11 drawable. If the application renders to a Win32 child window (e.g. the StarCraft II map editor), the GDI elements on the Window will just be overwritten by the gallium rendering output. This is difficult to fix because child windows are not X11 windows - they're just managed by Wine itself due to window management differences between X11 and Win32.
There are plenty of applications that work fine without any of those things, but there's a whole set of applications that will never work without a major redesign. And with that redesign you open up an entirely new can of worms. You'll have to think about a common interface for all d3d versions and how to mix different Mesa and Wine versions.
Don't get me wrong - Christoph Bumiller knew what he was doing when he wrote this thing. It avoids many pitfalls some of the "hello world" d3d and ddraw implementations out there have. But he also knew what he was doing when he made this a proof of concept research project.
I welcome any efforts to maintain this code and make it run more games. Even if we don't include it in Wine anytime soon it is a useful benchmarking and debugging tool. And it allows users to choose and use whatever fits them best.
If I can help by answering questions about the technical details of Direct3D I'm more than happy to do so - just contact me directly or mail wine-devel. If I may make a suggestion for the way forward: Try to make Wine's d3d9 tests work. Some of those tests may seem like they're testing unimportant details, but all of those were inspired by real application behaviors and debugging the tests is way easier than debugging binary blobs. Furthermore, making those tests run is the perfect way to show you mean business.
Note that we don't believe that there are legal issues with this code. Those problems were about the d3d10/11 pipeline implementation attempt. The d3d1x authors used confidential headers from the Windows DDK to code their software. This is not the case for gallium-nine to my knowledge.
Are there any plans for a Wayland port of Wine? gallium-nine itself is in no way tied to X11, might it be easier to implement some of the deficiencies if/when Wine is targeting a wayland backend?
Comment
-
Originally posted by Dukenukemx View PostThe graphic cards we deal with, like 3DFX Voodoo, ATI Rage, and Nvidia Riva 128, were made for gaming. Every graphics card sold in retail stores like CompUSA, were for gaming. Todays graphic cards are based on that. Just so happens graphic cards are great for accelerating UI's and video decoding as well.
SGI products were meant for servers and workstations, not home computers.
Comment
-
Originally posted by andrebrait View PostDo you have any idea of how Valve's togl works? Just wondering. It has a very low overhead.
Though in my testing wined3d beats Valve's d3d->gl wrapper in Team Fortress on my old GeForce 9600. Valve's code beats wined3d hands down on the newer GTX 460 however. That was about a year ago, and I didn't yet have my command stream implementation back then.
Also, the source engine is a very efficient engine.
Comment
-
Originally posted by s_j_newbury View PostAre there any plans for a Wayland port of Wine?
The code refactoring we did to support the mac driver allows us to add drivers for other windowing systems much easier than we used to. (There goes the "wine only cares about macs" conspiracy theory...)
There are some design choices Wayland made that might make it difficult to support Win32 as well as we can on X11. Some applications that e.g. depend on global window placements may only work in a virtual desktop.
Originally posted by s_j_newbury View Postgallium-nine itself is in no way tied to X11, might it be easier to implement some of the deficiencies if/when Wine is targeting a wayland backend?
Comment
Comment