Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Gallium3D's Direct3D 10/11 State Tracker To Be Nuked

  1. #1
    Join Date
    Jan 2007
    Posts
    15,108

    Default Gallium3D's Direct3D 10/11 State Tracker To Be Nuked

    Phoronix: Gallium3D's Direct3D 10/11 State Tracker To Be Nuked

    The Direct3D state tracker for Gallium3D that for a short time provided hope of a native Direct3D implementation for Linux of the Microsoft Direct3D 10/11 APIs without simply being a translator layer to OpenGL, is set to be nuked from mainline Mesa...

    http://www.phoronix.com/vr.php?view=MTMyNDU

  2. #2

    Unhappy

    That's beyond sad - a code which allowed to run Direct3D code natively has been purged.

    Damn.

    And Wine doesn't quite support Direct3D 10 yet.

    Damn.

  3. #3
    Join Date
    Mar 2012
    Posts
    123

    Default

    I'm guessing Gallium-based D3D1X can't be used on intel graphics, and you know why wine developers don't want it.

  4. #4
    Join Date
    Mar 2013
    Posts
    1

    Default

    I agree, this is sad... so why not do something about it? Phoronix could organize an Indiegogo campaign to fund development for a few months. I'd be surprised if nobody with the required knowledge was willing to dedicate some time to this if they could be paid.

  5. #5
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by tadpole View Post
    I agree, this is sad... so why not do something about it? Phoronix could organize an Indiegogo campaign to fund development for a few months. I'd be surprised if nobody with the required knowledge was willing to dedicate some time to this if they could be paid.
    The problem isn't a few months, it's ongoing maintenance over the long run.

    Whenever someone changes the gallium interface, build system, or other misc. large changes, they have to go in and fix up this state tracker, and no one really knows much about it or tests to make sure they aren't breaking it. And since no one is really using it, removing the code makes sense. If someone had the time to maintain it in the long term, it would stay. Paying someone to do that for a few months won't fix anything though.

  6. #6
    Join Date
    Jul 2012
    Posts
    627

    Default

    I's indeed VERY sad that project ends this way...

    ...and indeed, WINE is far far away to even support Dx10....only a very limited set of functions are supported (IIRC) and in practice, it can't run any Dx10 game, not to mention Dx11.

  7. #7
    Join Date
    Sep 2010
    Posts
    55

    Default

    The reason it has died is because Wine developers didn't wanted it. IMHO it should have been the way Direct3D support should have been implanted from the start (it's a graphic API as OpenGL, as such it belongs there). Afterward the rest of DirectX API could have been implanted aside and enabled developers to compile DirectX game with less porting effort. I don't quite know why such a project didn't picked up more steam. It is some kind of OpenGL protectionism? Or maybe Wine developers think this would have split Windows-emulation effort on Linux and didn't see this as a good thing? I don't know. There is hostility against implementing Microsoft technologies on Linux. Quite sad I think. Anything that can bring more native game to Linux is good.

  8. #8
    Join Date
    Dec 2011
    Posts
    2,103

    Default

    Could have been useful for people with Direct3D experience, coming to Linux and wants to keep on play with it.
    Or people who use Linux but wants to learn Direct3D, or people who maybe works with Direct3D as their job, but personally prefer to use Linux.

    Would have been pretty cool to have a Direct3D implementation even if its just Direct3D and not DirectX.

  9. #9

    Default

    I see this as nothing lost. The last thing we need is for all new games that come to Linux is for them to be wrapped in Wine to make them half functional.

    Games need to be ported native or not at all. Don't believe me? Go ask the Mac users how "great" Cider(based on Cedega) has been for Mac gaming.

  10. #10
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    The only problem that I've been having with wine using the oss radeon driver has been that directx games have been too slow to be playable. Besides that everything seems really good with wine. I think if it was able to natively render directx this performance probl;em wouldnt exist. Think of it like this, if the oss driver stack doesnt have the functionality to properly support a native directx renderer, how much worse is it to tranlate into opengl and then render? If the stack doesnt have the capability of properly supporting directx, then what kind of hackish crap must wines translation be doing to make an opengl representation?

    For those directx capabilities that are unsupported by the stack, how are they translated into opengl? Unsupported capability is unsupported capability...

    The solution here is not this hackish crap that wine is trying to do... The solution is to add the capability to the stack that is required for a native directx implementation to function properly.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •