Wine's Shader Compiler Now Handles... Reflections

[Jonno]

Please note that running tests in Wine set to emulate Win95 is still supporter, it is only the ability to run the test suite on actual Win95 that are removed.

Wine set to Win95 compatibility mode still support most functions introduced in later versions of Windows (such as Unicode), and excising functions that crashed on some input in Win95 but works on later versions of Windows will still work in Wine set to Win95. Only when an excising function changed working behaviour in a later Windows versions does Wine change it's behaviour based on compatibility mode. Such functions can still be tested with the test suite, but the tests may now use other functionality introduced/fixed in later versions of Windows, and will thus fail on real Win95.

This makes verifying bug-for-bug-compatibility with Win95 harder, but makes maintaining the test suite easier, likely a worthwhile trade off.

Also note that the test suite has never been able to run on Win 3.1, but win16 test can be run on WoW (Windows on Windows), the win16 compatibility layer in 32bit versions of Windows. That is still supported, but win16 tests are, as far as I can tell, all but nonexisting.

[crazycheese]

The problem is that WINE is not an Linux only program

I think the problem is only that DirectX is literally owned by Microcorp.
And everyone who is not with opengl donates to its development.

[Henri]

Were these tests supposed to signal regressions? And were these tests somehow not needed for 9x/3.x, or were they needed but broken? As a simple Wine user I'm still confused about why this won't impact Win9x/3.x applications.

There are regression tests, yes. The issue is on one side that Win9x is missing lots of things that are present on later versions. For example, Win9x has practically no support for Unicode, so if you wanted to test something you'd either have to restrict the tests to using non-Unicode functions only, or skipping the tests on Win9x. On the other hand, a lot of the things that are implemented in Win9x are just quirky or crash for no good reason, so you'd have to either avoid calling those as well, or make the tests less strict to accept the additional behaviour. Wine itself still needs to conform to the more strict behaviour, since there are plenty of applications that depend on 2000 or XP behaviour by now. And since most Win9x applications still run on e.g. XP or Win7 as well, having the tests run on Win9x doesn't add a whole lot.

[TheCycoONE]

Were these tests supposed to signal regressions? And were these tests somehow not needed for 9x/3.x, or were they needed but broken? As a simple Wine user I'm still confused about why this won't impact Win9x/3.x applications.

I'm not involved in any way so this is just a guess, but I think that the same functions were behaving slightly differently in NT varients than 9x varients and that therefore for the tests to pass in both NT and 9x varients they would have to be more lenient than if they were to target just the one line. If this is true, then with unlimited resources they could keep a seperate series of tests for 9X which is tested with Wine set to the particular windows versions, but they probably don't have the time/manpower for that.

[Remco]

- Dropping Win9x support from the tests should mostly result in the tests being more strict and easier to maintain. http://www.winehq.org/pipermail/wine...ry/089017.html explains it pretty well. Wine itself will keep supporting Win9x and 3.x applications.

Were these tests supposed to signal regressions? And were these tests somehow not needed for 9x/3.x, or were they needed but broken? As a simple Wine user I'm still confused about why this won't impact Win9x/3.x applications.

[ChrisXY]

Additionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.

Define serious gaming.

On my Athlon II 240 and HD 4670 with color tiling and page flipping enabled (and running the drm-radeon-testing kernel) Urban Terror runs with ~ 90-120 fps. It has bad vsync issues and it is not the most graphically challenging game but it runs fast.
On nexuiz with everything maxed out except for antialiasing and anisotropy I get > 20 fps all the time which is somewhat slow but somehow it is better playable than it sounds. With slightly reducing effects it runs perfectly.
Assault cube runs on 60-80 fps on "insane" graphics settings.

On the other hand Warcraft3 in wine with the -opengl switch (on the box it says it needs a 8 mb directx 8 graphics card) I got only now near 60 fps with color tiling and page flipping. Most of the time it goes down to 20 fps and on heavy fights it is at 4-6 fps. That's not funny.
When I try to start a half life 2 game even in -dxlevel 70 hl2.exe AND X both enter uninterruptible sleep.

So yes, wine can already be improved for r600g.

[Henri]

A couple of points:
- The article seems fairly clueless about what reflection support means, and how it fits in with the rest of Wine.
- Wine using the d3d1x state tracker simply isn't going to happen. The article is clueless about what the practical differences between using OpenGL vs. using d3d1x would be.
- Wine developers only using NVIDIA hardware and drivers is simply not true. Though pretty limited in the amount of time I can spend on this, I actually contribute to r600g (and Mesa in general) on occasion. I much rather spend my time on drivers I can actually debug and fix than on writing dodgy hacks for binary blobs. That doesn't mean the free drivers don't still have quite some way to go, of course, but I think free drivers are important and I'd like to see them succeed. Also, the EXT_texture_sRGB_decode extension mentioned earlier in this thread isn't even supported yet by current NVIDIA drivers.
- Wine focusing only on Direct3D or games doesn't have a whole lot of truth to it either. If you happen to have the git version of Wine, compare "git shortlog -s -n wine-1.0..wine-1.3.15" with "git shortlog -s -n wine-1.0..wine-1.3.15 dlls/wined3d". There may be a lot of work going into wined3d, but it's really just a small fraction of Wine developers working specifically on wined3d.
- The reason I'm not working on d3d10/11 is due to CodeWeavers' current priorities. I'm unhappy about this, but if you want to see this changed that's where you should complain. I imagine being an actual CodeWeavers customer would give such a complaint more weight.
- Dropping Win9x support from the tests should mostly result in the tests being more strict and easier to maintain. http://www.winehq.org/pipermail/wine...ry/089017.html explains it pretty well. Wine itself will keep supporting Win9x and 3.x applications.

[yesterday]

Did you mean using the the Gallium 3D State tracker for DX10/11?

I think that that would be the best way to go about it.

+1 To that idea

The " best way" would involve dropping all intel and proprietary nvidia and amd users?

[lolren]

Additionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.

i know that but switching to native Gallium 3D DirectX wine support would stop alot of games running till OSS drivers matures. Maybe another Wine branch..

[thefirstm]

yes, but is a know fact that most wine devs use nvidia (and the binary blob) (and this is the best to work with wine). sadly, nvidia does not support Gallium 3D, so it is a long shot to adopt that, at least for now.

Additionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.