Wine 3.3 Brings First Vulkan Bits, D3D CSMT By Default

[oiaohm]

wine-staging is better, it runs most of the games with a single wine prefix. Sometimes you need to have 32-bit wine prefix in a 64-bit system. With playonlinux you waste your drive storage with many prefixes and playonlinux increases the maintenance complexity when something goes wrong. Keep it simple.

Here goes the clueless. The first maintainer of staging also recommend application per WINEPREFIX not using a single one. This is not due to winetricks workarounds this is due to applications having automatic updates and at times they update shared parts resulting in program 1 failing because program 2 updated.

Just because you have been lucky doing something does not mean it recommend. Lets use a selling point that is invalid.

[oiaohm]

You need wintericks only once, to install all dlls that games need. Then with wincefg configure dll overrides and other settings per .exe file. winehq appdb and other forums give configuration instructions.

Yes people do the same stunts with vanilla wine and get bitten sooner or latter. Nasty fact here more winetricks dlls does not equal better in many cases.

That something works does not change that the recommendation for testing is 1 game per WINEPREFIX that the reason why the game is not work is not interaction. What you have just told me that your test results are worthless.

Does Origin and Uplay games work with vanilla wine? If not, make them work instead of hanging here.

Reality I don't have a single Origin or Uplay game. So I cannot perform any testing. You are not doing bug report correct so you are absolutely worthless. You are not willing to do per application per WINEPREFIX so your worthless.

Really if someone wants Origin and Uplay to work we need someone is willing to do proper bug reports and proper testing when developers ask. Not idiots like debianxfce who love giving invalid advice.

I am support person I am not a coder for wine. So tell me to go fix it is going to get you absolute no where. Only way to get somewhere will be submit correct test and bug reports and suggested patches.

[oiaohm]

You need wintericks only once, to install all dlls that games need. Then with wincefg configure dll overrides and other settings per .exe file. winehq appdb and other forums give configuration instructions..

Does not make this useful process. All it tells me is there is no point asking debianxfce to test out prototype patches because he will have a stack of applications mixed in one prefix so could be giving no false reports that something does not work when its fully functional and the reason its not working is that debianxfce is disobeying recommend process.

Does Origin and Uplay games work with vanilla wine? If not, make them work instead of hanging here.

Reality I am support I am not coder for wine. So give people advice on how to submit valid bug reports and valid testing and valid bug assocations to give the best odds of something being fixed. The reality is not me who has to-do anything. I don't own any Orgian/Uplay games I cannot do testing for developers.

So reality here you have the games debianxfce. You have the possibility of doing correct bug reports and performing tests as requested by developers. So the one who should not be here if you want Origin and Uplay games to work in vanilla wine is none other than you debianxfce.

Its about time debianxfce stops attempting to get other people to-do tasks that debianxfce should be doing.

[oscar]

It doesn't. This is the official ChromeOS with Android support. It required a bit of fiddling to get it running on a Windows laptop. At first there was no wifi nor sound and dmesg was spamming errors but I got those taken care of. However, I'm playing with things to see if I can get the container working on Chromium OS Special Build, which runs on-top the 4.14 kernel.

Hi Xaero_Vincent,
I followed your efforts on github related to gvt-g+dma_buf+androidx86.. you seem to pick good pet projects..
now seeing your ChromeOS Android efforts, I'm very interested in knowing "required a bit of fiddling".. can you please post some gist on github with details for others to replicate..
if not at least can you answer two things about ChromOS Android test:
1) ChromeOS works with GVT-g on QEMU+dma_buf similar to Android-x86..
2)ChromeOS Android supports Android Vulkan apps.. is working also in your laptop (i.e can you for example run VulkanCapsViewer)..
thanks..

[artivision]

Friendly advice for Codeweavers: Hire Immediately those who develop DXVK / VK9 / MoltenVK and remake WineD3D upon universal Vulkan dropping the old OpenGL api. You will cut development time by 5-10x and wile dropping non Vulkan Gpus you will still open Wine to more users supporting today's low end and middle range systems. You should know that there is a danger to go out of business.

[oiaohm]

Friendly advice for Codeweavers: Hire Immediately those who develop DXVK / VK9 / MoltenVK and remake WineD3D upon universal Vulkan dropping the old OpenGL api. You will cut development time by 5-10x and wile dropping non Vulkan Gpus you will still open Wine to more users supporting today's low end and middle range systems. You should know that there is a danger to go out of business.

Everything is lock stepped. Building on top of Vulkan would not alter the need to implement CSMT and buffer controls and other fragments to suit Direct X. So workload swapping from opengl to vulkan would be less than 10 percent alteration in development time cost. Going after personal from MoltenVK might be useful. But going after DXVK and VK9 that have taken the point of view its fine to cut corners in development may not be a good move long term.

Before wine can start major work building on Vulkan the interfaces from wine to platform native Vulkan have to be sorted out.

https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop.txt

Also it might be impossible to drop opengl support and support all DX8, 9,10,11 applications. Yes welcome to the mega nasty curve ball. Its perfectly valid for applications to be using a hi-bred of opengl and direct x.

The devil is in the details artivision. So unless you have a plan that includes opengl working with direct x and more done on vulkan you are kind of in trouble.

This is the problem with DXVK and VK9 when you start getting the details of dropping the opengl path completely comes hard because direct x and opengl are not always separate things under Windows due to the extensions that were added to opengl.

Its really simple to say do X without in fact knowing the complete list of requirements to have as many applications as possible work.

[dungeon]

Why you have disabled fog there, is nvidia driver after near decade still broken for the case?

https://forums.geforce.com/default/t...hin-fog-issue/

[Dukenukemx]

Have you tried BlueStacks?

Does Bluestacks work on Linux?

[Xaero_Vincent]

The question is, why? It's basically Gentoo Linux with Chrome OS bits. As for running Android apps on it, that is cool but nothing new. On Windows you can run NoxPlayer and it does a pretty good job. On Linux I'm still trying to find an equivalent, but on distros like Ubuntu or Mint.

There is Anbox, Slashlik, and Genymotion but they don't work really well IMO. The Android emulators on Windows use a virtual machine engine like QEMU or Virtualbox and OpenGL ES API tunneling, which adds overhead. The Chrome OS container solution runs it at essentially native performance with direct access to hardware and kernel drivers. There is some minor overhead with the Libhoudini ARM to x86 translation layer used to run ARM-only Android apps on Intel CPUs.

Chrome OS is an interesting operating system. Yes it's based on Gentoo Linux but it's quite unique with it's Freon display server, Android container. It's also gaining a Linux container to run Linux applications without an insecure chroot, plus there is built-in Wayland support on the main Chrome OS desktop.

https://nmilosev.svbtle.com/crouton-fedora-wayland-yes-please

[artivision]

Everything is lock stepped. Building on top of Vulkan would not alter the need to implement CSMT and buffer controls and other fragments to suit Direct X. So workload swapping from opengl to vulkan would be less than 10 percent alteration in development time cost. Going after personal from MoltenVK might be useful. But going after DXVK and VK9 that have taken the point of view its fine to cut corners in development may not be a good move long term.

Before wine can start major work building on Vulkan the interfaces from wine to platform native Vulkan have to be sorted out.

https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop.txt

Also it might be impossible to drop opengl support and support all DX8, 9,10,11 applications. Yes welcome to the mega nasty curve ball. Its perfectly valid for applications to be using a hi-bred of opengl and direct x.

The devil is in the details artivision. So unless you have a plan that includes opengl working with direct x and more done on vulkan you are kind of in trouble.

This is the problem with DXVK and VK9 when you start getting the details of dropping the opengl path completely comes hard because direct x and opengl are not always separate things under Windows due to the extensions that were added to opengl.

Its really simple to say do X without in fact knowing the complete list of requirements to have as many applications as possible work.

Vulkan can be used as an intermediate system exactly like Gallium, so i speak about native state trackers here and not compatibility layers and not 1:1 job. Meaning that the development time to make a native implementation will be equal to the development time needed to raise just 1% the speed of emulation at the same compatibility level. Wile you use simple words for the current WineD3D like "implementation" you actually doing a lot more complex job to figure out how you can dot each thing to the new api. The time you spending is not upon "implementing" but to figure out how to, after that you re-correct everything many times. I don't blame you that you don't have the sense of the difference in development times but your management is faulty. The first priority for a company is to cut the development times.