Announcement

Collapse
No announcement yet.

Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

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

  • Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

    Phoronix: Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

    Recent releases of Wine have tackled Direct3D improvements among other enhancements in this popular free software project and Wine 1.1.43 has been released this afternoon to offer up more Direct3D love...

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

  • #2
    Geez. End of year linux's are going to have some very nice wine packages.

    Comment


    • #3
      Originally posted by Hephasteus View Post
      Geez. End of year linux's are going to have some very nice wine packages.
      wine do not support the radeon opensource driver (mesa7.7/7.8)

      "wined3d: Don't use GLSL if the supported version isn't at least 1.20. "

      yes very nice wine packages... (ironic)

      Comment


      • #4
        Originally posted by Qaridarium View Post
        wine do not support the radeon opensource driver (mesa7.7/7.8)

        "wined3d: Don't use GLSL if the supported version isn't at least 1.20. "

        yes very nice wine packages... (ironic)
        Well yeah, we use GLSL 1.20 features. It would be unfortunate if we tried to use GLSL 1.20 shaders when the driver doesn't actually support those.

        Comment


        • #5
          Do you happen to know if you need essentially all of GLSL 1.20 or are there one or two specific things you use ? I don't have the list in front of me but I seem to remember 1.20 being a good mix of "pretty easy" and "probably hard" features...

          (hoping you use the "pretty easy" ones obviously )

          Comment


          • #6
            Actually the 1.10 -> 1.20 differences that I understand don't look too bad for the driver...

            EDIT - while searching I also found a patch for the r600 mesa driver that adds glsl 1.20, go figure

            Comment


            • #7
              Whoops, ignore - that's Andre's patch which changes the level of support the driver exposes so that you can see what functions the application actually uses.

              Comment


              • #8
                Originally posted by bridgman View Post
                Do you happen to know if you need essentially all of GLSL 1.20 or are there one or two specific things you use ? I don't have the list in front of me but I seem to remember 1.20 being a good mix of "pretty easy" and "probably hard" features...

                (hoping you use the "pretty easy" ones obviously )
                It's been a while since we switched to 1.20 shaders, but IIRC we use some array features that aren't in 1.10, and since making that switch we've also started to depend on gl_FragData[] being available regardless of ARB_draw_buffers.

                My impression from the list of changes between 1.10 and 1.20 is that most (all?) of the changes are grammar changes that shouldn't have all that much impact on the resulting TGSI. Since Mesa's GLSL parser seems to understand 1.20 it's not entirely clear to me why r600/radeon doesn't support it. I did ask about that in #radeon, but didn't get anything more concrete than something along the lines of "the driver doesn't support it".

                I'm not sure if using GLSL with Wine on r600/r700 would be an advantage at this point though. For reasons mostly related to the way d3d9 works, wined3d creates shaders that declare more uniforms than the GL implementation reports as supported, and then depends on the GLSL compiler to be smart enough to figure out which ones are actually used. AFAIK this work for both fglrx and nvidia, but not so much for Mesa. What's perhaps worse is that instead of failing to compile the shader r600/r700 seems to silently drop any uniforms past the supported ones. Typically that results in things being either misrendered or not rendered at all, without much to go on in terms of GL errors or GLSL infolog contents.

                I also ran across some memory corruption when using GLSL, I think due to pAsm->starting_export_register_number being larger than pAsm->D.dst.reg somewhere, resulting in writing to pAsm->pucOutMask[-1], which then corrupts internal glibc memory management structures. Unfortunately I haven't gotten around to properly tracking that down yet, due to other priorities/responsibilities.

                For what it's worth, I actually have r700 hardware, because I think AMD is doing the right thing here, and I'd like to help a bit with making it work. I'm just not able to spend a whole of time on it at the moment.

                Comment


                • #9
                  Originally posted by phoronix View Post
                  Phoronix: Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

                  Recent releases of Wine have tackled Direct3D improvements among other enhancements in this popular free software project and Wine 1.1.43 has been released this afternoon to offer up more Direct3D love...

                  http://www.phoronix.com/vr.php?view=ODE2MA
                  When I'm thinking of it, I don't think I have ever seen any analysis of the long term improvement of wine performance. In this article we hear about "optimizations", but what do they mean in reality?

                  Michael, it would be very nice to see how wine has changed (improved or regressed?), perhaps using some fairly advanced (DX9.0c) Windows game and see how performance (fps) changes with a number of the latest wine versions.

                  Following two games based on two different engines will be the best as to capture different aspects.

                  Comment


                  • #10
                    Originally posted by Henri View Post
                    It's been a while since we switched to 1.20 shaders, but IIRC we use some array features that aren't in 1.10, and since making that switch we've also started to depend on gl_FragData[] being available regardless of ARB_draw_buffers.

                    My impression from the list of changes between 1.10 and 1.20 is that most (all?) of the changes are grammar changes that shouldn't have all that much impact on the resulting TGSI. Since Mesa's GLSL parser seems to understand 1.20 it's not entirely clear to me why r600/radeon doesn't support it. I did ask about that in #radeon, but didn't get anything more concrete than something along the lines of "the driver doesn't support it".

                    I'm not sure if using GLSL with Wine on r600/r700 would be an advantage at this point though. For reasons mostly related to the way d3d9 works, wined3d creates shaders that declare more uniforms than the GL implementation reports as supported, and then depends on the GLSL compiler to be smart enough to figure out which ones are actually used. AFAIK this work for both fglrx and nvidia, but not so much for Mesa. What's perhaps worse is that instead of failing to compile the shader r600/r700 seems to silently drop any uniforms past the supported ones. Typically that results in things being either misrendered or not rendered at all, without much to go on in terms of GL errors or GLSL infolog contents.

                    I also ran across some memory corruption when using GLSL, I think due to pAsm->starting_export_register_number being larger than pAsm->D.dst.reg somewhere, resulting in writing to pAsm->pucOutMask[-1], which then corrupts internal glibc memory management structures. Unfortunately I haven't gotten around to properly tracking that down yet, due to other priorities/responsibilities.

                    For what it's worth, I actually have r700 hardware, because I think AMD is doing the right thing here, and I'd like to help a bit with making it work. I'm just not able to spend a whole of time on it at the moment.
                    Appreaciate your work.

                    Comment


                    • #11
                      Originally posted by Hephasteus View Post
                      Geez. End of year linux's are going to have some very nice wine packages.
                      Would it be wishful thinking to expect Linux to become a better Windows than Windows at some point?

                      Comment


                      • #12
                        Originally posted by Henri View Post
                        It's been a while since we switched to 1.20 shaders, but IIRC we use some array features that aren't in 1.10, and since making that switch we've also started to depend on gl_FragData[] being available regardless of ARB_draw_buffers.

                        My impression from the list of changes between 1.10 and 1.20 is that most (all?) of the changes are grammar changes that shouldn't have all that much impact on the resulting TGSI. Since Mesa's GLSL parser seems to understand 1.20 it's not entirely clear to me why r600/radeon doesn't support it. I did ask about that in #radeon, but didn't get anything more concrete than something along the lines of "the driver doesn't support it".

                        I'm not sure if using GLSL with Wine on r600/r700 would be an advantage at this point though. For reasons mostly related to the way d3d9 works, wined3d creates shaders that declare more uniforms than the GL implementation reports as supported, and then depends on the GLSL compiler to be smart enough to figure out which ones are actually used. AFAIK this work for both fglrx and nvidia, but not so much for Mesa. What's perhaps worse is that instead of failing to compile the shader r600/r700 seems to silently drop any uniforms past the supported ones. Typically that results in things being either misrendered or not rendered at all, without much to go on in terms of GL errors or GLSL infolog contents.

                        I also ran across some memory corruption when using GLSL, I think due to pAsm->starting_export_register_number being larger than pAsm->D.dst.reg somewhere, resulting in writing to pAsm->pucOutMask[-1], which then corrupts internal glibc memory management structures. Unfortunately I haven't gotten around to properly tracking that down yet, due to other priorities/responsibilities.

                        For what it's worth, I actually have r700 hardware, because I think AMD is doing the right thing here, and I'd like to help a bit with making it work. I'm just not able to spend a whole of time on it at the moment.
                        I thought wine developers wouldn't care about mesa but I was obviously wrong.
                        I hope mesa & wine developers would work hand-in-hand towards useful graphic drivers.
                        Wine developers obviously know which functions are pretty useful, mesa developers may be interested in a top lacking-feature list.

                        Doing this could also allow performance-enthusiasts people to actually try the open source driver.

                        Comment


                        • #13
                          I have been able to run quite a few games with Wine with the i965 driver, which supports GLSL 1.20. Not sure what's the best testcase for d3d9, but it's possible to run 3DMark 06.

                          Performance is unsurprisingly a major problem, but that's something I hope ATIs hardware can address

                          Comment


                          • #14
                            Originally posted by Henri View Post
                            For what it's worth, I actually have r700 hardware, because I think AMD is doing the right thing here, and I'd like to help a bit with making it work. I'm just not able to spend a whole of time on it at the moment.
                            I might as well take the opportunity to ask:
                            To what extent are wine development releases tested on ATI hardware with fglrx?

                            It might be a communication issue but I get the feeling Radeon owners are pretty much treated as second-rate users and served the "It's a fglrx problem" copy/paste as a way to avoid investigating the actual cause of the hickups.

                            I understand that a few years ago ATI's binary driver was too much a hassle to bother with, so I wonder if the "screw this" mindset is still influencing wine devs without a second thought.

                            Personally I've had problems with anything 3D past 1.1.37 in apps listed in the platinum top 10, problems which nature makes me wonder how this could even get pushed out of the door in that state.

                            Of course regression testing is welcome and encouraged by the wine team, and I understand development releases are prone to breakage, however the obviousness of the graphical glitches combined with that nagging feeling of "blame fglrx" being a reflex makes the whole process daunting.

                            Again, it's a feeling I get so you're more than welcome to prove me wrong.

                            Comment


                            • #15
                              Wine has always been a bloody pain in the back.

                              No matter what game I run (I have an entire book 'clouset' filled with them) it never, ever, ever works out of the box with Wine. The same goes for desktop apps, except for WinRAR, which you need for cracks.

                              It isn't that the Wine devs aren't doing a great job; on the contrary; when something works it work with the most complex 3D tech and shaders and all that, but it's always these tiny problems that screw the entire use of Wine in most cases.

                              For example: allmost all gamers that play online games have a headset. In the Windows world, almost everyone uses Ventrilo, which is a low latency group VOIP client. It works for 100% correctly, but there is one tiny stupid bug that renders the entire app useless: the hotkey push-to-talk doesn't work when it is out of focus. And guess what? When your playing a game, Ventrilo is always out of focus.

                              Another example: Carmageddon TDR2000 aka the Death Race works completely out of the box, even with copy protection (and it doesn't work on Windows anymore starting with Windows XP) and it works for 100% correctly on Wine, but the config app that runs before TDR2000 runs cannot detect the presence of a graphics card so it makes the game run software only with the most uglhy graphics that you have ever seen! There is a workaround where you can just manually edit the config file so it thinks it has already detected a Direct3D compatible graphics card and it runs like a charm (yay!), but it doesn't do that for newbies.

                              If only the Wine team would get together and fix these papercuts for a month long; Wine would be able to run games for end-users.

                              And that's the point anyways...

                              If only all Wine devs got together and decided

                              Comment

                              Working...
                              X