Page 1 of 4 123 ... LastLast
Results 1 to 10 of 32

Thread: Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

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

    Default 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. #2
    Join Date
    Dec 2008
    Posts
    315

    Default

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

  3. #3
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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)

  4. #4
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote 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.

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,570

    Default

    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 )

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,570

    Default

    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

  7. #7
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,570

    Default

    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.

  8. #8
    Join Date
    Feb 2009
    Posts
    45

    Default

    Quote 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.

  9. #9
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    Default

    Quote 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.

  10. #10
    Join Date
    Apr 2010
    Posts
    141

    Default

    Quote 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.

Posting Permissions

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