Wine 3.0 Released With Initial Direct3D 11 Support, D3D Command Stream

[oiaohm]

Another workaround is to start using C++ (and IMO if we target at least C++14 it's a much better one). As an example of a great project that successfully mixes both C and C++ I can point out Mesa. MSVC supports C++ just fine, so building with it should cause no problems.

C++ is off the table for dll at least and its because of MSVC vs GCC. Differences between MSVC and GCC use different name mangling and garbage collection and exception handling. Wine end up emulating MSVC C++ library function in C so that gcc can in fact build them and in fact have the right behaviour.

Lot of things other project can do wine cannot due to having to replicate the behaviours of MSVC on GCC or needing ablity to build code back on MSVC to test stuff.

But the bug you linked tells that it doesn't compile with c89, c99, c11 — not that it ends up in incorrect behavior..

This is because I did look at that bug a while back and got very naughty in my testing.

https://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Function-Specific-Option-Pragmas.html

Yes you can alter using #pragma GCC optimize where it using particular standards. Doing to cover the areas demanding gnuxx then you find out that using standard mode in gcc for c89, c99 and c11 either the standard problems or gcc has problems with what wine requires but it works fine as long as you stick to the gnu versions. So quite painful.

Thanks, it was a pleasure to read your comments, both on C89 and Gallium Nine, it's the first time I actually feel there are real technical reasons behind instead of something vague maybe-politic-maybe-just-because.

Wine development model really does not allow for political. Its like the person attempting to get a pulseaudio backend merge that took 8 years with about 50 rejects. Kind of problem as galluim nine where test cases that worked on the existing audio would not work on pulseaudio backend and people were again demanding it merge. A developer finally listen addressed the missing features that were breaking tests and the pulseaudio backend merged without issue.

I can example after example. Every case you had a group of users claiming this is better of this stack of applications merge it. But after enough stubbornness and sticking to rules as wine does normally a developer who take correct method re-implements and that feature gets merged into wine better than it ever was.

Wine is test driven development. This means if you break test with your patches and are unable to demo that under windows that is the right behaviour so the test was wrong your code will be rejected and it will not matter what other merits you think the code has its now dead in the water. This is why wine project has a staging branch these days for unable merged patches working to get to conditions to be merged..

Compiler standard selection is all about allow testing and replicating required behavours.

Now of course due to be test driven development lot of the developers don't exactly know why they are doing something with wine. All they know is they are doing it so they don't break tests. I do more support so having to explain to people why their patches are being stone walled is something I have to-do at times. Also having to explain wine compiler choices. The person who taught me most of this is the wine project official history writer. Yes it kind of strange to need to talk the historian to work out why stuff is done the way it is. Heavy test driven makes lot of wine project selections a matter of historic record of where something was tested and it failed do going that way was forbid and if it tested now and proven to work that forbid status can be removed.

So wine demos the price of being test driven to the point of removing most personal options from development. Its a common in most projects that selections are made from personal points of view. Personal points of view inside wine development model 99.9% of the time mean absolutely nothing it can you back that with test results please not when wine project wants test results they want the full wine test-suite to run with no new errors unless they are new tests.

Even code attempted to be submitted by codeweavers(they pay the maintainer his wage) cannot be accepted if it breaking the testsuite. There are no real wiggle room for anyone wanting to patch code in wine on this point. This lack of wiggle room means wine project does not get bogged down in political arguments or attempting to argue with the maintainer most of the time. Yes gallium nine developer did make the mistake of thinking wine issue were political.

Looking for political reasons for wine selection in this is a huge waste of time because they are not there.

[Hi-Angel]

C++ is off the table for dll at least and its because of MSVC vs GCC. Differences between MSVC and GCC use different name mangling and garbage collection and exception handling. Wine end up emulating MSVC C++ library function in C so that gcc can in fact build them and in fact have the right behaviour.

Lot of things other project can do wine cannot due to having to replicate the behaviours of MSVC on GCC or needing ablity to build code back on MSVC to test stuff.

But a userspace external to a dll don't need to know what language the dll was written in Just declare functions being exported as extern "C", and that's it. And C++ don't have garbage collection. It's basically like C, but more powerful because of stuff like RAII, lambdas, templates, etc.

This is because I did look at that bug a while back and got very naughty in my testing.

https://gcc.gnu.org/onlinedocs/gcc-4...n-Pragmas.html
Yes you can alter using #pragma GCC optimize where it using particular standards. Doing to cover the areas demanding gnuxx then you find out that using standard mode in gcc for c89, c99 and c11 either the standard problems or gcc has problems with what wine requires but it works fine as long as you stick to the gnu versions. So quite painful.

Okay, I can't comment anything sane on this because I don't know the code, and at this point can only speculate.

Wine development model really does not allow for political. Its like the person attempting to get a pulseaudio backend merge that took 8 years with about 50 rejects. Kind of problem as galluim nine where test cases that worked on the existing audio would not work on pulseaudio backend and people were again demanding it merge. A developer finally listen addressed the missing features that were breaking tests and the pulseaudio backend merged without issue.

I can example after example. Every case you had a group of users claiming this is better of this stack of applications merge it. But after enough stubbornness and sticking to rules as wine does normally a developer who take correct method re-implements and that feature gets merged into wine better than it ever was.

Wine is test driven development. This means if you break test with your patches and are unable to demo that under windows that is the right behaviour so the test was wrong your code will be rejected and it will not matter what other merits you think the code has its now dead in the water. This is why wine project has a staging branch these days for unable merged patches working to get to conditions to be merged..

Compiler standard selection is all about allow testing and replicating required behavours.

Now of course due to be test driven development lot of the developers don't exactly know why they are doing something with wine. All they know is they are doing it so they don't break tests. I do more support so having to explain to people why their patches are being stone walled is something I have to-do at times. Also having to explain wine compiler choices. The person who taught me most of this is the wine project official history writer. Yes it kind of strange to need to talk the historian to work out why stuff is done the way it is. Heavy test driven makes lot of wine project selections a matter of historic record of where something was tested and it failed do going that way was forbid and if it tested now and proven to work that forbid status can be removed.

So wine demos the price of being test driven to the point of removing most personal options from development. Its a common in most projects that selections are made from personal points of view. Personal points of view inside wine development model 99.9% of the time mean absolutely nothing it can you back that with test results please not when wine project wants test results they want the full wine test-suite to run with no new errors unless they are new tests.

Even code attempted to be submitted by codeweavers(they pay the maintainer his wage) cannot be accepted if it breaking the testsuite. There are no real wiggle room for anyone wanting to patch code in wine on this point. This lack of wiggle room means wine project does not get bogged down in political arguments or attempting to argue with the maintainer most of the time. Yes gallium nine developer did make the mistake of thinking wine issue were political.

Looking for political reasons for wine selection in this is a huge waste of time because they are not there.

Well, such stuff usually happens per lack of communication. When people don't see a reasoning behind something (usually because they lack some information), they start asking everybody. If nobody can answer the question, peoples starts speculating. At this point if still no technical reasons can be seen, people, depending on situation, turn either to Hanlon's razor or to politics.

For example when you mentioned about usage of DX9 together with DX10/11, I turned to this discussion https://github.com/wine-compholio/wine-staging/pull/333 to see if it was mentioned there. I did watch it, but pretty cursory, so I easily could've missed something, so I started searching for word "DX11", to no avail. Then the word "compat" — and the last match for the word did reveal a short paragraph saying this

As a second step, if there is a general agreement that a
Gallium backend is a good idea (lot of people to convince ...), it
would basically be necessary to start again from scratch. Upstream
would never accept a solution which is only compatible with d3d9. What
about ddraw, d3d8, d3d10 or d3d11? The best way to do this would be to
implement a Gallium version of "wined3d" (instead of d3d9).[technical details follows]

It could imply what you mentioned, but to unaware people it rather sounds as if the author suggests writing more backends for no reason. You could probably say that reading that discussion requires certain background — but in this specific discussion, being a hot topic, participated dozens of peoples with a very vague background.

[oiaohm]

But a userspace external to a dll don't need to know what language the dll was written in Just declare functions being exported as extern "C", and that's it. And C++ don't have garbage collection. It's basically like C, but more powerful because of stuff like RAII, lambdas, templates, etc.

Theory and real world does not match. When you have function names containing C++ forbid words they don't work in extern "C" and you need to have those words because the C++ dll built by Microsoft compilers do. Yes people who use C++ sell extern "C" as a solve all it is until you have the nightmare of attempting to be a different versions of C++ and have the compiler hate you.

Really c++ standard does not mandate garbage collection but when you deal with provided runtime C++ with MSVC and gcc you have to deal with garbage collection and they are absolutely different as how the garbage collection has to work is not in the standard. Making mistake of putting something gcc garbage collected into MSVC program equals things going badly wrong.

Well, such stuff usually happens per lack of communication. When people don't see a reasoning behind something (usually because they lack some information), they start asking everybody. If nobody can answer the question, peoples starts speculating. At this point if still no technical reasons can be seen, people, depending on situation, turn either to Hanlon's razor or to politics.

That is kind of problem. Its not lack of communication its not understanding what is being said and how serous it is.

For example when you mentioned about usage of DX9 together with DX10/11, I turned to this discussion https://github.com/wine-compholio/wine-staging/pull/333 to see if it was mentioned there. I did watch it, but pretty cursory, so I easily could've missed something, so I started searching for word "DX11", to no avail. Then the word "compat" — and the last match for the word did reveal a short paragraph saying this

It could imply what you mentioned, but to unaware people it rather sounds as if the author suggests writing more backends for no reason. You could probably say that reading that discussion requires certain background — but in this specific discussion, being a hot topic, participated dozens of peoples with a very vague background.

I will re-quote bits and explain because that paragraph is a lot more serous. First thing for those who don't know slackner is the official maintainer of what patches are allowed in staging. So what ever slackner say says has to be taken deadly serous-ally.

What about ddraw, d3d8, d3d10 or d3d11?

This bit is very serous. For those who don't know how to read that. Those names there ddraw, d3d8, d3d10 and d3d11 are segments in the wine testsuite that are broken when gallium nine is enabled. And the test-suite is based off behaviours of real world applications. Yes that is direct x 8 using applications that happen to use a little direct x 9 go into fail as well. When you have 4 areas of wine testsuite throwing failure you have quite a large number of effected applications that are crashing way more than what gallium nine makes work right.

The best way to do this would be to implement a Gallium version of "wined3d" (instead of d3d9).

Where wine implements the cross bridge between Dx versions is in wined3d what is used to replace what a windows direct x driver does. So replacing wined3d with something closer to real hardware would be a valid path.

Slackner/Sebastian who look after staging is willing to ignore test suite failures, the fact upstream might ask questions why more back-ends as long as the people behind the patch show the will to address the problems. Answering him we are only doing direct x 9 and will ignore all those other failures basically equals forgot getting your patch until you change or never what ever comes first. Why will he not put patch like gallium nine in staging simple if he does then those behind the patch being a idiot will put pressure on mainline to include something that is not ready and he will be trouble and patch will be forced removed anyhow.

Reality here is if you cannot get you patch pass Slackner/Sebastian due to not listening and address the problems with plan you are really in trouble. You don't even what to hear what the wine mainline maintainer will be thinking of you.

To be in staging branch does not require perfection but does require a plan to get to something that will work correctly some point in the future. Please note Slackner/Sebastian has answered same kind of ways over 100 times on gallium nine. Yet people still attempting to apply pressure instead of listening and coming back with this is our plan how to address all those failures. Please note Slackner/Sebastian will also delete patch from staging if you turn out not to be following your submitted plan to address problems what is really only fair.

Yes the people who are saying works for me with gallium nine attempting pressure on wine project really need to stop it and put pressure back on gallium nine for where their plan is to address problems or move on to something else that stands a better chance of working correctly.

[Hi-Angel]

Theory and real world does not match. When you have function names containing C++ forbid words they don't work in extern "C" and you need to have those words because the C++ dll built by Microsoft compilers do. Yes people who use C++ sell extern "C" as a solve all it is until you have the nightmare of attempting to be a different versions of C++ and have the compiler hate you.

Well, given we're talking of replacing pure C with C++ — are there words that C does allow in function names but C++ doesn't?

Really c++ standard does not mandate garbage collection but when you deal with provided runtime C++ with MSVC and gcc you have to deal with garbage collection and they are absolutely different as how the garbage collection has to work is not in the standard. Making mistake of putting something gcc garbage collected into MSVC program equals things going badly wrong.

Oh, it's the first time I hear C++ indeed has an optional support for garbage collection https://stackoverflow.com/questions/...r-why-and-hows Well… Then just don't use it I mean, having GC in C++ is weird enough that there should be a switch to disable it, especially given the linked answer does show example where a pointer might get garbage-collected even though still in use. FWIW I'm not even sure GCC has support for it, I didn't find anything in docs.

Besides, what about such dlls when used from C code? I think GC is either disabled upon building libraries, or isolated enough to not influence anything in the outside world.

FWIW, you were complaining that debug info from GCC/Clang built binaries plays terribly with ones built by MSVC, so you not gonna use them together anyway.

That is kind of problem. Its not lack of communication its not understanding what is being said and how serous it is.


I will re-quote bits and explain because that paragraph is a lot more serous. First thing for those who don't know slackner is the official maintainer of what patches are allowed in staging. So what ever slackner say says has to be taken deadly serous-ally.



This bit is very serous. For those who don't know how to read that. Those names there ddraw, d3d8, d3d10 and d3d11 are segments in the wine testsuite that are broken when gallium nine is enabled. And the test-suite is based off behaviours of real world applications. Yes that is direct x 8 using applications that happen to use a little direct x 9 go into fail as well. When you have 4 areas of wine testsuite throwing failure you have quite a large number of effected applications that are crashing way more than what gallium nine makes work right.


Where wine implements the cross bridge between Dx versions is in wined3d what is used to replace what a windows direct x driver does. So replacing wined3d with something closer to real hardware would be a valid path.

Slackner/Sebastian who look after staging is willing to ignore test suite failures, the fact upstream might ask questions why more back-ends as long as the people behind the patch show the will to address the problems. Answering him we are only doing direct x 9 and will ignore all those other failures basically equals forgot getting your patch until you change or never what ever comes first. Why will he not put patch like gallium nine in staging simple if he does then those behind the patch being a idiot will put pressure on mainline to include something that is not ready and he will be trouble and patch will be forced removed anyhow.

Reality here is if you cannot get you patch pass Slackner/Sebastian due to not listening and address the problems with plan you are really in trouble. You don't even what to hear what the wine mainline maintainer will be thinking of you.

To be in staging branch does not require perfection but does require a plan to get to something that will work correctly some point in the future. Please note Slackner/Sebastian has answered same kind of ways over 100 times on gallium nine. Yet people still attempting to apply pressure instead of listening and coming back with this is our plan how to address all those failures. Please note Slackner/Sebastian will also delete patch from staging if you turn out not to be following your submitted plan to address problems what is really only fair.

Yes the people who are saying works for me with gallium nine attempting pressure on wine project really need to stop it and put pressure back on gallium nine for where their plan is to address problems or move on to something else that stands a better chance of working correctly.

Thanks for explanations.

[artivision]

Problem here since I do support on wine. I am not looking at the information from 40 games. I am looking 5000+ games and applications. Gallium Nine looks very bad when you are looking big picture. Look great when you are using applications that work with it. Of course the wine developers like me are looking big picture and wants something that fits properly and works for the big picture.

Failure to understand that there is a big picture means people start demand items like galluim nine get included when they don't have the technical merit to be included then yell at the developer for being foolish. Wine project rules does not support per application or applications hacks. Part of the prime objective of wine is to be able to run everything without user having to change settings. Galluim nine since it does not support the integration between direct x versions and opengl does not meet part of the prime objective either.

Unless there is changes in gallium nine developer it would be better to support VK9 at least there is a fair chance for that to merge. Its possible to share from vulkan buffers back to normal opengl and direct x under windows and it already possible from the vulkan support in wine to do that with existing parts. So linking VK9 in properly is in fact possible.

The big picture is that if you have a less than 3Ghz processor (laptop) you can forget playing with WineD3D9 for about half the available games. Also even on a high end system you will lose half the frame-rate. Till today you people haven't even learned how to make proper multi-threaded code. Even i can make code that can split efficiently the game-engine from the graphics-engine, even if the game is single-threaded. Sorry but that's how it is.

[oiaohm]

Well, given we're talking of replacing pure C with C++ — are there words that C does allow in function names but C++ doesn't?

Yes there is like the key words like class.

https://www.kernel.org/pub/linux/kernel/people/mochel/doc/text/class.txt

Its the classic one if someone uses a C++ compiler on the Linux kernel. Now you have structures and functions containing the word class that are not C++ parts and C++ compilers can get really upset yet C compiler no problems.

So its not always possible to build a C program in C++ when the exported function names have exact requirements and those requirements conflict with what C++ compiler likes. The other thing is g++ does attempt at time to understand how MSVC encode its names. So wine switching to C++ would bring some major complications and require quite a few gcc and llvm c++ compiler modifications.

Oh, it's the first time I hear C++ indeed has an optional support for garbage collection https://stackoverflow.com/questions/...r-why-and-hows Well… Then just don't use it I mean, having GC in C++ is weird enough that there should be a switch to disable it, especially given the linked answer does show example where a pointer might get garbage-collected even though still in use. FWIW I'm not even sure GCC has support for it, I didn't find anything in docs.

https://gcc.gnu.org/projects/cxx-status.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm

There is a C++11 and newer the standard mandates that you include a GC to be fully to spec. Currently gcc has not implemented this interface. Instead you have the following interface.

https://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information

A full C++ parser would be too complicated for this task, so a limited subset of C++ is interpreted and special markers are used to determine what parts of the source to look at. All struct, union and template structure declarations that define data structures that are allocated under control of the garbage collector must be marked. All global variables that hold pointers to garbage-collected memory must also be marked. Finally, all global variables that need to be saved and restored by a precompiled header must be marked. (The precompiled header mechanism can only save static variables if they’re scalar. Complex data structures must be allocated in garbage-collected memory to be saved in a precompiled header.)

O yes g++ support garbage collection as a random-ally placed land mines of garbage collection that can cause you real trouble when you are needing to control the garbage collection to match up with MSVC method of garbage collection.

Besides, what about such dlls when used from C code? I think GC is either disabled upon building libraries, or isolated enough to not influence anything in the outside world.

Dll files export C functions as one function and C++ functions as a C++ mangled name function so you can have the same function appearing twice and one is expected to obey garbage collection. Sanity would say isolate when you make dll but that is not what most C++ compiler have done with garbage collection. So something has been passed to your function you are done with it you need to report to garbage collection that you have released it if it being tracked by garbage collection.

FWIW, you were complaining that debug info from GCC/Clang built binaries plays terribly with ones built by MSVC, so you not gonna use them together anyway.

I was complaining about the hell of debugging info from GCC/Clang with MSVC built ones as it a nightmare that you face when attempting to work out why wine will not run X program. Of course wine for Linux and OS X and Freebsd is built with gcc or clang and the binaries executable people want to run are build with MSVC. Due to the hell that debugging is why at times you need to be able to built bits of wine for windows using MSVC to work out if the debugging information is tell truth or fibs.

If the debugging information for mixed compiler build programs could be sorted out it would make wine development a lot more pleasant.

The biggest restrictions on wine come from having to do stuff that is compatible with c++ applications built by MSVC.

Yes user C++ it will be better argument complete falls in a heap when you have cases where you are having to mix two C++ compilers actions to play ball with each other without ripping themselves to bits. Wine is a clear demo of why at times C has it place due C leaving the actions of the program up to the programmer to set and not doing things like garbage collection in background. Of course most people doing C++ would only be dealing with 1 C++ compiler at a time and not see the nightmare wine has to face off against.

[oiaohm]

The big picture is that if you have a less than 3Ghz processor (laptop) you can forget playing with WineD3D9 for about half the available games. Also even on a high end system you will lose half the frame-rate. Till today you people haven't even learned how to make proper multi-threaded code. Even i can make code that can split efficiently the game-engine from the graphics-engine, even if the game is single-threaded. Sorry but that's how it is.

The process to direct 3d command stream its interesting complex and painful. It was not writing multi-threaded code was the problem. It was locating a lot of areas that opengl when you run multi threaded goes nuts. Galuim nine has advantage sitting directly on the hardware of not having to deal with opengl single threaded nature. Redone on top of vulkan that is design to be multi threaded there is quite a performance boost possible there and be more hardware neutral and use storage types that can be integrated in.

Losing half the framerate it still runs compared to be complete crashed and not running. Sorry only about 1/3 of the dx9 games can work wine current default would work the dx8 to dx9 interaction gallium nine does not support breaks about 2/3 of the direct x 9 games that you could run under wine. Games and recycled old code from prior games. Same thing happens with your newer dx10,dx11 and dx12 games.

The big picture is you have to-do what works properly even if it slow. Test driven development that wine follows is not performance driven development. Early wine had performance driven development and that caused lot more regressions between versions as in a programs would work one version of wine and fail in newer versions of wine way more often.

So should wine go back to its old performance driven development and forgot having most number of applications work as in run. That is effectively what you are asking for.

[artivision]

The process to direct 3d command stream its interesting complex and painful. It was not writing multi-threaded code was the problem. It was locating a lot of areas that opengl when you run multi threaded goes nuts. Galuim nine has advantage sitting directly on the hardware of not having to deal with opengl single threaded nature. Redone on top of vulkan that is design to be multi threaded there is quite a performance boost possible there and be more hardware neutral and use storage types that can be integrated in.

Losing half the framerate it still runs compared to be complete crashed and not running. Sorry only about 1/3 of the dx9 games can work wine current default would work the dx8 to dx9 interaction gallium nine does not support breaks about 2/3 of the direct x 9 games that you could run under wine. Games and recycled old code from prior games. Same thing happens with your newer dx10,dx11 and dx12 games.

The big picture is you have to-do what works properly even if it slow. Test driven development that wine follows is not performance driven development. Early wine had performance driven development and that caused lot more regressions between versions as in a programs would work one version of wine and fail in newer versions of wine way more often.

So should wine go back to its old performance driven development and forgot having most number of applications work as in run. That is effectively what you are asking for.

Sorry friend but your metrics are not correct. I play only AAA games on a gaming laptop, those are the games that i consider real games. Until now all of them work with Gallium-Nine without any exceptions. I cannot say the same for Wine-CSMT, low fps, broken graphics.

[oiaohm]

Sorry friend but your metrics are not correct. I play only AAA games on a gaming laptop, those are the games that i consider real games. Until now all of them work with Gallium-Nine without any exceptions. I cannot say the same for Wine-CSMT, low fps, broken graphics.

Really notice the pure weaselling words. Only AAA games lets ignore business applications or anything else using direct x that Gallium-Nine breaks.

The metrics I use are solid on what percentage of applications and games can be run.

Basically artivsion is saying I don't care who else workflow I break as long as the few programs I am interested in work. Of course that arguement means nothing to test driven development like wine. Wine project does not exist to service just 1 group of users exclusively.

[duby229]

Really notice the pure weaselling words. Only AAA games lets ignore business applications or anything else using direct x that Gallium-Nine breaks.

The metrics I use are solid on what percentage of applications and games can be run.

Basically artivsion is saying I don't care who else workflow I break as long as the few programs I am interested in work. Of course that arguement means nothing to test driven development like wine. Wine project does not exist to service just 1 group of users exclusively.

I really hate to say this but, In that case then it's definitely time for gamer oriented fork of wine.