Wine 1.1.43 Brings Many Direct3D Fixes, Optimizations

[phoronix]

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

[Hephasteus]

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

[Qaridarium]

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)

[Henri]

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.

[bridgman]

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 )

[bridgman]

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

[bridgman]

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.

[Henri]

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.

[sabriah]

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.

[Hans]

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.