Announcement

Collapse
No announcement yet.

Gallium3D Direct3D 9 For Wine Revived, Again

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

  • #31
    Originally posted by werfu View Post
    But at the same time, it's hot, it's new, it has the potential to bring a lot more Wine usage and could even live outside if a modular architecture get in place. I'd love to see both the DX9 and the DX10/11 tracker thrive and enable Linux gaming a lot more. Hell, one could even wrap what's left of DirectX and enable near recompiling porting of commercial games. Suddenly all hell'd break loose and the SteamOS could offer 100% of their catalog (yeah I'm dreaming, but why not).
    The problem is that the directx binaries on Windows have become the most wart ridden messes of unexplained undocumented behavior implementing the api intuitively means almost nothing works.

    Microsoft had the habit (and still does) of patching Windows to fix bugs in games. Device vendors do this a lot too, it is why many AAA titles require day-one gpu drivers from AMD / Nvidia.

    Wine is so huge, in part, because it has to find and implement all the bugs in directx beyond just the functionality. And even a dx9 state tracker would have to do the same, because directx isn't an API, it is an implementation - and as a developer, conforming to implementations makes me want to perform ritual sacrifice of goats.

    Comment


    • #32
      Originally posted by werfu View Post
      Wine is one hell of an old open source project. It's been around for ages! I remember using it on my 486 with one of the first 2.4 kernel. Wine developers are proud. It took an incredible amount of work to get to 1.0, and while everybody though it was foolish to develop such a layer, they've continued. If I put myself in place of the Wine developers, I can easily understand how I could refuse to add such functionality. It's been developed by someone who's external to the team, replace a complete subset that took a LOT of work to put in place in the first place and opens up a possibility of new bugs. Not only that, but it would only benefit a small fraction of users and would be dedicated to Linux (and FreeBSD when the tracker gets ported). So, yeah, I understand them.

      But at the same time, it's hot, it's new, it has the potential to bring a lot more Wine usage and could even live outside if a modular architecture get in place. I'd love to see both the DX9 and the DX10/11 tracker thrive and enable Linux gaming a lot more. Hell, one could even wrap what's left of DirectX and enable near recompiling porting of commercial games. Suddenly all hell'd break loose and the SteamOS could offer 100% of their catalog (yeah I'm dreaming, but why not).
      Wine developers is amazing, working year after year, i follow wine since 1.1.21 on games and since this times wine had big progress as, DX9c begins works, ATI/AMD support begins show shader model 3 games, sound work for example: virtua tennis 3 and many others, wmv support on ford racing games (without wine tricks): this appear around wine 1.7.3, installation net framework 3.5 and 4 (without wine tricks but requires on complied wine dont install mono for works) and other many changes in various areas

      Resuming thanks for all wine developers and waiting for your future works



      Comment


      • #33
        Originally posted by ChrisXY View Post
        Speaking of radeonsi, does this work on it/will it work?
        No reason I can see that it wouldn't, so long as it's using an up-to-date Mesa stack. As this state tracker looks to be Mesa 10 I would imagine that you would get everything you get from Mesa 10 (including all radeonsi improvements) plus the D3D9 st.

        Comment


        • #34
          Originally posted by pinguinpc View Post
          ...Seriously if you want use wine, NVIDIA with privative drivers is your only option but AMD Opensource driver gains compatibility but performance is low and privative gain performance but loss compatibility but nvidia privative drivers have more performance and compatibility

          Are you trying to make a point, or promote NVIDIA's proprietary driver? I fail to see any reason for the latter in this thread...

          My only problem with fglrx and Wine was Guild Wars 2 and osu!, and both seem to work great for me now. On radeonsi, both games also worked, but were slightly slower. Can't say I care how they perform on NVIDIA since I don't own such hardware (and won't for political reasons). But giving the impression Wine is next to useless on AMD in-comparison to NVIDIA just isn't true.

          Comment


          • #35
            Originally posted by Gusar View Post
            Look who's talking.

            You seem to think maintenance is just adding a few lines of code. You're completely missing the entire end-user support system that you also have to maintain when you distribute software - writing documentation, bug triaging, etc. You're also missing the QA burden - if wine devs incorporate support for the d3d tracker, then they have to test everything with both the tracker and the standard wine stack. Furthermore, when the devs make changes, they have to think how those changes might affect either the standard stack or the tracker and potentially change the tracker-related code, which consumes both time and brain power.

            There's is nothing whatsoever political about either of these, they're all practical, *real* burdens that get imposed on devs when they take a piece of code. So when you say "requires almost no maintainance", you're flat-out wrong. Adding a piece of code might be easy, but that's just one small part of maintenance. You're free to prove otherwise, but that will require more than just making big unverified assumptions and accusing people of lying.
            LOL. Yeah rite... So Wine has to do all these things? Maybe they need to hire more people for their marketing division based on this patch? Maybe they need more salesmen? Gosh, the burden...

            I can't take you seriously. You see, unlike you, i am a pro programmer... And i know lies when i see them...

            Comment


            • #36
              Originally posted by zxy_thf View Post
              It's possible that they simply don't want to do QA on this patch.
              You know you need to test games with dx9 tracker once more.
              Anyway I think it's time to branch, as the wine team clearly has to balance different platforms while we - at least me - only want a faster wine under Linux.
              They don't have to. Anyway, it is not like the do stellar QA for the rest of Wine...

              But, they don't have to enable it by default. They can just accept it, provide a compile time option, and let the community maintain it. But of course, that can't happen on an "open source" project, right?

              Comment


              • #37
                Originally posted by justmy2cents View Post
                i'm a developer my self and i know i would do the same as wine developers. usually so called maintainers disappear and whole maintaining falls on developers who were never interested in that
                they get exceeding bug noise, since common user won't know whom to contact to report it.

                it is open source. if you don't like something you can
                - stop using it
                - search alternative
                - fork, patch and maintain that codebase. if you're right ppl will pick it up. just look at MATE. when ppl 1st heard that one single guy will fork gnome 2... everybody laughed. now look at it. don't be a whining ass, have the balls to do it or shut up and crawl into your hole

                how much did you pay wine developers so far to feel so entitled that developers must work extra work for you?
                So let me get this straight: If i have not given money to the developers, i am not allowed to review their product and criticize their decisions? Especially an "opensource" product? SERIOUSLY? I don't know if you are a developer, but you don't seem too bright to me...

                I never said i don't like Wine in general. I don't like the attitude of Crossover employees... That is my right, and i can express it since we are not in N. Korea...

                Their decision is purely based on the fact that most of their money come from Mac users. I am willing to bet Linux users don't usually pay for Crossover... That is the reason they don't want Linux specific enhancements. There is no technical reason, this patch is so simple. If it was complicated, i might have accepted their argument. But is is so simple...

                PS: They won't get that much "bug noise" from supporting the d3d9 state tracker. They don't have to enable it in Crossover. They can let it as an unsupported Linux compile time feature...

                Comment


                • #38
                  Originally posted by TemplarGR View Post
                  So let me get this straight: If i have not given money to the developers, i am not allowed to review their product and criticize their decisions? Especially an "opensource" product? SERIOUSLY? I don't know if you are a developer, but you don't seem too bright to me...

                  I never said i don't like Wine in general. I don't like the attitude of Crossover employees... That is my right, and i can express it since we are not in N. Korea...

                  Their decision is purely based on the fact that most of their money come from Mac users. I am willing to bet Linux users don't usually pay for Crossover... That is the reason they don't want Linux specific enhancements. There is no technical reason, this patch is so simple. If it was complicated, i might have accepted their argument. But is is so simple...

                  PS: They won't get that much "bug noise" from supporting the d3d9 state tracker. They don't have to enable it in Crossover. They can let it as an unsupported Linux compile time feature...
                  criticize? yea, you can. that is your basic right. same as developers have the right of choice... or don't they? you damn sure fight for your rights, but deny basic right to others. right of choice is most basic part of OSS. but, what you're doing is not criticizing. example, "wine developers LIED...", i mean how can you lie that you don't like something and don't plan on supporting it? it was a CHOICE, not a CLAIM and AFAIK choice cannot be lie. same for your comment, is not criticism, it is a claim

                  oss project rejecting inclusion? never happens... or does it? look at kernel. they will flat out reject inclusion if it doesn't fit in their plan or structure, their agreed writing style...

                  in OSS both developer and user are right. but
                  - developer has the right to decide on not accepting some solution into their project or take another direction
                  - user has the right to say screw them, fork and prove them wrong

                  not much noise? let's see http://appdb.winehq.org/objectManage...tion&iId=13667
                  right now it is pretty decent and clean how versions work. imagine all this duplicated since it might run for someone with tracker and not for someone without. why would they need to go trough that if they don't want it? and this never happens, i guess http://www.phoronix.com/scan.php?pag...tem&px=MTMyNDU

                  even if you leave it outside.of crossover people usually simply write "wine appname" in google. now, go figure what articles one will saw. some random templargr bragging it works x fps. imagine the surprise when he installs it just to realize it doesn't work. what will they do the 1st thing... flood the wine support

                  keeping side project outside wine, where you simply take each tarball and release with patches would be painless, not require any work (your words, not mine). that's how distros do binary blobs for example

                  Comment


                  • #39
                    Originally posted by TemplarGR View Post
                    i am not allowed to review their product and criticize their decisions?
                    You're not "criticizing their decisions". You're making demands, you're throwing out accusations, hefty ones at that (they're "lying", seriously?), you're claiming they have an agenda, you're also throwing out insults and cheap shots at other forum participants, and you're doing it all with a really stinky attitude. All the while proclaiming how trivial supporting the tracker would be.

                    You're a "pro programmer", *show* me how trivial it would be! Why do you refuse? With one supposedly easy gesture you could shoot down my arguments completely. Why do you not take that chance? Well, the answer is obvious.

                    Comment


                    • #40
                      Originally posted by werfu View Post
                      Not only that, but it would only benefit a small fraction of users and would be dedicated to Linux (and FreeBSD when the tracker gets ported). So, yeah, I understand them.
                      Lol, you do realise the main users of Wine are Linux users, right?

                      And if adding something that "only the minority of Linux users will be able to use" is bad, then why did the Wine devs add that OSX specific X11 replacement some time ago?

                      Face it, it's all ego issue. Someone developed something such that the whole DX-GL translation layer can now be obsoleted, but the old Wine devs, who think more about their legacy than the actual benefit of users, want to keep this layer and reject any alternatives, even if they are clearly superior.

                      Comment


                      • #41
                        WINE is free Winapi implementation, not free Directx implementation.

                        As such, I see no problem with Dx state tracker usage over Gallium, skipping whole Dx-OpenGL overhead and plugging directly into graphics driver.


                        But also remember, how Microsoft has suspended OpenGL? In Dx versions 1-3, the OpenGL was plugged into Dx HAL, not into driver level. So GL performance will always be lower than raw Dx intermediate solely due to the overhead translation.
                        By skipping the overhead of GL-Dx translation, Wine could gain really good performance on machines with Gallium available.


                        But then, the Dx redistributables are required to be installed into Wine userspace.
                        MS can easily create a method to block such usage, because using Dx as of EULA, apart from prohibiting reverse engineering, allows MS to reserve rights in the future. As such it can easily block the usage of the module by disallowing its installation and usage outside of ms-certified environments.


                        I think we have exactly the same situation as with Reiser.
                        In either case, the patches are better off maintained externally for some time to prevent the case of suddenly disappearing developer.
                        They could also be useful to measure the OpenGL-Dx translation overhead!

                        Comment


                        • #42
                          Originally posted by Espionage724 View Post
                          Are you trying to make a point, or promote NVIDIA's proprietary driver? I fail to see any reason for the latter in this thread...

                          My only problem with fglrx and Wine was Guild Wars 2 and osu!, and both seem to work great for me now. On radeonsi, both games also worked, but were slightly slower. Can't say I care how they perform on NVIDIA since I don't own such hardware (and won't for political reasons). But giving the impression Wine is next to useless on AMD in-comparison to NVIDIA just isn't true.
                          The point is nvidia privative driver driver offer much performance and compatibility than AMD/ATI, this situation can consulted on wineappdb for many apps

                          AMD/ATI can be used but have more problems with wine than nvidia, compatibility much reduced, performance much reduced and this situation not change in short time because only free information (lack of GCN hardware information compared to privative) not solve, AMD must be compromise more seriously (resources) with opensource community especially

                          A major problem in games especially is, in mayor part of games of 2012 and before appears (Nvidia meant be to played) this is a serious problem, and that situation have since 10 years


                          I can test some titles since 2009 on my blog (I testing both hardware)

                          http://gamesonwine.blogspot.com

                          or on my youtube channel

                          https://www.youtube.com/user/mrdeathjr28



                          Comment


                          • #43
                            Originally posted by TemplarGR View Post
                            As for me creating a fork of Wine with the d3d9 tracker support, because that is what you are suggesting, it is quite a stupid proposal. There is absolutely no need for that. You shouldn't create a fork just to use a patchset. If a distro wants the d3d9 state tracker, it can enable it. The problem is that this won't lead to its universal use and as such interest in improving the d3d9 state tracker will dissappear, just as it happened with the d3d10/11 state tracker.
                            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.

                            Comment


                            • #44
                              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.

                              Comment


                              • #45
                                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.

                                Comment

                                Working...
                                X