Announcement

Collapse
No announcement yet.

Open Source 3D stacks and WINE

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

  • Open Source 3D stacks and WINE

    As anyone who uses WINE to run Windows games and other 3D applications must be acutely aware of, WINE's Direct3D reimplementation is not even close to fully functional on any OpenGL stack other than NVidia's proprietary driver. A large number of games and apps simply refuse to run on any 3D stack but NVidia's; many others need the user to disable application features (lowering detail levels, forcing the app to use a lower version of D3D, etc.) not merely for performance reasons but to get the application to run (or at least display correct graphics) at all.

    My question is, what work, if any, is being done between the driver developers and the WINE developers to improve this situation? I realize that the open source ATI 3D stack is very much a work in progress right now, but frankly I don't expect things to improve even after Radeon 3D support is "finished" and the stack supports OpenGL 2.1 or 3.0. After all, the proprietary ATI driver and (I believe) the open source Intel driver both support OpenGL 2.0 or higher, and yet WINE isn't any more functional on them (in fact, in some cases even less functional) than on the open source ATI stack. Are the driver developers aware of what NVIdia-specific OpenGL extensions or other functionality WINE is relying on and planning to implement them? Are the WINE developers aware of cases where their code is overly dependent on NVidia specifics (e.g. relying on behaviour undefined by the OpenGL specifications that happens to work a specific way on NVidia) such that they, or some interested external contributor, can try to remedy it?

  • #2
    Probably never. Open source drivers simply do not exist as far as WINE devs. are concerned, and ATI binaries are the devil .
    But serious for a bit, I think work is being done to move WINE is a more "general" direction when it comes to drivers.

    Comment


    • #3
      Originally posted by Alex W. Jackson View Post
      I realize that the open source ATI 3D stack is very much a work in progress right now, but frankly I don't expect things to improve even after Radeon 3D support is "finished" and the stack supports OpenGL 2.1 or 3.0.
      I do
      Originally posted by Alex W. Jackson View Post
      After all, the proprietary ATI driver and (I believe) the open source Intel driver both support OpenGL 2.0 or higher, and yet WINE isn't any more functional on them (in fact, in some cases even less functional) than on the open source ATI stack.
      You probably do have noticed that fglrx is not so to say bug-free? There's some issues that are caused by Wine-side things but plenty more that are caused by bugs in the driver. To be frank, nVidia just (still) happens to have the drivers that have the best combination of being feature complete and bug free. I'm pretty sure the situation will start unraveling for ATi users with Gallium and it might be that ATi now manages to make stable proprietary drivers for users with new cards that they dropped so much of the codebase for old cards.
      Originally posted by Alex W. Jackson View Post
      Are the driver developers aware of what NVIdia-specific OpenGL extensions or other functionality WINE is relying on and planning to implement them?
      Afaik Wine doesn't need anything that's literally nVidia-specific. It's just that those generic extensions to OpenGL 2.1 tend to be well supported by nVidia, buggy or slow on fglrx and non-existent (for still a while) on open drivers. It doesn't mean they wouldn't be needed for games.

      Comment


      • #4
        I think there are a few issues here :

        1. Wine was originally written on NVidia cards and made some design decisions based on the internal implementation of the NVidia driver, which causes problems on any other driver even if the OpenGL implementation of those other drivers is 100% correct. The NVidia-specific aspects of Wine are being taken out over time, but it does take time.

        2. Wine relies on a number of OpenGL functions which no other app in the world seems to use, not even compliance test suites. Nothing wrong with that (although it`s a pain in the butt), however it means that Wine relies on some of the least tested and least-exercised parts of the driver. Again, this just takes time - as OpenGL bugs are found we fix them, but identifying the specific OpenGL issues is the time-consuming part. This is a relatively small part of the problem as far as I can see, and I believe workarounds are in place for the open issues.

        3. Wine relies on Windows-only extensions being present in the X implementation.
        Test signature

        Comment


        • #5
          Thanks for the informative replies. I've got another question.

          I recall reading (possibly in the comments under a Wine bugzilla entry) that the reason Wine typically requires a more advanced GPU to run the same application than Windows (e.g. even with a driver that does everything the way Wine likes, you need a D3D10-level card to fully emulate D3D9) is because Wine has to do things like add additional instructions to shaders to translate differences between OpenGL and D3D in, for example, how texture coordinates are interpreted.

          Now I've looked at the register documents AMD has released, and also at some Intel GPU register documents, and I've noticed that there are register bits all over the place specifying "D3D mode" or "OpenGL mode" for things like texture coordinates and whatever else differs between the two APIs. My question is, instead of WINE doing the "translating" from D3D to OpenGL, would it not make more sense to define some OpenGL extensions like "MESA_texcoords_like_that_other_api", and have the driver simply set the appropriate register to switch the card into "D3D mode" when an application uses those extensions.

          I imagine such extensions wouldn't be useful for anything other than WINE, and so it wouldn't be worth the engineering effort for the proprietary driver developers to specify and implement them (plus it might antagonize Microsoft) but that should be a golden opportunity to showcase the strength of open source development. Has anyone from Mesa (figuratively) sat down with the Wine D3D developers and asked "if you could ask for any completely new OpenGL extensions you wanted, specifically for the purpose of translating from D3D to OpenGL, what would you ask for?"

          Comment


          • #6
            One imagines that it may even be possibly (with a LOT of work) to implement something very close to Direct3D over Gallium with the proper hardware acceleration modes, giving Wine better acceleration and giving us an API that makes porting Windows 3D apps to Linux much easier.

            Comment


            • #7
              Sounds like a good idea :-)

              Comment


              • #8
                It seems to me that it would take a lot less work to encapsulate just the awkward low-level differences between D3D and OpenGL into OpenGL extensions, rather than write a complete bottom-to-top reimplementation of D3D. Especially when we already have an implementation of the "top half" of D3D in Wine, that takes care of all the pervasive Windows-isms in that API like COM, etc. Why do all that work again?

                Comment


                • #9
                  We would need to hear from the Wine developers to be sure, but my guess is that many of the OGL to D3D differences are being ignored without any real problems.
                  Test signature

                  Comment


                  • #10
                    Hmm, I'm sure I remember reading an explanation that "[some big-name D3D9 game] needs a GF8 in Wine because Wine needs to add instructions to its shaders to work around the differences between D3D and OGL".

                    Comment

                    Working...
                    X