Jump to content

  • Log in with Facebook Log in with Twitter Log In with Google      Sign In   
  • Create Account

Unofficial Wineskin Project


  • Please log in to reply
234 replies to this topic

#211 vskllee

vskllee

    Novice Member

  • Members
  • 5 posts
  • Graphics Card:Radeon HD 4850
  • Operating System:macOS 10.12 (Sierra)

Posted 25 March 2019 - 04:01 PM

hi!I want to ask how to modify the wine menu bar?

#212 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 25 March 2019 - 05:40 PM

View Postvskllee, on 25 March 2019 - 04:01 PM, said:

hi�I want to ask how to modify the wine menu bar?

As explained before that requires patching and compiling wine from source as such does not fall under Wineskin development.

That's a question for Custom wine build section.

#213 yangm97

yangm97

    Lurker

  • Members
  • 1 posts
  • Graphics Card:HD 3000
  • Operating System:OS X 10.9 (Mavericks)

Posted 14 April 2019 - 09:46 PM

Will directx 10 and above work through MoltenVK when using this wrapper?

#214 RastaFabi

RastaFabi

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts
  • Graphics Card:Intel HD 4000, 1536MB dynamic, shared
    NVIDIA GTX 750Ti, 2048MB, eGPU (Thunderbolt)
  • Operating System:macOS 10.12 (Sierra)

Posted 14 April 2019 - 10:52 PM

View Postyangm97, on 14 April 2019 - 09:46 PM, said:

Will directx 10 and above work through MoltenVK when using this wrapper?
Please do read the information provided, before asking questions.
This thread‘s opening post clearly states that it's not supported.


Once support is available, which needs to be implemented by the developers of MoltenVK, wine can be compiled to leverage this.
Before that happens no macOS wine implementation whatsoever will be available providing this functionality.
For further information and MoltenVKs implementation status please refer to this bug tracker.

#215 ovvldc

ovvldc

    Master Member

  • Members
  • 1250 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 16 April 2019 - 07:47 AM

The latest MoltenVK release supports many more functions than the original, so we are probably much closer to DXVK or something like it. But once it works, it will probably use a lot of memory and not be as fast as a native Vulkan driver (much less native Windows).

#216 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 18 April 2019 - 04:18 AM

I pushed a new wrapper update;
  • Working Gnutls
  • Current FAudio built from current head (no wma decoding)
  • MoltenVK taken from latest SDK (1.1.106.0)
  • wine64 used by default on 64bit wrappers
  • font smoothing enabled on wrapper creation


#217 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 21 May 2019 - 11:34 PM

View Postovvldc, on 16 April 2019 - 07:47 AM, said:

The latest MoltenVK release supports many more functions than the original, so we are probably much closer to DXVK or something like it. But once it works, it will probably use a lot of memory and not be as fast as a native Vulkan driver (much less native Windows).
What is the estimated performance hit as compared to native DX? 50%? 25%? 15%? Any rough estimate?

#218 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 22 May 2019 - 03:23 AM

View Posteierfrucht, on 21 May 2019 - 11:34 PM, said:


What is the estimated performance hit as compared to native DX? 50%? 25%? 15%? Any rough estimate?

There can’t be an estimate until DXVK/VKD3D is functional using MoltenVK.
cdavis5e is the one doing all the work on MoltenVK to support DXVK/VKD3D.

#219 ovvldc

ovvldc

    Master Member

  • Members
  • 1250 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 22 May 2019 - 07:44 AM

You can follow feature progress here: https://github.com/K...enVK/issues/203

#220 eierfrucht

eierfrucht

    Regular Member

  • Members
  • Pip
  • 11 posts
  • Graphics Card:GeForce GTX 1050Ti
  • Operating System:macOS 10.12 (Sierra)

Posted 22 May 2019 - 08:36 AM

I follow that, I've even run QuakeVK on Sherry. I wondered if at least a very rough estimate existed, like above 50% or below 50% perf hit...

#221 ovvldc

ovvldc

    Master Member

  • Members
  • 1250 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 22 May 2019 - 08:43 AM

The fews thing that is that Dota2 was faster on MoltenVK than on OpenGL, and that Dolphin is not. For the latter, I can quote from their progress report: "it's important to note that macOS still has the worst driver situation for Dolphin and it is an inferior platform for emulation in general. Once Apple removes OpenGL support completely, the situation will be even more dire. As nice as MoltenVK support is as an option, it's still slower than OpenGL in many cases and is significantly slower than native Vulkan support. Running Dolphin on Windows via Bootcamp is still our recommended way to get the best possible Dolphin experience from a macOS machine."

No idea how Wine/DXVK over MoltenVK is performing but I am not holding my breath right now...

We shall see if anything becomes easier at WWDC.

#222 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 22 May 2019 - 11:39 PM

View Posteierfrucht, on 22 May 2019 - 08:36 AM, said:

I follow that, I've even run QuakeVK on Sherry. I wondered if at least a very rough estimate existed, like above 50% or below 50% perf hit...

We can’t give even a rough estimate as the feature is not even available publicly!
Who knows how many api features need to be emulated still. (If someone did have an idea they wouldn’t be able to post any information until it’s public like after the FF macOS port is released.)

There is a reason Slice shows VKQuake/Cube demo running;
https://github.com/v...mment-421704200

View Postovvldc, on 22 May 2019 - 08:43 AM, said:

The fews thing that is that Dota2 was faster on MoltenVK than on OpenGL, and that Dolphin is not. For the latter, I can quote from their progress report: "it's important to note that macOS still has the worst driver situation for Dolphin and it is an inferior platform for emulation in general. Once Apple removes OpenGL support completely, the situation will be even more dire. As nice as MoltenVK support is as an option, it's still slower than OpenGL in many cases and is significantly slower than native Vulkan support. Running Dolphin on Windows via Bootcamp is still our recommended way to get the best possible Dolphin experience from a macOS machine."

No idea how Wine/DXVK over MoltenVK is performing but I am not holding my breath right now...

We shall see if anything becomes easier at WWDC.

https://github.com/gfx-rs/portability seems to be faster with Dolphin, but Dolphin being an emulator anyway already does strange things with the graphics API, then Vulkan > MoltenVK > Metal.
I would say emulaters are a bad usage case for MoltenVK.



Can we move the discussion to another thread everyone as it’s not directly related to the thread.

#223 vanhouten

vanhouten

    Experienced Member

  • Members
  • PipPip
  • 22 posts
  • Graphics Card:AMD Radeon RX 580
  • Operating System:Other OS/Not specified

Posted 23 May 2019 - 02:14 PM

Hello,

I was wondering if there was a way to make Wineskin wrappers work with BetterTouchTool ? I mean at an application level (not global). Mouse gestures work at a global level but it's not very handy. I can make ControllerMate work by switching from "running in foreground" to "running" but BTT doesn't have this option (probably not the best way though).

#224 ovvldc

ovvldc

    Master Member

  • Members
  • 1250 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 23 May 2019 - 06:22 PM

Also a separate topic? (I have no answer to the original question)

#225 RastaFabi

RastaFabi

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts
  • Graphics Card:Intel HD 4000, 1536MB dynamic, shared
    NVIDIA GTX 750Ti, 2048MB, eGPU (Thunderbolt)
  • Operating System:macOS 10.12 (Sierra)

Posted 29 May 2019 - 11:57 PM

Now that the first development release of macOS 10.15 is close, and the public beta should follow within two weeks, what is your plan regarding your unofficial Wineskin fork?
CodeWeavers pledged to incorporate a wine32 on wine64 wrapper while also promising DX11 support via DXVK (DX9 via D9VK), via Vulkan, via MoltenVK (GL via Vulkan, via MoltenVK?). This somewhat indicates, that the wine/engine site of things should be covered midterm.
Supposedly Apple does not incorporate further fundamental api changes, do you think your current builds of Wineskin will just work? Might it be necessary to stripe down all the 32bit library and executable parts in order to work altogether, implying the need to maintain a pre 10.15 and a 10.15 fork separately? Or might this required a major code rewrite altogether? (NSTask?)
Do you even plan continuing support with apple ramping up those new hurdles?
Would be great to get some developer-perspective on this.

Thank you for all your work (and Vitor’s) done so far, as it’s safe to say you guys are one of the main drivers of current Mac gaming.

—————
https://www.phoronix...-Alpha-Released
https://github.com/K...enVK/issues/203
https://www.codeweav...t=27;msg=212891

#226 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 30 May 2019 - 01:06 AM

View PostRastaFabi, on 29 May 2019 - 11:57 PM, said:

Now that the first development release of macOS 10.15 is close, and the public beta should follow within two weeks, what is your plan regarding your unofficial Wineskin fork?
CodeWeavers pledged to incorporate a wine32 on wine64 wrapper while also promising DX11 support via DXVK (DX9 via D9VK), via Vulkan, via MoltenVK (GL via Vulkan, via MoltenVK?). This somewhat indicates, that the wine/engine site of things should be covered midterm.
Supposedly Apple does not incorporate further fundamental api changes, do you think your current builds of Wineskin will just work? Might it be necessary to stripe down all the 32bit library and executable parts in order to work altogether, implying the need to maintain a pre 10.15 and a 10.15 fork separately? Or might this required a major code rewrite altogether? (NSTask?)
Do you even plan continuing support with apple ramping up those new hurdles?
Would be great to get some developer-perspective on this.

Thank you for all your work (and Vitor’s) done so far, as it’s safe to say you guys are one of the main drivers of current Mac gaming.


Unofficial Wineskin, is already 64Bit (except wsgamma due to no source code) so the application is ready.

CodeWeavers are working on at least two solutions that I'm aware of, one being Hangover, a patched pure wine64 with included custom qemu to handle 32bit applications/games.
Option 2, (patch?) and compile using a custom version of clang that had built in trunking support so 32Bit process will be ran on 64Bit threads. The resulting wine would be like now wine/wine64 but running as 64Bit. < The version I would prefer.

I've been building wine with MoltenVK support since it was possible so once DXVK runs we can use it with a WS10 Engine, so if later they want to us MoltenGL or some other weirdness if it works it can be built into an Engine.

The NSTask thing is more for passing permissions on correctly from Wineskin > wine processes.
I don't think I will need to fork the project for macOS 10.15, the problem is wine more than anything else (maybe some extra checks to disable all but WS11 Engines to be safe lol)

I don't want to use Hangover but I'm willing to build Hangover Engines if needed, Unofficial Wineskin already launches wine64 if it found over wine already.


I plan to keep supporting the project as long as possible, I don't want to fork into different versions unless it's unavoidable for now I would just need to disabled using WS10 and lower Engines on macOS 10.15 once it's launched.

#227 ovvldc

ovvldc

    Master Member

  • Members
  • 1250 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 30 May 2019 - 07:29 AM

I understand that having to maintain their own compiler is a big reason why Codeweavers is hesitant on option 2. I wonder if that options would be helpful for other use cases. Ideally, it would be upstreamed in LLVM/Clang with unit tests so that they keep it in mind when advancing their codebase.

#228 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 30 May 2019 - 12:19 PM

View Postovvldc, on 30 May 2019 - 07:29 AM, said:

I understand that having to maintain their own compiler is a big reason why Codeweavers is hesitant on option 2. I wonder if that options would be helpful for other use cases. Ideally, it would be upstreamed in LLVM/Clang with unit tests so that they keep it in mind when advancing their codebase.

Hangover is more aimed at arm64 devices, that it could work for macOS is another matter, calling outside of the included emulator gives major slowdowns (mentioned at the last wine conference)

Maintaining a custom compiler, well they already maintain winegcc, a patched clang for macOS cross-compiling, now mingw-w64 and Winehq both already share a lot of code already.

During the last wine conference they only shown Hangover running on the Nvidia sheild but did explain the other the custom compiler version.
Hangover slows down if calling outside of the emulator and on some applications/games that’s constantly if they use 32bit & 64Bit library’s.

Wine compiled to run 32Bit on 64Bit threads using trunking ran at almost native speeds as a 32bit compile, also none of the slowdown from emulation.
The trunking is mostly already baked into LLVM the customizations to clang are to add the ability to use it for x86 code (some other things but I’m sure but I only quickly looked over the commits)

From my perspective Hangover if used would be crippling wine on macOS even more the it currently is, also considering CodeWeavers makes a large cunk of revenue from Porting services (Currently one that got mentioned publicly was a FF game that will be using DXVK in the macOS port!)

#229 ovvldc

ovvldc

    Master Member

  • Members
  • 1250 posts
  • LocationEurope
  • Graphics Card:Intel Iris Plus
  • Operating System:Other OS/Not specified
  • I like to play:stories

Posted 01 June 2019 - 06:33 PM

Fully emulating would be crippling. I can imagine a scenario where JIT recompiling makes sense and doesn't slow down too much when going from 32bit to 64bit as they are roughly the same instruction set, but it will still cost memory and CPU cores.

But if they have a patched clang anyway, they can add this as well. As long as Intel and AMD still support the 32bit instructions anyway ;)

#230 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 01 June 2019 - 11:25 PM

View Postovvldc, on 01 June 2019 - 06:33 PM, said:

Fully emulating would be crippling. I can imagine a scenario where JIT recompiling makes sense and doesn't slow down too much when going from 32bit to 64bit as they are roughly the same instruction set, but it will still cost memory and CPU cores.

But if they have a patched clang anyway, they can add this as well. As long as Intel and AMD still support the 32bit instructions anyway ;)

I will properly build hangover tomorrow and give it a try myself lets see if it's usable or not before I go making changes to WineskinLauncher to accommodate it.

But yeah I'm sure clang will be used over hangover for macOS, since hangover was more aimed at ppc arm devices

Edit;
Well looks like I can skip building it myself for the moment, qparis build it and uploaded a build, I did some tests and it’s honestly not very useful in its precent build configuration.

#231 RastaFabi

RastaFabi

    Advanced Member

  • Members
  • PipPipPip
  • 59 posts
  • Graphics Card:Intel HD 4000, 1536MB dynamic, shared
    NVIDIA GTX 750Ti, 2048MB, eGPU (Thunderbolt)
  • Operating System:macOS 10.12 (Sierra)

Posted 05 June 2019 - 08:16 PM

Hi @Gcenx, I just wanted to report, that your wineskin fork apparently is working fine on macOS Catalina.
While I did not test existing wrappers I created a new one with a 64bit engine (4.7). Wineskin proceeded to create the wrapper and I did launch wineconfig.exe, regedit.exe and some more tools. Checking the wine environment I found the expected: syswow64 (the 32bit directory :huh:) is empty, as the 32bit wine process setting it up just did not run.

#232 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 06 June 2019 - 01:08 AM

View PostRastaFabi, on 05 June 2019 - 08:16 PM, said:

Hi @Gcenx, I just wanted to report, that your wineskin fork apparently is working fine on macOS Catalina.
While I did not test existing wrappers I created a new one with a 64bit engine (4.7). Wineskin proceeded to create the wrapper and I did launch wineconfig.exe, regedit.exe and some more tools. Checking the wine environment I found the expected: syswow64 (the 32bit directory :huh:) is empty, as the 32bit wine process setting it up just did not run.

Yeah since on prefix creation wine couldn't function so
wine wineboot
would have failed but
wine64 wineboot
would have functioned.

I recently make sure to have Wineskin default to using wine64 over wine when available, I had the same results when testing on Mojave with 32bit mode disabled.
Still I'm a little surprised it even worked at all considering all the engines other then then the CX ones are from winehq.


If you replace the wswine.bundle contents with a pure 64Bit compile and rebuild the wrapper (ignoring the error about wine) it will function.
When I have some time I might do a proper set of updates more aimed at Catalina

If you would like a pure64 compile to play with let me know I can thrown one together.

Edit;
I should explain a little more, even if you compile wine as only 64Bit you will get the exact same results as you experienced here, the syswow64 directory and other 32bit folder will still get created by using “wine64 wineboot”

#233 Shiningalex

Shiningalex

    Novice Member

  • Members
  • 6 posts
  • Graphics Card:HD4000
  • Operating System:macOS 10.12 (Sierra)

Posted 12 June 2019 - 10:10 AM

Thanks for this. I can't wait to try it out.

#234 vskllee

vskllee

    Novice Member

  • Members
  • 5 posts
  • Graphics Card:Radeon HD 4850
  • Operating System:macOS 10.12 (Sierra)

Posted 19 July 2019 - 03:18 AM

Does it support macos10.15?

#235 Gcenx

Gcenx

    Veteran Member

  • Members
  • PipPipPipPipPip
  • 362 posts
  • Graphics Card:Intel Iris
  • Operating System:macOS 10.12 (Sierra)

Posted 13 August 2019 - 02:24 AM

View Postvskllee, on 19 July 2019 - 03:18 AM, said:

Does it support macos10.15?

No.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users