Announcement

Collapse
No announcement yet.

Gallium3D Direct3D 9 For Wine Revived, Again

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dukenukemx
    replied
    Originally posted by tuubi View Post
    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?

    Leave a comment:


  • tuubi
    replied
    Originally posted by Dukenukemx View Post
    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.

    Leave a comment:


  • Dukenukemx
    replied
    Originally posted by s_j_newbury View Post
    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.
    Originally posted by profoundWHALE View Post
    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.

    Leave a comment:


  • profoundWHALE
    replied
    Originally posted by Dukenukemx View Post
    Maybe who ever is responsible for this PPA can add support for the DX9 state stracker? Oibaf drivers are very popular, so maybe he can add the DX9 state tracker to his drivers?



    There are three methods for running Direct3D games in Wine.

    1) Current stable method, which is a slow D3D -> OpenGL process.
    2) New D3D which isn't implemented yet into Wine, but basically multi-threads D3D-> OpenGL for a huge speed boost.
    3) Use a state tracker which actually gives native DX9 to Open Source drivers. Would be the fastest method since there's no conversion process of D3D->OpenGL, and would experience less bugs.

    Christoph Bumiller of Nouveau originally developed the DX9 state tracker, and got it damn near working perfectly, including even in wine. It was shrugged off and forgotten, or at least we thought until okias revived it, and it apparently kicks ass. But this only works with Open Source drivers, and not even the Intel open source driver. Just Gallium3D and Nouveau drivers.

    As for legal issues with Microsoft, there isn't any, at least not yet. Nobody knows if implementing a native DX9 state tracker is breaking any laws, but nobody wants to incur the wrath of Microsoft. Even if it's not illegal, nobody wants to spend the legal fees to fend them off. Too much of a grey area.

    But it's probably not the main reason you won't see this in Wine. Their reasoning is that it's too much extra work for something only a few will be able to use. Even though Intel graphic cards aren't really for gaming, and AMD open source drivers are nearly as good as proprietary. The exception is Nvidia where the proprietary is really really good.
    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.

    Leave a comment:


  • s_j_newbury
    replied
    Originally posted by Dukenukemx View Post
    Maybe who ever is responsible for this PPA can add support for the DX9 state stracker? Oibaf drivers are very popular, so maybe he can add the DX9 state tracker to his drivers?



    There are three methods for running Direct3D games in Wine.

    1) Current stable method, which is a slow D3D -> OpenGL process.
    2) New D3D which isn't implemented yet into Wine, but basically multi-threads D3D-> OpenGL for a huge speed boost.
    3) Use a state tracker which actually gives native DX9 to Open Source drivers. Would be the fastest method since there's no conversion process of D3D->OpenGL, and would experience less bugs.

    Christoph Bumiller of Nouveau originally developed the DX9 state tracker, and got it damn near working perfectly, including even in wine. It was shrugged off and forgotten, or at least we thought until okias revived it, and it apparently kicks ass. But this only works with Open Source drivers, and not even the Intel open source driver. Just Gallium3D and Nouveau drivers.
    Nouveau is Gallium3D. I'm working on getting it going on Intel too, utilising the ilo Gallium3D driver. (Yes, this should work even while using the Classic i965 DRI driver since gallium-nine uses the gallium pipe-loader which works the same way as the EGL driver - which you can select at run-time with EGL_DRIVER)

    As for legal issues with Microsoft, there isn't any, at least not yet. Nobody knows if implementing a native DX9 state tracker is breaking any laws, but nobody wants to incur the wrath of Microsoft. Even if it's not illegal, nobody wants to spend the legal fees to fend them off. Too much of a grey area.

    But it's probably not the main reason you won't see this in Wine. Their reasoning is that it's too much extra work for something only a few will be able to use. Even though Intel graphic cards aren't really for gaming, and AMD open source drivers are nearly as good as proprietary. The exception is Nvidia where the proprietary is really really good.
    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...

    Leave a comment:


  • andrebrait
    replied
    Would be possible to implement the state tracker in non-Gallium3D drivers?

    Leave a comment:


  • zanny
    replied
    I thought there was some under-developed gallium3d Intel driver too, but Intel didn't want to play ball with their competitions tech since it was NIH, and in their defense at the time Gallium blew chunks compared to their own stack.

    Leave a comment:


  • Dukenukemx
    replied
    Originally posted by dh04000 View Post
    We need a hero(someone with both the skills and drive) to set up and make this a reality and write the patch and spin a modified version of Wine in a ppa/repository for people to try.
    Maybe who ever is responsible for this PPA can add support for the DX9 state stracker? Oibaf drivers are very popular, so maybe he can add the DX9 state tracker to his drivers?

    Originally posted by profoundWHALE View Post
    I'm a little late to the party and not well informed on wine, but lets see if I have this right.

    - When I install and run a game under wine, it basically translates directx to opengl.
    - This patch would enable native directx runtime, meaning no overhead but...
    - Licensing issues if Microsoft wants to be... well, Microsoft and screw everyone over

    If all of the above is true, would we not be able to say:
    1) Install a game through wine
    2) This patch thingy would be used to translate Directx straight to OpenGL
    3) No need for Directx emulation after that

    Or am I dreaming? Because it'd be a powerful tool for anyone who wants to port a Windows game to Linux. Run it through this system once for a working example, and then they would only need about a month for full optimization. (depending on the team size) And sorry for my poor knowledge of terms and such.
    There are three methods for running Direct3D games in Wine.

    1) Current stable method, which is a slow D3D -> OpenGL process.
    2) New D3D which isn't implemented yet into Wine, but basically multi-threads D3D-> OpenGL for a huge speed boost.
    3) Use a state tracker which actually gives native DX9 to Open Source drivers. Would be the fastest method since there's no conversion process of D3D->OpenGL, and would experience less bugs.

    Christoph Bumiller of Nouveau originally developed the DX9 state tracker, and got it damn near working perfectly, including even in wine. It was shrugged off and forgotten, or at least we thought until okias revived it, and it apparently kicks ass. But this only works with Open Source drivers, and not even the Intel open source driver. Just Gallium3D and Nouveau drivers.

    As for legal issues with Microsoft, there isn't any, at least not yet. Nobody knows if implementing a native DX9 state tracker is breaking any laws, but nobody wants to incur the wrath of Microsoft. Even if it's not illegal, nobody wants to spend the legal fees to fend them off. Too much of a grey area.

    But it's probably not the main reason you won't see this in Wine. Their reasoning is that it's too much extra work for something only a few will be able to use. Even though Intel graphic cards aren't really for gaming, and AMD open source drivers are nearly as good as proprietary. The exception is Nvidia where the proprietary is really really good.

    Leave a comment:


  • profoundWHALE
    replied
    I'm a little late to the party and not well informed on wine, but lets see if I have this right.

    - When I install and run a game under wine, it basically translates directx to opengl.
    - This patch would enable native directx runtime, meaning no overhead but...
    - Licensing issues if Microsoft wants to be... well, Microsoft and screw everyone over

    If all of the above is true, would we not be able to say:
    1) Install a game through wine
    2) This patch thingy would be used to translate Directx straight to OpenGL
    3) No need for Directx emulation after that

    Or am I dreaming? Because it'd be a powerful tool for anyone who wants to port a Windows game to Linux. Run it through this system once for a working example, and then they would only need about a month for full optimization. (depending on the team size) And sorry for my poor knowledge of terms and such.

    Leave a comment:


  • dh04000
    replied
    Originally posted by Dukenukemx View Post
    The problem isn't technical, but more political. We know the D3D9 state tracker can be faster and more stable, but isn't implemented because of cross compatibility with MacOSX and non Gallium3D based drivers. But at this point I think a simple patch for Mesa and Wine is enough. If enough people use it, then Wine developers may change their minds and mainline it.
    We need a hero(someone with both the skills and drive) to set up and make this a reality and write the patch and spin a modified version of Wine in a ppa/repository for people to try.

    Leave a comment:

Working...
X