Announcement

Collapse
No announcement yet.

FUTEX2 Spun Up A Fifth Time For This Linux Interface To Help Windows Games

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • coder
    replied
    Originally posted by F.Ultra View Post
    What major optimizations for games have WIndows done (ignoring DIrectX since that is a special case)?
    I'm no Windows expert, but I'd say pulling GPU drivers into userspace (or, at least out of ring 0) was a pretty big one.

    I'm sure there are tons of other things Windows did to optimize for games. The main question I have is which of them were bad for security or other types of apps? There was that whole thing people ran into porting games to Stadia with userspace spinlocks that didn't work so well, in Linux -- how much did Windows have to gimp their scheduling code to make crap like that work well?

    Leave a comment:


  • uid313
    replied
    Originally posted by F.Ultra View Post

    What major optimizations for games have WIndows done (ignoring DIrectX since that is a special case)? I have to admit that I'm a bit rusty coding for Windows now a days but I cannot think of anything major changed in this regard the last decades?!
    DirectStorage, it is some amazing technology used in Xbox Series X and S to load data from the solid-state disk directly into the graphics memory.

    Leave a comment:


  • ryao
    replied

    Originally posted by F.Ultra View Post
    Could also be argued that in an environment where you do have access to WFMO then people tend to design their code around it leading to IMHO an abundant usage of multiple object when fewer might have served the same purpose. Looking that the situations that WINE is trying to solve here with games creating, waiting for and disposing millions of such objects then IMHO this scream inefficient design (of the games, not of WFMO).
    I have yet to see an example of good code that needs WaitForMultipleObjects. I suspect that WaitForMultipleObjects was not used on Windows because it is good, but because the locking model was focused on interprocess locks rather than intraprocess locks. Microsoft introduced POSIX-like SRW locks that they encourage developers to use for better performance.

    Originally posted by F.Ultra View Post
    What major optimizations for games have WIndows done (ignoring DIrectX since that is a special case)? I have to admit that I'm a bit rusty coding for Windows now a days but I cannot think of anything major changed in this regard the last decades?!
    I would like to know this too.

    Here is what I know offhand, not excluding DirectX, as it is a large collection of APIs and the list becomes really short without it:

    * SRW Locks
    * Miscellaneous scheduler improvements
    * DXIL's elimination of libraries/modules, which allows better shader compiler output via interprocedural optimizations that could not be done between libraries. They seem to have taken a stepbackward by adding experimental library support to DXIL1.1. The elimination of libraries is basically copied from Vulkan (or was it Mantle?).
    * Supporting the latest initiatives by GPU designers such as Resizable BAR Support, Mesh Shading, Variable Rate Shading, Sampler Feedback, etcetera.
    * Not forcing NVMe to use a queue depth of 1 like their initial NVMe support did.

    It is not a very impressive list, although it is not comprehensive either. It is just a bunch of miscellaneous things. I am not sure if some of them count as major things.
    Last edited by ryao; 10 July 2021, 10:30 AM.

    Leave a comment:


  • ryao
    replied
    Originally posted by coder View Post
    Be that as it may, WaitForMultipleObjects() has been around since at least Windows 95, and had nothing to do with games. Wine might be adding it for games, but it wasn't in Windows primarily for games.
    Wine has had it for a long time. It has also been a source of slow Wine performance for a long time because it traditionally required IPC with the wine server. The wine developers reimplemented it to use eventfd (esync) to improve thread synchronization in wine for Proton to a level that is close to native Windows performance, but they want to reimplement it using futex2 to get thread synchronization to match native Windows performance. At least, that is my understanding.

    Leave a comment:


  • ryao
    replied
    Originally posted by jrch2k8 View Post

    Very simple, in my case:

    1.) a 2nd GPU to do pass through make no economic sense just to play some games.
    2.) I only use DRM free or cracked games(because those usually remove any DRM)(i do own them but usually the crack works better).
    3.) is not that hard for me and lutris kinda make it easier.
    4.) I don't play anything that include loot boxes(if i wanna burn money on RNG i'll go to a damn casino)
    5.) i don't buy games at release, they are usually half done, full of bugs and very expensive(even less pre order, you burn me once not twice)
    6.) i just don't like Windows and i don't want it even on a virtual machine, hence i have no problem waiting few weeks until someone finds a way around whatever issue i have and since i don't make money playing games, is no biggie.
    7.) My ultra modded skyrim SE works better on Wine+RADV than on Windows
    Nvidia likely could make this easier if they made their VGPU technology available on GeForce, but then they couldn't get licensing fees. AMD could likely do the same if they brought their MxGPU analog to Radeon. :/

    Leave a comment:


  • ryao
    replied
    Originally posted by binarybanana View Post
    I gave up on wine/proton since no matter how much it improves there will always be enough issues for it to be frustrating at times. Some games, especially older games run better than on Windows, but other than that it's hit and miss in both compatibility and performance. Look at this, they even have to mess with the kernel to make it work better.
    This is just a performance tweak. It does not improve compatibility.

    Originally posted by binarybanana View Post
    To be fair, even native programs could benefit from it, but still.

    Nowadays I just use a Windows VM with GPU passthrough. Literally every game I tried works exactly the same as on base metal Windows and performance is same, or slightly better actually. DPC latency is also much better at 30-60us avg, curiously. No more worrying about compatibility. No more workarounds. No more crap performance. No more visual glitches or other bugs and wondering if that's normal. You also can use stuff like HeSuVi for excellent virtual surround sound on headphones, or use SpecialK to decrease input latency in games to a minimum. Only thing that's problematic it that some online games consider a VM a cheat and might ban you. There aren't that many, but some do. Not sure how those mpare with wine, since I don't play those, but anti-cheat is even more of a headache on wine kernel mode anti cheat especially), so if a VM is a cheat, it's likely that wine is, too.

    So given that I wonder why people still bother with wine/proton. I guess it's fine if someone doesn't care if a few games are unplayable or for people who only play a handful of games that happen to work. A VM with a bare-bones Windows takes seconds to boot and the game console OS is ready. Probably starts faster than Steam does.
    Compatibility issues are the reason why Valve has a game whitelist and basically gives no guarantees about games that are not on the white list.

    The long term goal is compatibility, but compatibility is hard given that Windows is a moving target and has a bloated API. They have made amazing progress despite that. Their biggest problem these days is kernel anticheat. You can literally go down the list of 100 most popular games (native excluded) and every game marked red is marked it because of kernel anticheat:



    If you ignore those and start looking at less than 100% perfect games, then you will find a myraid quantity of other issues. This is the long tail portion of the pareto principle and it will take the most time to resolve. :/

    Leave a comment:


  • ryao
    replied
    Originally posted by avem View Post

    It's not just for Wine. Nothing in the Linux kernel is just for something, its userspace API are available for all applications.

    As to whether it's better or not I've no idea. Since so many people are working on it, it looks like Windows has some APIs which are ill-represented in Linux, so a closer implementation could bring huge benefits in terms of performance/usability.
    Valve is funding it primarily for Wine. They said that they could also use it inside the steam client, although it is a black box, so it is hard to examine that claim.

    As for it being better, it is not an upgrade for things that are happy with the existing futex code, having either the same performance at best and slightly lower performance at worse.

    Leave a comment:


  • ryao
    replied
    Originally posted by uid313 View Post
    Is futex2 better than futex?
    While this was made specially for Wine, is this only for Wine, or should all of Linux use futex2 instead of futex?
    No. It just adds features that people want that are not in the original futex code. its requeue operation is actually slower than the original futex requeue operation while the other operations perform the same, so switching to it just because you can would at best be no different and at worse be slightly slower.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by theriddick View Post

    To be fair allot of stuff done under Linux has always been for developers and server infrastructure first.
    Windows has been making major optimizations to how gaming works for quite some time while Linux has been going back into the ocean, until recently. So all this futux2 etc.. its all catch up.. a metric galactic sized level of catch up was/is needed.

    Two major holdovers from windows10 for me is obviously stuff like this to help stream in data, since many next-gen games get clogged with the amount of calls being made under wine/proton. AND, Anticheat, which has been making SOME progress btw. (devs can now enable EAC wine/proton to work in their games..)
    What major optimizations for games have WIndows done (ignoring DIrectX since that is a special case)? I have to admit that I'm a bit rusty coding for Windows now a days but I cannot think of anything major changed in this regard the last decades?!

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by coder View Post
    I started with multithreaded programming on Windows, so I was aware of when I wanted WaitForMultipleObjects() and didn't have it. And that has actually been a very small number of times.

    I wonder if it's any easier to shoot yourself in the foot, with WFMO. When acquiring multiple mutexes, the main pitfall is if any code path which acquires them does so in a different order than any of the others, you can hit a deadlock.
    Could also be argued that in an environment where you do have access to WFMO then people tend to design their code around it leading to IMHO an abundant usage of multiple object when fewer might have served the same purpose. Looking that the situations that WINE is trying to solve here with games creating, waiting for and disposing millions of such objects then IMHO this scream inefficient design (of the games, not of WFMO).

    Leave a comment:

Working...
X