Direct3D 9 Support Released For Linux Via Gallium3D, Running Games

[zhasha]

Ouch. Ok, you're right, i didn't actually look at the code and was trying to go off what i thought. However, doesn't this go against what was earlier said that native apps couldn't run against it? Is there some other reason this is true? I confess to not really understanding the commit you linked to, because it's just a big deletion of the wine code, so it doesn't really show how you achieved the support without it and i'm not familiar enough with mesa/graphics code to find that on my own.

It's designed so that the state tracker doesn't know about the window system, only the subsystem (drm in this case). For this I came up with ID3DAdapter9 and its accompanying Present interfaces. Originally there were two libraries, both compiled from within the mesa tree; notably libd3d9-xlib. IDirect3D9[Ex] is a completely self contained interface and although it parrots many Windows-isms it's by no means dependent on Windows. As you can see from this ginormous, ugly function, mapping X11 to the functions in the IDirect3D9[Ex] interface is perfectly possible. This was in fact the way I originally tested the driver as it was significantly easier than getting it to work with wine's internals and pulling useful debug information.
The libd3d9-xlib implementation bitrotted and eventually it was nuked since everything was done through wine, but it could easily be revived and you'd have completely wine-less Direct3D 9 available. Literally this:

gcc -o d3dtest d3dtest.c -ld3d9 -lX11
./d3dtest

The only difference was the entrance points (a technicality if you ask me) because it was easier and mirrored GLX in a lot of ways. Here's an example program:

#include <d3d9xlib.h>
#include <stdio.h>

Display *g_dpy;
IDirect3D9 *g_d3d9;

const D3DFORMAT fb_formats[] = {
    D3DFMT_A2R10G10B10,
    D3DFMT_X8R8G8B8,
    D3DFMT_X1R5G5B5,
    D3DFMT_R5G6B5
};

const char *
d3dformat_to_string( D3DFORMAT fmt )
{
    switch (fmt) {
        case D3DFMT_A2R10G10B10: return "D3DFMT_A2R10G10B10";
        case D3DFMT_X8R8G8B8: return "D3DFMT_X8R8G8B8";
        case D3DFMT_X1R5G5B5: return "D3DFMT_X1R5G5B5";
        case D3DFMT_R5G6B5: return "D3DFMT_R5G6B5";
        default:
            return "Unknown";
    }
}

void
print_mode_info( UINT adapter,
                 UINT mode,
                 D3DFORMAT format )
{
    D3DDISPLAYMODE modeinfo;
    HRESULT hr;

    hr = IDirect3D9_EnumAdapterModes(g_d3d9, adapter, format, mode, &modeinfo);
    if (FAILED(hr)) {
        printf("| | ERROR 0x%08x: Unable to query mode info %u on adapter %u\n",
               hr, mode, adapter);
        return;
    }

    printf("| | %ux%u @ %uHz\n",
           modeinfo.Width, modeinfo.Height, modeinfo.RefreshRate);
}

void
print_adapter_info( UINT adapter )
{
    D3DADAPTER_IDENTIFIER9 ident;
    HRESULT hr;
    UINT modecount;
    unsigned i, j;
    const char *os, *runtime;

    hr = IDirect3D9_GetAdapterIdentifier(g_d3d9, adapter, 0, &ident);
    if (FAILED(hr)) {
        printf("ERROR 0x%08x: Unable to query adapter %u\n", hr, adapter);
        return;
    }

    switch ((ident.DriverVersionHighPart >> 16) & 0xFFFF) {
        case 4: os = "Windows 95/98/NT4"; break;
        case 5: os = "Windows 2000"; break;
        case 6: os = "Windows 2000/XP"; break;
        case 7: os = "Windows Vista"; break;
        case 8: os = "Windows 7"; break;
        default:
            os = "Unknown";
    }
    switch (ident.DriverVersionHighPart & 0xFFFF) {
        case 11: runtime = "Direct3D 6"; break;
        case 12: runtime = "Direct3D 7"; break;
        case 13: runtime = "Direct3D 8"; break;
        case 14: runtime = "Direct3D 9"; break;
        case 15: runtime = "Direct3D 10"; break;
        case 16: runtime = "Direct3D 10.1"; break;
        case 17: runtime = "Direct3D 11"; break;
        default:
            runtime = "Unknown";
    }

    printf("Adapter %u:\n"
           "| Driver: %s\n"
           "| Description: %s\n"
           "| DeviceName: %s\n"
           "| DriverVersion:\n"
           "| | OS: %s\n"
           "| | Runtime: %s\n"
           "| | Version: %u\n"
           "| | Build: %u\n"
           "| VendorId: 0x%x\n"
           "| DeviceId: 0x%x\n"
           "| SubSysId: 0x%x\n"
           "| Revision: %u\n"
           "| GUID: {%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X}\n"
           "| WHQL: 0x%08x\n"
           "|\n",
           adapter, ident.Driver, ident.Description, ident.DeviceName, os,
           runtime, (ident.DriverVersionLowPart >> 16) & 0xFFFF,
           ident.DriverVersionLowPart & 0xFFFF, ident.VendorId,
           ident.DeviceId, ident.SubSysId, ident.Revision,
           ident.DeviceIdentifier.Data1, ident.DeviceIdentifier.Data2,
           ident.DeviceIdentifier.Data3,
           ident.DeviceIdentifier.Data4[0], ident.DeviceIdentifier.Data4[1],
           ident.DeviceIdentifier.Data4[2], ident.DeviceIdentifier.Data4[3],
           ident.DeviceIdentifier.Data4[4], ident.DeviceIdentifier.Data4[5],
           ident.DeviceIdentifier.Data4[6], ident.DeviceIdentifier.Data4[7],
           ident.WHQLLevel);

    for (i = 0; i < sizeof(fb_formats)/sizeof(*fb_formats); ++i) {
        printf("| Modes (%s):\n",
               d3dformat_to_string(fb_formats[i]));

        modecount = IDirect3D9_GetAdapterModeCount(g_d3d9, adapter,
                                                   fb_formats[i]);
        if (modecount > 0) {
            for (j = 0; j < modecount; ++j) {
                print_mode_info(adapter, j, fb_formats[i]);
            }
        } else {
            printf("|   None\n");
        }
    }

    {
        D3DDISPLAYMODE cmode;

        printf("| Current Mode:\n");
        hr = IDirect3D9_GetAdapterDisplayMode(g_d3d9, adapter, &cmode);
        if (FAILED(hr)) {
            printf("|   ERROR 0x%08x: Unable to query "
                   "current mode on adapter %u\n", hr, adapter);
        } else {
            printf("|   %ux%u @ %uHz (%s)\n",
                   cmode.Width, cmode.Height, cmode.RefreshRate,
                   d3dformat_to_string(cmode.Format));
        }
    }
}

int
main( int argc,
      char *argv[] )
{
    UINT i, adaptercount;

    g_dpy = XOpenDisplay(NULL);
    if (!g_dpy) { fprintf(stderr, "XOpenDisplay failed!\n"); return 1; }

    g_d3d9 = XDirect3DCreate9(D3D_SDK_VERSION, g_dpy);
    if (!g_d3d9) {
        fprintf(stderr, "XDirect3DCreate9 failed!\n");
        XCloseDisplay(g_dpy);
        return 1;
    }

    adaptercount = IDirect3D9_GetAdapterCount(g_d3d9);
    if (adaptercount == 0) {
        printf("No adapters present on this system.\n");
    }

    for (i = 0; i < adaptercount; ++i) {
        print_adapter_info(i);
        if (i != adaptercount-1) { printf("\n"); }
    }

    IDirect3D9_Release(g_d3d9);
    XCloseDisplay(g_dpy);

    return 0;
}

[Kivada]

I wonder why some don't consider this state tracker "native". The fact it's used on WINE has nothing to do with this support being native or not, but with the fact there are no native apps using D3D. I agree with someone who said it's not a good idea because is a tech dependent on MS, but saying it's not native is wrong. Gallium drivers work based on state trackers, and this D3D9 support is as native as OpenGL 3.0 is.

Because Wine is not native. It's a kludge to appease those that wanted to cling to Windows only software.

Because it will mean that Linux users will be brushed aside completely when they have issues when trying to run these games in a non supported way.

At a time when the fortress that is Direct3D is finally crumbling this is exactly the wrong direction to be moving in.

[mrugiero]

Because Wine is not native. It's a kludge to appease those that wanted to cling to Windows only software.

Because it will mean that Linux users will be brushed aside completely when they have issues when trying to run these games in a non supported way.

At a time when the fortress that is Direct3D is finally crumbling this is exactly the wrong direction to be moving in.

Well, with your criteria OpenGL is not native, because WINE is able to use it.
D3D support is in the driver. What is in WINE is the ability to use it directly, and is mostly there because the author of this support (which is on the driver, i.e., native, you can program an app that uses it without requiring WINE nor winelibs) needed something to test it and since there was no previous native support, there was no native apps using this support. Nobody is suggesting people should consider WINE as the porting, but instead using *native* D3D as a way to make this porting *easier*, because it doesn't imply rewriting the whole graphics code, which in a lot of cases is the most complex part of the program. WINE support is still good for legacy apps that have no hope to get ported, and is good that there is something to get better performance for them.

[Kivada]

Well, with your criteria OpenGL is not native, because WINE is able to use it.
D3D support is in the driver. What is in WINE is the ability to use it directly, and is mostly there because the author of this support (which is on the driver, i.e., native, you can program an app that uses it without requiring WINE nor winelibs) needed something to test it and since there was no previous native support, there was no native apps using this support. Nobody is suggesting people should consider WINE as the porting, but instead using *native* D3D as a way to make this porting *easier*, because it doesn't imply rewriting the whole graphics code, which in a lot of cases is the most complex part of the program. WINE support is still good for legacy apps that have no hope to get ported, and is good that there is something to get better performance for them.

You are an idiot, Wine is a hackjob to force Windows only software to work on non Windows OSs, OpenGL is a core part of every OS that isn't Windows.

Just because you can get D3D to work instead of running the calls through an OpenGL interpreter means squat when you still have to get everything else to work through half working reverse engineered APIs.

It doesn't make porting easier, it makes half assed ports easier. These games will still run more slowly then a real native port.

You want historical proof? OS/2 could run Windows only programs, what happened? Nobody wrote any native software for OS/2, so whenever Microsoft made some changes OS/2 had to catch up. Not having native software meant that heavy lift programs for Windows would also run slower on OS/2.

If there was an equivilent to Wine for OS X only software that would still not be native.

[mrugiero]

You are an idiot, Wine is a hackjob to force Windows only software to work on non Windows OSs, OpenGL is a core part of every OS that isn't Windows.

Just because you can get D3D to work instead of running the calls through an OpenGL interpreter means squat when you still have to get everything else to work through half working reverse engineered APIs.

It doesn't make porting easier, it makes half assed ports easier. These games will still run more slowly then a real native port.

You want historical proof? OS/2 could run Windows only programs, what happened? Nobody wrote any native software for OS/2, so whenever Microsoft made some changes OS/2 had to catch up. Not having native software meant that heavy lift programs for Windows would also run slower on OS/2.

If there was an equivilent to Wine for OS X only software that would still not be native.

I'm probably an idiot, but the D3D state tracker means the support is within the drivers. That's what native means, no hackjob wrapper. You can build something targeting it without either WINE or winelib. It has nothing to do with running Windows apps. The fact it's only used by WINE has nothing to do with the ability to make native apps for Linux using D3D, but with the fact there is none already and the developer needs to test his work.
I never stated running games through WINE with this D3D state tracker is native. I stated the D3D state tracker *only* is native. And it is. I don't care about historical proof on something unrelated to my statement.

EDIT: I agree that it makes half assed ports easiear. Sadly, that's what most companies probably want to do, specially with an underdeveloped market share. As I said already, using an API dependent on someone who wants to destroy Linux is probably not smart. But that doesn't mean it isn't easier. And serious ports can be easier, too.

[duby229]

There is something to be said about making a superior product though. If wine got so good (someday) that it could run windows programs better than windows.... Well then Unix like OSes including Linux, BSD, and even MacOSx would have a serious advantage over Microsoft. Essentially you take an advantage by making their technology trivial.

EDIT: That is why platform Independence is so important for wine.

EDIT2: Let us imagine a hypothetical future. One where Gallium3D gets ported to BSD, OpenSolaris, Haiku, MacOSx, whatever... At that point in time I would then say that this patch should get accepted upstream by the wine devs. Until then however it is too platform dependent.

[mrugiero]

There is something to be said about making a superior product though. If wine got so good (someday) that it could run windows programs better than windows.... Well then Unix like OSes including Linux, BSD, and even MacOSx would have a serious advantage over Microsoft. Essentially you take an advantage by making their technology trivial.

EDIT: That is why platform Independence is so important for wine.

EDIT2: Let us imagine a hypothetical future. One where Gallium3D gets ported to BSD, OpenSolaris, Haiku, MacOSx, whatever... At that point in time I would then say that this patch should get accepted upstream by the wine devs. Until then however it is too platform dependent.

If this support is isolated enough (within the code, I mean), a build-time switch might fix the possible drawbacks of having this platform specific support. If not, I agree fully with you, since it could affect, for example, Mac or BSD users which gains nothing from this patch.

[zhasha]

Let us imagine a hypothetical future. One where Gallium3D gets ported to BSD, OpenSolaris, Haiku, MacOSx, whatever... At that point in time I would then say that this patch should get accepted upstream by the wine devs. Until then however it is too platform dependent.

Two can play at that game: winemac.drv is too platform specific (OS X only, and they even support X11!). It should be removed from wine immediately.

When it lives next to wined3d and is switchable by a registry key AND it falls back to wined3d in case of error AND the underlying architecture has already seen preliminary ports to BSD, Haiku and even Windows, how then, pray tell, is it too platform dependent?

[duby229]

Two can play at that game: winemac.drv is too platform specific (OS X only, and they even support X11!). It should be removed from wine immediately.

When it lives next to wined3d and is switchable by a registry key AND it falls back to wined3d in case of error AND the underlying architecture has already seen preliminary ports to BSD, Haiku and even Windows, how then, pray tell, is it too platform dependent?

Your work is fantastic. This code is OSS. It's so good in fact that I'm certain someone will maintain a patchset. I'm convinced that it will still be available regardless of if it gets accepted upstream or not.

[Ramiliez]

Two can play at that game: winemac.drv is too platform specific (OS X only, and they even support X11!). It should be removed from wine immediately.

When it lives next to wined3d and is switchable by a registry key AND it falls back to wined3d in case of error AND the underlying architecture has already seen preliminary ports to BSD, Haiku and even Windows, how then, pray tell, is it too platform dependent?

Im afraid that your work wont be accepted to Wine
If they reject it you could try to convince distro maintainers who do not engage in politics to include your D3D support as package
You could try Sabayon they even include winetricks and Skype in their base repos.