If you want the fastest performance right now, just install this PPA. Don't forget to also add the ppa:ubuntu-wine/ppa as well.
(At this rate a Directx 9 native execution is a better idea)
Ok, 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.
Why? This is basically the same line of thinking Debian has about not using systemd - hey, a ridiculously small portion of our userbase uses arcane technologies the rest don't, but we can't use an objectively better system because we need to stay 'portable".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
At some point the world needs to come to grips with coreboot + linux + systemd + mesa basically ruling everything, taking over all devices, and everyone being in a wonderful bliss of open computing and open collaboration rather than reinventing the wheel all the time.
It 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.
I don't agree that "runs some applications faster" vs "will never run some applications by design" qualifies as "objectively better". The same for a widely accepted industry standard with a formal specification vs an internal interface of one piece of software.
The best future I can see for a gallium-wine integration is writing a gallium shader backend for wined3d. We already have an abstraction layer to support GLSL, ARB_*_program, GL_ATI_fragment_shader and GL_NV_texture_shader. Adding a module that supports native TGSI code might just be a fill-in-the-blanks exercise. That way you take advantage of bypassing GLSL and still keep the Direct3D implementation in its native Win32 environment.
The same thing can be done for the rest of the GL calls in theory, but it is more work.
But I agree that there are some limits to platform independence. I don't know what the right decision is re systemd vs other startup tools, or making systemd Linux-only. I use systemd on some of my Linux installations, OpenRC on others. Both get the job done and I couldn't care less about which one is used.
Something about games: they are more important than gold. Even animals play, we just play better. Games and virtual worlds will be part of our future. Today proprietary hardware and software, only exist because of games. No one is interested for programs, high quality software exist on all platforms, mostly with free software. The first rate and mostly scenario games like FF are for consoles, the second rate and mostly online mmo are for MS-PC and everything else for the rest of the systems. We must somehow find the way to emulate D3D efficiently (if we want free software to win). And we must find the way to emulate Instruction_sets efficiently (if we want free hardware to win). So many years proprietary Instruction_set computing and just C. We are decades behind because of proprietary.
I know someone that has work for Instruction_set emulation. They are many projects like: https://en.wikipedia.org/wiki/Loongson and like http://news.softpedia.com/news/X86-o...s-296390.shtml He told me that we will not succeed any time soon because of Wine's D3D inefficiency. No one want emulation for programs, high quality software exist on all platforms, they only try for games.Wine with native D3D can perform with just a 2core_3.6dmips/mhz_@3ghz core2 pentium, just 20,000dmips. Wine GLSL needs at least a firstname.lastname@example.org AVX i3, 60,000dmips. A total 3x.
Wine must considered from community, high priority software, the one in the center that solves all problems.
Angry birds pushes sales of Android tablets and smart phones, and Doom pushed PC sales back in the day. Don't underestimate the power of gaming.
Originally Posted by Gabe Newell