Wine-Staging Has Been Revived, Working Towards New Release

[nomadewolf]

I would like to see a link that proves your claims.

From what I've seen, Nine developers (the main one is @mannerov) have done everything they have been asked to and is technically feasible.

The Wine developers simply refuse to deal with Nine at all. They do claim there are some unresolved issues, but they do not and cannot tell you what these issues are, if you ask them. I have asked them. They might dig up some old threads that talk about issues that have been resolved years ago or where core Mesa3D and Radeon developers explain to them why doing that is bad idea.
If these are really the issues, then they are against the very concept of Gallium Nine and that cannot be fixed.

I heard from Wine developers a lot of concerns that, Gallium Nine is too niche, that it doesn't work on MacOSX, or with newest NVidia hardware and proprietary drivers. At that point I decided that they care only about NVidia.


---

About the people who have issues with Nine.
1. If for some reason Nine cannot work, it fallbacks to wined3d. So start wine in terminal and look for the green "enabled" text.
2. I do not like the vsync handling of Nine, so I disable it. At the moment Xorg Server 1.19.6 has a bug (should be fixed in next release) that causes game hang when vsync/vblank is enabled.
3. Nine also supports its own CSMT. Since 'meltdown' fixes (on intel cpus) it might be good idea to check if disabling it gives you better speed (`export csmt_force=0`)
4. If you are trying to find performance issues, I do recommend you to play with `GALLIUM_HUD`

In case it wasn't clear enough, i was trolling, of course.
Thanks for the explanation, though.

[oiaohm]

I've just did some quick test, and you are completely wrong duby229 is absolutely right in his comment. Using wine 3.2, here are the results for TMUF (rated gold or something with nvidia users telling it works great on high settings) with custom heavy on blocks (to stress CPU) map:

https://www.phoronix.com/scan.php?page=article&item=2018-start-mesanv&num=2

Now the thing you are overlooking is Nvidia in hardware and drivers at times is twice as fast as AMD at running opengl. So at times due to differences in drivers and hardware in the cards means something that is workable on Nvidia is not workable on AMD. This is not that wine is doing anything special for Nvidia its just how the hardware is.

It also makes you question how fast the Nvidia users would be going if they were not limited by the issues wine has with opengl.

Wine d3d:
Windows: 36-37 FPS at start, up to ~50 FPS stuttery mess whole map = unplayable.
GNU/Linux: 36-37 FPS at start, up to ~50 FPS basically the same FPS around whole map but a lot smoother compared to the Windows = barely playable.

This is only a recent change that both in fact perform the same back a year or two in drivers you would see AMD on Linux cleanly losing to AMD on Windows in opengl.

Gallium Nine/Native:
Windows: 59-60 FPS at start, up to 100+ FPS, smooth gameplay, playable.
GNU/Linux: 59-61 FPS at start, up to 100+ FPS, smooth gameplay, playable.

Both of these paths are bypassing opengl. Both are not cross platform.

That being said, there is a room for improvement in Mesa drivers, and surely there would be the case where nvidia have performance advantage with proprietary drivers, but not even close to as big as wine d3d presents it.

Wine doing a lot of shader builds runs straight into where Mesa has been weak and Nvidia drivers have been strong.

Intel has demo perform boost in open source drivers switching from TSGI to SPIR-v as the stage after GLSL. There are a lot of places in the way opengl is design that it consumes a heck load of cpu. Nvidia has been way better at optimising this down.

To fix HLSL shaders to opengl performance will need opengl 4.6 and the ability to use SPIR-v or at least AMD/Intel GLSL handling gets a intelligent as Nvidias.

http://community.monogame.net/t/dire...an-opengl/7951 You have well and truly underestimated how much being cross platform and having to be on top of opengl ruins your day. There are many cases documented where without doing any translation you are 50% slower doing the same tasks on opengl compared to direct x. Nvidia has extended the opengl standard to take out some of the worst areas so they got those extensions first. Those performance boost extensions most of the have ended up as part of mainline opengl version requirements.
The idea that the problem is because wine project targets Nvidia is false. There are some major issues with opengl. Wine company backer wants cross platform support what is something galluim nine has never offered. Wine project developers know you need unified DX stack due to what applications use. Both of these points puts you at head to head with wine development.

Opengl games normal perform by doing stuff different ways to the way you would under direct x to attempt to avoid opengl nightmares its not like wine can reorder all direct x game logic when sitting on top of Opengl.

Yes I know its not good to hear that being stuck on AMD cards has been giving you a weaker GPU so making performance problems worse. Add in driver design issues in the open source opengl then add in design issues in the opengl stack then add in to be cross platform wined3d has to sit on top of opengl only being 50 percent down at times is doing quite well.

Vulkan has had a lot of stuff redesigned. There is a good chance that properly made DX to Vulkan will be able to be close to direct X. Vulkan does not mandate a forced memory layout like opengl does as well. Yes converting from DX to opengl memory layout is another price wined3d has todo for cross platform.

Really galluim nine had part of the right idea. The graphic stack need alterations to work right. Same issues of opengl programs not being able to perform against direct x ones started vulkan.

Yes the claim that wined3d can never catch galluim on opengl could turn false. The company behind wine has been talking to Nvidia , Intel and AMD on what extensions to add to opengl to address problems. Of course opengl standard being a process of bureaucracy its not fast to alter it.

[leipero]

iyxwsoekthsv No offense taken, but you will be proven wrong simply by historical track record, and maybe lack of imagination on your side. The simple fact is that you are right that hardware and software progressed a lot since "deep blue", however that is not how technology works, it always progress at the "begining" and becomes stagnant after certain point, you can observe that with literally everything, from car industry, aircrafts, rockets or any mechanical machine, you can see that technology is literally stagnant for 70+ years on grad scheme of things..., even worse case is for electricity distribution and generation, ways of doing it, it's stagnant for well over 100 years, medicine is stagnant for quite a while now, but it didn't hit that threshold yet as mechanics and electronics, so it just got slower. So, basing on that, there's l8iterally no reason to assume that computer science would be any different, it will not, that's pretty much a given and 99% chance. Aside the factors that are conserned for this topic alone (since we are off topic), that follows the same pattern otehr technologies did in the past, so, in order to gain percivable difference in quality (2 times "better" graphics), you need million times increased complexity, so it is no longer proportional to what it was say only 10-15 years ago. Chess example is very bad example, because it was part of marketing, chess is very limited game anyway, it's the same example of marketing happening at this age with all talk about suposed "AI" (that inr eality have nothing to do with AI) and neural networks and other nonsense, while those applications might (and probably will) be useful for some specific tasks (like chess example), it is largely overhyped marketing, nothing more. At the end, it have nothing to do with imagination, and everything to do with historical facts. But we are wll off topic here.

To a very great extent that is in fact as a result of suboptimal use of both hardware as well as software.

I disagree, while suboptimal usage of hw/sw is the problem, that is not the main problem. The main problem is that you can only do so much before your changes make very little "real world" difference. For example, two dots by themselves are very limited in what you can do, 10 while still limited are notable improvement, 100 is a "night/day" difference, and so on (don't take these figures literaly tho, just an example), after million, the number of dots required to make percevable difference goes towards billion. That is the real problem.

The benchmark I was running is however fully 3D and accelerated and did in fact use Gallium Nine. And it too showed not a single shred of improvement. Regardless, even top down games such as PA and RW do actually rely on hardware acceleration, so should benefit from properly implemented APIs.

Yes, but benchmark is not the same as real world game, as I've mentioned already, in 3DMark03/06 there's almost no difference between wine d3d and nine. Top down games while using hardware acceleration, they hardly use any significant portion of lowest end GPU's (most of the time, it depends on game really), so benefit will be negligible. So in your case, you are right, wine d3d will work just fine.

oiaohm

Now the thing you are overlooking is Nvidia in hardware and drivers at times is twice as fast as AMD at running opengl. So at times due to differences in drivers and hardware in the cards means something that is workable on Nvidia is not workable on AMD. This is not that wine is doing anything special for Nvidia its just how the hardware is.

I am not overlooking that because that simply isn't the case, there is no scenario where nvidia driver is "twice as fast", that's just fabrication on your side now. Twice as fast assumes same hardware power, and that just isn't the case for quite a while now. So I am not ignoring that, it seems that youa re ignoring the fact that wine d3d is done for nvidia hardware, and that is the main reason why it sucks on AMD.

This is only a recent change that both in fact perform the same back a year or two in drivers you would see AMD on Linux cleanly losing to AMD on Windows in opengl.

No, that is completely untrue, since I'm testing this game on wine from time to time for years, it always did suck on my hardware via wine d3d translation layer, while planty of nvidia users claiming it works "perfect" with far slower hardware on winehq alone. You are attempting to convince me (and otehrs) in something that simply isnt true and you have hard data as an argument that you choose to ignore.

Both of these paths are bypassing opengl. Both are not cross platform.

So??? The point is, both of those paths are bypassing WINE D3D translation layer that's my point!

You have well and truly underestimated how much being cross platform and having to be on top of opengl ruins your day. There are many cases documented where without doing any translation you are 50% slower doing the same tasks on opengl compared to direct x...

That would all be fine and dandy, if there isn't the case where some poorly ported OpenGL games to be "Linux native" do not work exactly as in windows, and better in Wine than in "linux native" case. "Some examples" do not account for something that is universal, and for D3D games, wine UNIVERSALLY sucks on AMD hardware most of the time, while OpenGL games do not have those problems most of the time.

So let me sumarize:
OpenGL driver works fine under OpenGL wine games, so that can't be blamed as you do now.
Wine D3D add much larger performance hit on AMD GPU's, despite the fact that OpenGL games work at almost the same speed as in Windows, so it simply can't be blamed on drivers. When wine d3d is bypassed games magically start to work fine under wine on AMD hardware, in fact on native speed (the fact that Wine Is Not an Emulator)

It seems that you have choosen your narative, and choosed to ignore all hard data presented to you by multiple users here, so I don't know how productive this conversation will turn out to be to be honest. You keep finding excuses to blame Mesa and anything other than wine itself, and at the same time calling what is experience of majority of users a conspiracy or myth.

We all aknowledge there is a room for improvement in Mesa, that's not even in question, the question is if there is a room for improvement in wine d3d translator, and why nvidia users have benefits in it.

[oiaohm]

So let me sumarize:
OpenGL driver works fine under OpenGL wine games, so that can't be blamed as you do now.
Wine D3D add much larger performance hit on AMD GPU's, despite the fact that OpenGL games work at almost the same speed as in Windows, so it simply can't be blamed on drivers. When wine d3d is bypassed games magically start to work fine under wine on AMD hardware, in fact on native speed (the fact that Wine Is Not an Emulator)

You kind got to asking the right question why is wined3d taken such a hit.

You need to read all of this.
https://msdn.microsoft.com/en-us/lib..._Index_Buffers

I have pointed to particular point that will be related latter. So Microsoft has told developers how they should lay out their code for optimal performance on Direct x 9.

https://comminos.com/posts/2018-02-2...profiling.html
As you can see a developer has notice that one of those features can now be implemented in opengl.

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_buffer_storage.txt

That feature only was added in 2013 for opengl 4.4 yet it was in dx 9 in 2002.

So until this development this year wine is having to use a non optimal code way of doing this. If you were coding an application purely in opengl you would avoid this path completely before opengl 4.4 features got added to opengl .

Nvidia GPU drivers optimising for non optimal code is way ahead of AMD ones. So you have a non optimal opengl program it will run twice as faster on Nvidia as it does on AMD, Most people who benchmark benchmark with optimal programs. So they don't see where the AMD drivers are absolutely horrible.

Some of your less known games with opengl as switch to optional next to direct x 9 show the same nightmare of where Nvidia opengl perform great on windows yet AMD opengl performs at half speed. So the issue you are talking about is not in fact wined3d unique. Just wined3d is most like thing to give you opengl system horrible instruction orders.

So your idea that there is no case where Nvidia is twice as fast as AMD is in fact false.

Galluim nine was on the right path to a point there are issues with mapping direct x to opengl mostly missing features that have one hell of a performance kick in the teeth due to being the missing and having to be worked around. Nvidia due to there driver handles this better. This is not designing for Nvidia. The fact direct x application under wine show same bad behaviours is party because Microsoft optimisation guides lead them to coding programs dependant on gpu card features that wined3d to run on opengl has to emulate in software and replace with multi opengl commands. Of course this emulation causes higher cpu usage and lower gpu usage.

You can think of wined3d usage of opengl as the worst possible order of opengl instructions a video card driver will have to deal with.

Its really simple to take the theory that I am suffering because they are design for the competitors card. This case is the nightmare of opengl if you feed it code done the wrong ways it does not perform on AMD yet Nvidia copes. Now with the fact that direct x9 applications have a microsoft recommend design that fairly much says lets code in ways that can never work well before opengl 4.4 because things will be done in incorrect orders you need a very tolerant driver. Open source graphics driver and closed source ATI/AMD drivers have never been tolerant beasts.

When you look at the HLSL you work out this cannot be done optimal until we have opengl 4.6. The question is what ones of these non optimal paths forces on wined3d are causing the worst performance hit.

Please note wined3d first being done single thread instead of multi threaded as dx9 design mandates also come up from the fact that opengl be it open source or closed feed it multi thread contexts under OS X or Linux would fall over and die.

So the gap between galluim nine and wined3d will reduce. Remember wined3d cannot implement parts until the opengl driver is providing those parts.

[leipero]

oiaohm

So your idea that there is no case where Nvidia is twice as fast as AMD is in fact false.

Ok, than give me reproducable case outside of wine, obviously in wine nvidia could be 4 times faster...

Its really simple to take the theory that I am suffering because they are design for the competitors card. This case is the nightmare of opengl if you feed it code done the wrong ways it does not perform on AMD yet Nvidia copes.

I'm not sure, someone might get exact quote, but that assertion comes from wine developers, where they publicly admited they are doing everything on and for nvidia hardware.

So the gap between galluim nine and wined3d will reduce. Remember wined3d cannot implement parts until the opengl driver is providing those parts.

Well, we are waiting for that gap to be reduced for a while now, however, that gap doesn't bother me, what does bother me is the universal gap between nvidia and AMD similary powerful hardware under wine d3d, while that (and especially that big of a) difference can't be reproduced under most of the other conditions.

Besides, if you are using non-optimal code path that works better on one chip design/drivers, instead of optimal one, what does that say about your developement? So you are choosing sub-optimal paths for compatibility sake, while knowing that those sub-optimal ways would universally favor one chip designer/drivers over the other, and your rational for allowing such thing would be probably market share, while at the same time you refuse any of the community done work as "sub-optimal"? I don't know man..., why that hypocrisy? This is exact conclusion that would suggest what duby229 said is true from my perspective.

I've aknowledged all of your suggestions in the past and did some test, and from this limited testing this is how things stand for now.

PS: Your 3rd link doesn't work.

[oiaohm]

oiaohmOk, than give me reproducable case outside of wine, obviously in wine nvidia could be 4 times faster...

You will find some of equal in digial currency mining with GPU acceleration. Where some of those also use non optimal paths. Worst if I could find the link was 64 to 1. Yes AMD 64 times slower. If you really pick on the AMD closed and open source drivers weakness at handling badly optimised code you can almost stop the GPU dead.

Nvidia no matter how you attempt to abuse you will not drop it performance under 1/4. How Nvidia makes this work is being smart enough in driver to pickup hang you you are request operations in X order I don't have to respect that and does a form speculative execution so allow it to absorb the blow of getting instructions from opengl that are technically in the wrong order and totally non optimal.

Well, we are waiting for that gap to be reduced for a while now, however, that gap doesn't bother me, what does bother me is the universal gap between nvidia and AMD similary powerful hardware under wine d3d, while that (and especially that big of a) difference can't be reproduced under most of the other conditions.

You have made a presume because you have not seen how non-optimial code ruins the way AMD driver works. Also there are example in different fields using GPU acceleration where the gap with AMD vs NVidia due to weak non-optimial handling in the AMD drivers and the complete open source drivers makes wine performance difference look quite minor.

Please note you said cannot be reported under most other conditions. This fairly much admits to me that you know that there are different cases where the issue turns up. Just wined3d is very good at finding it.

Besides, if you are using non-optimal code path that works better on one chip design/drivers, instead of optimal one, what does that say about your developement? So you are choosing sub-optimal paths for compatibility sake, while knowing that those sub-optimal ways would universally favor one chip designer/drivers over the other, and your rational for allowing such thing would be probably market share, while at the same time you refuse any of the community done work as "sub-optimal"? I don't know man..., why that hypocrisy? This is exact conclusion that would suggest what duby229 said is true from my perspective.

The thing you have missed is the code is non optimal for both Nvidia and AMD opengl drivers out of wined3d. Nvidia copes better but they are not perform where they should.

https://comminos.com/posts/2018-02-21-wined3d-profiling.html

Do check out this note he is using Nvidia he is profiling wined3d and direct in face it doing non optimal very non optimal. Most games if you profile that are perform like 50 percent slower with AMD vs Nvidia with wined3d you will in fact see that both drivers have non optimal code when you profile them. Nvidia closed source drivers at this stage is better at coping with non optimal. In some ways this could be that the AMD driver still need to improve to deal with corner cases Nvidia can cope with.

Yes you do a apitrace and you can see the instructions that wine is giving to both drivers and you can confirm that wine is not showing either any favouritism. Just using functions as per opengl standard just in a order the cards drivers don't like. Its not like wine can start really caching all gpu request and reordering them from the application as this would add insane latency. This is a true rock and hard place problem.

The reality has not be possible to translate direct x to opengl and be optimal until the right extensions appeared and that code is implemented in wined3d.

With opengl wine developers have had a long term road map of getting features over time added to reduce the impact but this was not for just 1 version of direct X. This is for all version of Direct X wine supports.

Reality with apitrace you can confirm that its not favouritism. At times apitrace replays are sent to open source driver developers by codeweavers so they can attempt to locate exactly why this stuff goes so nightmare.

Galluim nine is not cross platform and does not appear to have a suitable design for long term maintenance. Cross platform support means that wine would still have to maintain opengl support even as non optimal.

Problem here is the wine developers are not sure if Galluim nine higher performance is just because they have not got all the opengl extensions in use as they should be yet. Of course they had to get multi threading working first. Remember multi thread was disabled because dri1 opengl drivers under Linux did not support it. So this has been a very long term project to improve opengl.

Optimising the open source graphic stack on Linux is no where near complete for corner cases. Yes wined3d hits a particular corner case. Of course how many corner cases wine will be hitting in drivers will be reduced as opengl extensions usage gets implemented that means wine does not have to do the work around what means wine can do more optimal code.

Now for compatibility wine project wants to keep the means if it has to that it can operate on a system with only opengl 3.3 so fall back to non optimal that runs.

Remember its compatibility services that codeweavers get paid for.

[leipero]

oiaohm Ok, so there's no concrete reproducable example in 3D graphics. I'm not saying that it's impossible tho...

No, I do not know about any cases where that sort of thing happens, I'm just open to the posibility that it might happen, and that it is not imposible, for my personal experiences on Windows over a decade, It was quite clear that AMD (at the time ATI) drivers were better for different reasons mainly input lag that was unbarable on nvidia GPU's as well as high FPS stutter, can't speak for now since I avoid them as a plague for quite a while, it is possible that it is far better now, but that's different topic anyway.

Do check out this note he is using Nvidia he is profiling wined3d and direct in face it doing non optimal very non optimal. Most games if you profile that are perform like 50 percent slower with AMD vs Nvidia with wined3d you will in fact see that both drivers have non optimal code when you profile them. Nvidia closed source drivers at this stage is better at coping with non optimal. In some ways this could be that the AMD driver still need to improve to deal with corner cases Nvidia can cope with.

At this point I have no clue what you are talking about, I'm sorry, but I don't, I am not a programmer. There are things called "standards and specifications", if driver follows specification of one API (OpenGL in this case), and if wine D3D translation is implemented to compliment that specification, it is only internal code of D3D adapter in wine that might have a problem or not.

Again, if that is the case (driver problem, not wine problem) same thing wouldn't happen in windows, and as I showed in earlier posts, there's basically performance parity between windows and GNU/Linux in both wine D3D and native/gallium nine, suggesting that problem isn't in drivers at all, but purely in wine d3d. I really do not see how what you are saying could be true, and no one is saying it is intentional favoritism (but might as well will be), it's that it is made for nvidia GPU's and tested on them, that's all.

[oiaohm]

At this point I have no clue what you are talking about, I'm sorry, but I don't, I am not a programmer. There are things called "standards and specifications", if driver follows specification of one API (OpenGL in this case), and if wine D3D translation is implemented to compliment that specification, it is only internal code of D3D adapter in wine that might have a problem or not.

Opengl standards define functions applications can use. The standard does not define any optimal order to call those functions in. So you can be using totally to standard opengl functions in whatever order you think is suitable and if that be causing the GPU or memory transfer system to the GPU to totally stall that is the fault of the opengl driver by standard. Now is the opengl driver code with opengl standard that is meant to cope with no matter the stupidity applications throw at it. Nvidia driver is better at coping with non optimal code thrown at it.

Again, if that is the case (driver problem, not wine problem) same thing wouldn't happen in windows, and as I showed in earlier posts, there's basically performance parity between windows and GNU/Linux in both wine D3D and native/gallium nine, suggesting that problem isn't in drivers at all, but purely in wine d3d. I really do not see how what you are saying could be true, and no one is saying it is intentional favoritism (but might as well will be), it's that it is made for nvidia GPU's and tested on them, that's all.

Lot of the optimisation design in AMD is shared between there drivers. So you have drawn a incorrect presume. AMD have not had in their closed drivers good dealing with opengl functions being called in non optimal orders be this windows or Linux. So of course you see the same effect under windows and under linux of more damage from non optimal than Nvidia drivers.

Yes there are some issues with opengl not having particular features so requiring wined3d todo longer and nastier paths to remain using opengl code but these longer and nastier code is the same longer and nastier code given to AMD and NVIDIA drivers if there was not a difference in how these opengl drivers coped with nasty code you would not be seeing the performance difference between NVIDIA and AMD..

The nasty code a lot of cases not to written to optimal order and due to having using direct x function ordering of requests not possible to put into optimal order while missing the opengl function to perform the task in a equal way to what direct x would have. Yes Direct x function calls are optimised on the presume that you can perform particular tasks at particular ways and when opengl cannot due to no feature like that wined3d is in hell.

Some of the nasty order can be attempting to run shaders before all they need is transferred to graphics card. Using out order on the GPU help here cannot run x on gpu run y that will be used in future because everything it needs was already transferred to the GPU until everything for x is transfered. A proper optimal design program is not meant to do this kind of abuse to the graphics card drivers but nothing in the opengl standard says its wrong.

This is why its kind of important to profile like making apitrace record and playing the record back on Nvidia and AMD and notice have a performance difference then checking and find out it was only using pure to opengl standard functions to cause the stall. That is what a lot of us have found who profile.

Yes some of the problem is in wined3d with feature that historically could not be implemented in opengl because the functions did not exist and have not yet been implemented using the new opengl functions. This stuff does not explain the difference in performance between AMD and NVIDIA with wined3d since wined3d is throwing equally bad at both.

The presume that wined3d was built for NVIDIA and that would explain the performance difference is also not backed by a API trace and perf where you can see Nvidia is in fact performing badly and is having standard conforming functions thrown at it just like AMD to cause this bad performance.

Thing to remember NVIDIA spent a lot of resources optimising badly coded games early on where ATI did not this logic is still in the Nvidia drivers. So you give Nvidia and AMD cards nice optimal design stuff they can perform as you expect. You give them non optimal stuff and you watch the AMD card suffer massively.

The first mistake most make since people are report games useable with NVidia that the results they are getting are performing well. Profiles of gpu and memory transfer usage on Nvidia shows a clear picture with wined3d even when a game with nvidia is running to users acceptable it currently not where near optimal.

When you do the same profiling on AMD you see the performance hits are in the same places as the Nvidia just due to the way AMD drivers handle they are handling it worse so the performance dips are larger but to execution they are happening at the same points. Basically the same non optimal order is riping the bits out Nvidia performance as well as AMD card performance difference being Nvidia is better at masking over issues.

So the bias to Nvidia is not backed by looking at the profile information. If it was you would not be seeing the dips performance in the same places in execution just with a different magnitude value. This profiling tells that you are looking at a opengl driver issue as well as wined3d issues. The opengl driver issue explain why AMD and Nvidia with wined3d perform differently.

I do agree working out how to use more opengl extensions to stop using as many code paths that are non optimal in wined3d ways of reducing the harm from the wined3d side. But it may not be possible for wined3d sticking to opengl to do everything in optimal order then fixing the AMD side/open source drivers side could be important.

[duby229]

Opengl standards define functions applications can use. The standard does not define any optimal order to call those functions in. So you can be using totally to standard opengl functions in whatever order you think is suitable and if that be causing the GPU or memory transfer system to the GPU to totally stall that is the fault of the opengl driver by standard. Now is the opengl driver code with opengl standard that is meant to cope with no matter the stupidity applications throw at it. Nvidia driver is better at coping with non optimal code thrown at it.

That's not true at all. Or at least at the minimum, that's not accurate at all. The truth is that nVidia and AMD both profile games and then they use driver hacks to fix them. What it means is that those games are -broken- and relying on driver hacks is relying broken behavior..... And it's entirely the fault of nVidia and AMD.....

[leipero]

oiaohm Ok, then use "non-optimal" code example, this should be reproducable..., it should be reproducable in GNU/Linux native way.

As far as I understand, wined3d is suposed to translate DX calls to OpenGL calls, and that's about it.

The problem here is that we hear abouth those mythical bad drivers, while ignoring Intel GPU's, so it might turn out that acording to the wine developers, everyone have "bad drivers" except nvidia, and somehow, that doesn't translate into native OpenGL applications most of the time...., amusing to say the least.

It's true that I take words "It's working perfect" in my subjective way that migh be very different to the person who presented that sentence, and yes, it is probably wrong to take it as such, even those FPS measurments.

So, this is shorten conclusion reader should draw from your posts: Wine d3d use non-optimal path, but because nvidia driver is so great, it just works well, while other drivers and GPU's suck.

For this to be true, it would require tests of both native WIndows and GNU/Linux GL applications, testing of wined3d in both Windows and GNU/Linux on all 3 vendors and possible drivers (close and open), doing same tests in both CPU starwed scenario (with both single and multi threaded starwed tests) and CPU non-starwed scenario, and comparing percentages. That would reveal the problem for sure.

If your theory is true, than on nouveau (with supported GPU's thata ctually have proper driver) same problem would happen, and I somehow doubt about that..., I don't have resources for doing such tests.