airlied My bad, from what I saw (by dates of commit) I assumed it is, but regardless, overriding core 4.1 GL profile would result in same bahviour, overriding in 4.1COMPAT would start applications. Changing GLSL version to 410 have no influence (application starts regardless). Change to 4.3COMPAT also starts applications. It works with compatibility profiles for some reason, but not with the core profile.
Announcement
Collapse
No announcement yet.
R600 Gallium3D Gets More Fixes, Experimental SB Tessellation Support
Collapse
X
-
Originally posted by leipero View Postairlied My bad, from what I saw (by dates of commit) I assumed it is, but regardless, overriding core 4.1 GL profile would result in same bahviour, overriding in 4.1COMPAT would start applications. Changing GLSL version to 410 have no influence (application starts regardless). Change to 4.3COMPAT also starts applications. It works with compatibility profiles for some reason, but not with the core profile.
- Likes 1
Comment
-
Originally posted by smitty3268 View Post
Sounds pretty clear cut to me that the app is broken and requires a compat profile which only works with the nvidia binary driver at the moment. If that's the case, you should submit a patch to Mesa's .drirc so that it automatically provides the necessary overrides for that application.
Comment
-
Originally posted by leipero View Post
But it also happens in wine for some D3D applications and not for other D3D applications, that doesn't seem so clear cut to me, why would wine act difenrently?Last edited by duby229; 14 January 2018, 03:49 PM.
Comment
-
Originally posted by duby229 View Post
It's because wine devs are primarily nVidia fanboys and they intentionally implemented compat profiles in a way that mesa won't support. They were trying to be ignorant when they made that decision. Wine -is- an emulator and it requires runtime behavior to be the same between native windows libraries and wine libraries. But because wine refuse to admit that it is an emulator they won't do that unfortunately. So it gives them the possibility to say, well it works on nVidia, so too bad so sad. Even though ultimately it was them who made that decision intentionally.
Comment
-
Originally posted by leipero View Post
Maybe, but genymotion does the same, I don't know, it requires more testing from others to confirm if that is really the case or not.
Comment
-
Originally posted by duby229 View Post
It's the same reason. Wine translates DX calls into GL calls. And they do it in a way that works on nVidia hardware, but will never be supported by mesa. And they do it on purpose specifically for that reason.
Comment
-
Originally posted by leipero View Post
Here is the problem tho, same happens with gallium nine, and correct me if I'm wrong, but wine translation is bypassed by it? So, mesa does everything in that case, wine is used as compatibility layer only. If that is the actual reason, I'm thinking other mesa users who are already on 4.1+ for example (any "GCN" GPU) would face the same problem, download genymotion (it's in AUR if on Arch), create VM (Android 7.1 for example) and try to start it, if that is the case as you say, it should crash and not work on those GPU's where GL 4.1+ is enabled by default?
- Likes 1
Comment
-
Originally posted by duby229 View Post
No, the bottom line is mesa doesn't support compat profiles and it never will. Gallium Nine is part of mesa and the wine libs for it are just wrappers. The wine devs need to fix their code but they won't because they can always just say well, it works fine on nVidia, so too bad so sad.... They did it that way on purpose....
Comment
-
Originally posted by leipero View Post
I'm not disputing what you are saying, but genymotion have nothing to do with wine, because of that reason I suspect on something else and that it should be investigated with more test systems.Last edited by duby229; 15 January 2018, 03:09 PM.
Comment
Comment