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

[duby229]

The thing is you can run wine test suite on gallium nine and see it increased failures then remember wine test suite the actions it checking for were talking from applications. So gallium-nine does not have better over all compatibility. A small pool of applications is really easy to have tester bias but when you get to the larger pool of applications wine supports gallium-nine starts looking down right horrible..

The techincial limitations and no plan to address them is what forbids galluim-nine entry into wine. If something has major technical issues with no plan to address them like galluim-nine is only right to reject merging it in until they come up with a plan to fix. Basically if you admit those technical limitations exist its very hard to say that wine is wrong on refusing merge.

Wine test suite could do with more tests added. There are most likely behaviours galluim-nine does that are missing from the test-suite and that would allow application compatibility to be improved. The wine test suite is a database of known and provable MS windows behaviours.

A small number of applications doing better performance and better compatibility will not move wine developers a inch from the rejected if that fix breaks other applications. Why wine project is demanding correct behaviour. Half correct behaviour is not good enough. Wine project values correct behaviour to how windows behaves check-able by test application in test suite over performance.

I understand for the most part. Most modern GPU's are going to have at least semi-reliable or better Vulkan drivers, if they don't already. (even though they won't all be mesa drivers) And Vulkan is pretty low level, between it and SPIR-V it can do everything Gallium can and more. Until then I just don't see the current results as a working solution. The Gallium path is basically dead and gone, but until the Vulkan path becomes viable gallium nine is still the better option.

I really have high hopes for Vulkan in general. I hope those devs with the right skills are able to write solutions that wine will accept.

[Hi-Angel]

I really wish Gcc would implement the C++11 garbage collector. Mostly for sanity. So you don't end up with internal gcc garbage collector sneaking into libstdc++ or some developer hack up equal to a garbage collector being in libstdc++. So its like this is the garbage collector for lbistdc++ if you need one use it.

Basically it bad enough dealing with having a garbage collector without having the nightmare of not knowing where it used or what garbage collection is in use.

It is also particularly fun when someone uses a C++ library of random and you find out http://www.hboehm.info/gc/ some garbage collection library has come in as well.

So its not like g++ does have garbage collection implemented in different places it does just it has no unified mandate standard for it. You really don't want that when you are attempting to join between binary from two different compilers.

I am confused. This garbage collector can only "sneak up" if you use gcc internals, which is not what we are talking about.

Can you provide for clarification a minimal example where that would cause a problem?

[oiaohm]

I am confused. This garbage collector can only "sneak up" if you use gcc internals, which is not what we are talking about.

Can you provide for clarification a minimal example where that would cause a problem?

I would have dig back though my experimental notes of tracking why MSVC c++ and Gcc c++ made parts could not join up. With multi threading and memory interactions what is internal can become issues. Its one of the nasty effects of a garbage collector and it mixing with non connected freeing system and you mix in multi threading. I might be remembering wrong that is gc on the gcc c++ side it might be that gcc c++ free stuff without a means to inform garbage collector. I could have miss read that as some other form of collection.

Yes these miss match issues do get complex. Being in C without constructors, destructors, garbage collectors you are in full control when all those events happen so can match behaviour. That is the problem for something like wine C++ may not be that much of advantage in fact the extra features of C++ provide a lot of extra areas for conflicts with what you need todo.

[Hi-Angel]

I would have dig back though my experimental notes of tracking why MSVC c++ and Gcc c++ made parts could not join up. With multi threading and memory interactions what is internal can become issues. Its one of the nasty effects of a garbage collector and it mixing with non connected freeing system and you mix in multi threading. I might be remembering wrong that is gc on the gcc c++ side it might be that gcc c++ free stuff without a means to inform garbage collector. I could have miss read that as some other form of collection.

Yes these miss match issues do get complex. Being in C without constructors, destructors, garbage collectors you are in full control when all those events happen so can match behaviour. That is the problem for something like wine C++ may not be that much of advantage in fact the extra features of C++ provide a lot of extra areas for conflicts with what you need todo.

Okay, thanks, one thing that is clear — one simply needs to make sure that exports/imports and fields of dlls created from C++ do match ones that would've been created from C. That would've solve those problems with GC and mangling.

[oiaohm]

I understand for the most part. Most modern GPU's are going to have at least semi-reliable or better Vulkan drivers, if they don't already. (even though they won't all be mesa drivers) And Vulkan is pretty low level, between it and SPIR-V it can do everything Gallium can and more. Until then I just don't see the current results as a working solution. The Gallium path is basically dead and gone, but until the Vulkan path becomes viable gallium nine is still the better option.

I really have high hopes for Vulkan in general. I hope those devs with the right skills are able to write solutions that wine will accept.

But you do understand why wine cannot just accept gallium-nine. Not when gallium-nine breaks so much. You need the pressure in the hope someone will make a correct solution or go about the effort to fix because path is blocked. The VK9 and the Dx11 to Vulkan by third parties and the dx12 to Vulkan by main developer at least have a better chance of working with each other without needing to perform major source code modification and at least have the bits that need to be shared in the right form to share with opengl so should be able to be made shared with everything else existing in wine.

If there is a leason from gallium-nine blocked entry into wine is don't attempt to apply pressure. When lead developer refuses patch and is questioning construction of path something very serous can be wrong. Slacker particularly is not codeweavers staff. So was not company interest..

The big thing that went wrong with gallium-nine is there was a lack of understanding at the start how dx 9 was required to integrate with everything else in the system. When you make a core mistake like that the fix is never painless.

Second big thing was attempting to just present benchmarks of programs they got working and say hey since this is faster and renders without some bugs wine has you have to merge. If a project has the policy that all submitted patches have to pass test suite like wine don't think any amount of pressure will change you patches rejection. If you solution breaks the test suite you either have to fix the test suite or fix your patch.

I hope the new vulkan dx attempts don't make the same mistakes galluim-nine did interacting with wine. Instead plays by the rules and everything should go nicely.

[oiaohm]

Okay, thanks, one thing that is clear — one simply needs to make sure that exports/imports and fields of dlls created from C++ do match ones that would've been created from C. That would've solve those problems with GC and mangling.

The thing you are getting is not just the dll import/exports. The behaviour inside the function has to be a reasonable approximation of what the MSVC C++ function would have done and too much variation will cause problems.

https://stackoverflow.com/questions/5107948/throwing-c-exceptions-across-dll-boundaries

Different sections of memory pointers passed across have to remain intact to be passed back as expect for exceptions. MSVC all parts using the same C++ runtime are not isolated from each other. A MSVC program may be watching GC to see if something is frozen or not. So not freeing stuff inside your function using the GC can result in a never ending loop of a subprocess being terminated because it frozen.

Basically there is not a clean separation between the exe and the dll files when you are talking C++ in MSVC that wine has to replicate this in places. GC is internal behaviour of the functions. Copy something to a new block of memory free the prior block on the idea that the function will return different can also cause issues.

[Hi-Angel]

The thing you are getting is not just the dll import/exports. The behaviour inside the function has to be a reasonable approximation of what the MSVC C++ function would have done and too much variation will cause problems.

https://stackoverflow.com/questions/5107948/throwing-c-exceptions-across-dll-boundaries

Different sections of memory pointers passed across have to remain intact to be passed back as expect for exceptions. MSVC all parts using the same C++ runtime are not isolated from each other. A MSVC program may be watching GC to see if something is frozen or not. So not freeing stuff inside your function using the GC can result in a never ending loop of a subprocess being terminated because it frozen.

Basically there is not a clean separation between the exe and the dll files when you are talking C++ in MSVC that wine has to replicate this in places. GC is internal behaviour of the functions. Copy something to a new block of memory free the prior block on the idea that the function will return different can also cause issues.

Then don't throw exceptions out of dll! My point is about using more powerful language to achieve same thing that is now achieved with C. If there're specifics that might cause problems, such as imports of stdc++, or exceptions — prohibit their usage.

[Hi-Angel]

oiaohm anyway, talk is cheap. If somebody would send a patch written in C++ that does not affect tests or behavior with MSVC (not negatively anyway), would it be accepted upstream?

[duby229]

The thing you are getting is not just the dll import/exports. The behaviour inside the function has to be a reasonable approximation of what the MSVC C++ function would have done and too much variation will cause problems.

https://stackoverflow.com/questions/5107948/throwing-c-exceptions-across-dll-boundaries

Different sections of memory pointers passed across have to remain intact to be passed back as expect for exceptions. MSVC all parts using the same C++ runtime are not isolated from each other. A MSVC program may be watching GC to see if something is frozen or not. So not freeing stuff inside your function using the GC can result in a never ending loop of a subprocess being terminated because it frozen.

Basically there is not a clean separation between the exe and the dll files when you are talking C++ in MSVC that wine has to replicate this in places. GC is internal behaviour of the functions. Copy something to a new block of memory free the prior block on the idea that the function will return different can also cause issues.

Just speculating here, but that sounds like a good LLVM project, a fully MSVC compatible front end for it would solve your problems.

[oiaohm]

Then don't throw exceptions out of dll! My point is about using more powerful language to achieve same thing that is now achieved with C. If there're specifics that might cause problems, such as imports of stdc++, or exceptions — prohibit their usage.

Thing here is its the one who wrote the MSVC dlls you are implementing compatibility with so application can run with wine code instead have decide what you have to throw across dll/exe boundary. So GC and exception interactions have to match. If you break that you will cause problems. This is one of the major differences doing something like wine you have limitations based on achieving compatibility.

Prohibit their usage of everything that can cause problems you end up fairly close to C in the first place. So you don't have the advanced features of C++.

oiaohm anyway, talk is cheap. If somebody would send a patch written in C++ that does not affect tests or behavior with MSVC (not negatively anyway), would it be accepted upstream?

So far no one has attempt to submit a patch like that required C++ other than something like winegecko or wine-mono that is based on outside projects. One case for a mainline patch the code was that close to C it was like a 2 line change and it was C.

Please note the wine project is not totally adverse to C++ just there has never been pure reason out side winegecko and wine-mono. But there are a lot of issue you can cause with careless use of C++ in environment where you have to replicate behaviour.

Just speculating here, but that sounds like a good LLVM project, a fully MSVC compatible front end for it would solve your problems.

Not easy format of GC and exception handling and other parts send across exe/dll boundary with MSVC C++ change with MSVC version. There are 14+ version different implementations of MSVC C++ support inside wine itself by C implementations. These fragments of different versions of MSVC C++ interfaces are on different system dlls.

I am not saying your idea would not be nice duby229. Just the level of effort required to make what is wine requirement is makes writing C code emulating different versions of MSVC C++ behaviour look simple.