Gallium3D Direct3D 9 For Wine Revived, Again

[Dukenukemx]

I suspect the issue is much more as has been suggested above re. MacOSX support... the only important Linux drivers this can't support are the proprietary ones...

If MacOSX support is the issue, then it's more to do with CrossOver profits then Wine development.

Do you think it would be possible, or even worth it, if say a program installed through Wine that used Directx had all of that Directx->OpenGL? So then at runtime it would be running OpenGL(created from Directx) with no overhead.
In short:
Wine->Install; Directx->OpenGL
Wine->Emulate Win32 program; OpenGL

Is that sort of thing possible? I have a feeling that we'd need the source code to make a major modification like that.

You mean like an Direct3D to OpenGL wrapper? They already exist, but you wouldn't stop the overhead. Done in Windows or Linux, you still have extra work for the CPU to do.

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.

[tuubi]

You mean like an Direct3D to OpenGL wrapper? They already exist, but you wouldn't stop the overhead. Done in Windows or Linux, you still have extra work for the CPU to do.

I think he means an in-place conversion of all direct3d calls to opengl calls in the game binaries, so no runtime wrapping would be necessary. Wouldn't that be a nice bit of black magic? It's not like d3d-to-gl migration is just a matter of replacing some api calls and headers even at code level. Even if someone conjured up such a wonderful tool, there's no way it could produce anything but horribly unoptimized abominations.

[Dukenukemx]

I think he means an in-place conversion of all direct3d calls to opengl calls in the game binaries, so no runtime wrapping would be necessary. Wouldn't that be a nice bit of black magic? It's not like d3d-to-gl migration is just a matter of replacing some api calls and headers even at code level. Even if someone conjured up such a wonderful tool, there's no way it could produce anything but horribly unoptimized abominations.

Even if you could successfully do that, it would have to be cater made per game. BioShock was a completely Directx9.0c game, and Radeon X850 owners and lower couldn't play the game. A fan went through the trouble to hack it to be regular DirectX9, and it barely works. Can you imagine what work would need to be done to get every game in existence to produce OpenGL code?

[profoundWHALE]

I think he means an in-place conversion of all direct3d calls to opengl calls in the game binaries, so no runtime wrapping would be necessary. Wouldn't that be a nice bit of black magic? It's not like d3d-to-gl migration is just a matter of replacing some api calls and headers even at code level. Even if someone conjured up such a wonderful tool, there's no way it could produce anything but horribly unoptimized abominations.

For some reason, I just love the way you phrased that, and I agree, it would probably be horribly unoptimized.

Even if you could successfully do that, it would have to be cater made per game. BioShock was a completely Directx9.0c game, and Radeon X850 owners and lower couldn't play the game. A fan went through the trouble to hack it to be regular DirectX9, and it barely works. Can you imagine what work would need to be done to get every game in existence to produce OpenGL code?

For each new install it would have to be done, yes, but it wouldn't be any different as to what games work. The only difference is there'd be no overhead.

(At this rate a Directx 9 native execution is a better idea)

[stefandoesinger]

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.

[zanny]

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

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".

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.

[Dukenukemx]

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.

[stefandoesinger]

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".

As I've explained in my post, Direct3D is a lot more linked to Win32 than it may seem. There is a whole set of operations a gallium state tracker as it is designed right now cannot support.

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.

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.

I hope that day comes some day. But for now we still have to deal with binary drivers, Windows (yes, there are people who use wined3d on Windows), OSX and Android. Personally I don't test any BSD system, but Francois (one of my coworkers at CodeWeavers) makes sure Wine doesn't break there.

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.

[artivision]

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.

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 2core_9.6dmips/[email protected] AVX i3, 60,000dmips. A total 3x.

Wine must considered from community, high priority software, the one in the center that solves all problems.

[Dukenukemx]

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 2core_9.6dmips/[email protected] AVX i3, 60,000dmips. A total 3x.

Wine must considered from community, high priority software, the one in the center that solves all problems.

I know a lot of people throw gaming to the side as unimportant, but consider this. The graphics card only exists for gaming. It wasn't made for anything else, but to play games. Yet today it's one of the most important components in computer systems.

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.

But what was so shocking to me was that Windows was the second highest usage application in the U.S. The number one application was Doom, a shareware program that hadn't been created by any of the powerhouse software companies. It was a 12-person company in the suburbs of Texas that didn't even distribute through retail, it distributed through bulletin boards and other pre-Internet mechanisms. To me, that was a lightning bolt. Microsoft was hiring 500-people sales teams and this entire company was 12 people, yet it had created the most widely distributed software in the world. There was a sea change coming.