Announcement

Collapse
No announcement yet.

FUTEX2 Linux Patches Updated To Support Variable-Sized Futexes

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

  • #71
    Common LISP (list processing programming language from the 1960s), the only way to deal with horrible long lists of common objects. (Fortunately, that is the tricky part.)

    Comment


    • #72
      Originally posted by indepe View Post
      Exactly, the situation you try to describe here is much too complex for a single WaitForMultipleObjects call.
      That is the problem. The situation where support for WaitForMultipleObjects breaks down in wine is not the case where you have only a single one of them. The breakdown is when you have many of them.

      Originally posted by indepe View Post
      Whereas the situation described before is a simpler, very common situation of distributing a workload onto a fixed number of workerThreads that simply finish their task at some point. I'd very much expect these situations to appear in game engines as well. It certainly did in my own rendering, where there is no such try-and-retry logic going on, for which a single WaitForMulipleObjects call isn't suited either. The example code in those links would not be able to handle that correctly.
      Those examples are only the hello world examples. The games that break down in wine with WaitForMultipleObjects are the ones that have retry logic and the case that you will have two or more WaitForMultipleObjects where the object list is between them have 1 or more of the same Objects and has unique objects as well. The more complex rendering engines and the more complex anti-cheat systems.

      The thing to remember WaitForMultipleObjects takes a list of handles this is what makes reducing it to a single integer hard safely.

      Originally posted by indepe View Post
      You would have a wrapper function, not write that code explicitely in each situation.
      The reality here is WaitForMultipleObjects is a wrapper code. How to handle having to wait on multiple objects that can be in different states when you start while being correctly setup.

      Procedural programming weasel i know it. But there is a catch here why is the procedure called Wait for Multiple Objects. When you have the case that objects are being waited on by many parties that when you start WaitForMultipleObjects on many threads with one of the same objects objects how to do this and have the correct count and not use a insane amount of resources.

      Of course having a shared design to handle the WaitForMultipleObjects being called many times with overlapping but not identical set handles/objects does have it use cases. There will generally be your more complex nightmare cases like game engines with multi rendered output per frame to reduce end user latency or you game anti-cheat engines that are attempt to run in the spare cpu time between frame/output renders.

      Think about the multi rendered outputs per frame. Player pushes movement key after the next frame is already rendered but the display vsync is not here yet should the input be delayed until the next frame or should you rerender the current frame in queued. Of course if you have to rerender the frame you need to be kind of optimised for this. Yes the simple examples like the intel one I pointed to don't contain rerender to reduce input latency. The simple example also does not contain out of order rendering. Yes out of order rendering is a another stunt some game engines do to attempt to control rendering cost. Out of order rendering this is where you have spare cpu/gpu rendering time at the moment so engine guess renders something yes guessing right can control GPU/CPU load more evenly of course that guess rendered could come a object in the list of the next outputs.

      The problem here you cannot look at the WaitForMultipleObjects in the single solo case and say I have a replacement that works. You need to cover the many case where you have overlapping sets between multi active WaitForMultipleObjects that is the problem case the wine developers are dealing with. This is the problem case that comes out your more complex Direct X only game engines. Some of the reason why those game engines are not ported to Linux native is how to properly solve this problem and it also why games based those game engines commonly have poor ratings in wine appdb.

      As I said this is quite a horrible usage and its quite a complex one with no really simple solution with existing Linux kernel locking primitives. Yes there was that solaris attempted solution but it has its limitations and issues. Of course people did not look in the wine source code history to see that method had been tried. Its really simple to forgot sun developers worked on wine to bring solaris support at one point in wine history.

      Comment


      • #73
        Originally posted by oiaohm View Post
        That is the problem. The situation where support for WaitForMultipleObjects breaks down in wine is not the case where you have only a single one of them. The breakdown is when you have many of them.
        Are you talking about resource limits using eventfd? That has nothing to do with futex based solutions, which are the only thing being discussed here, about this article.

        Originally posted by oiaohm View Post
        Those examples are only the hello world examples. The games that break down in wine with WaitForMultipleObjects are the ones that have retry logic and the case that you will have two or more WaitForMultipleObjects where the object list is between them have 1 or more of the same Objects and has unique objects as well. The more complex rendering engines and the more complex anti-cheat systems.

        The thing to remember WaitForMultipleObjects takes a list of handles this is what makes reducing it to a single integer hard safely.
        If you think simpler use cases are not relevant, then why do you waste my time with "hello world" examples?
        Do you still think that you need to explain basics, don't you realize that is not the case?

        Did you even know that simple use case can be implemented with just an atomic counter and a semaphore?

        Originally posted by oiaohm View Post
        The reality here is WaitForMultipleObjects is a wrapper code. How to handle having to wait on multiple objects that can be in different states when you start while being correctly setup.

        Procedural programming weasel i know it. But there is a catch here why is the procedure called Wait for Multiple Objects. When you have the case that objects are being waited on by many parties that when you start WaitForMultipleObjects on many threads with one of the same objects objects how to do this and have the correct count and not use a insane amount of resources.
        What do you mean by saying that, except what is utterly obvious?

        Also, solutions using futexes don't require "insane" resources. You are mixing up completely different things.

        Originally posted by oiaohm View Post
        Of course having a shared design to handle the WaitForMultipleObjects being called many times with overlapping but not identical set handles/objects does have it use cases. There will generally be your more complex nightmare cases like game engines with multi rendered output per frame to reduce end user latency or you game anti-cheat engines that are attempt to run in the spare cpu time between frame/output renders.

        Think about the multi rendered outputs per frame. Player pushes movement key after the next frame is already rendered but the display vsync is not here yet should the input be delayed until the next frame or should you rerender the current frame in queued. Of course if you have to rerender the frame you need to be kind of optimised for this. Yes the simple examples like the intel one I pointed to don't contain rerender to reduce input latency. The simple example also does not contain out of order rendering. Yes out of order rendering is a another stunt some game engines do to attempt to control rendering cost. Out of order rendering this is where you have spare cpu/gpu rendering time at the moment so engine guess renders something yes guessing right can control GPU/CPU load more evenly of course that guess rendered could come a object in the list of the next outputs.
        Sorry, I don't know what point you are trying to make. There are simpler solutions for simple use cases, specifically cases in which there is a single waiter, but obviously use cases with multiple waiters (not just multiple events) are not as simple. That should be obvious since I have already described a less simple case when I was asked how to implement wait-for-any (that's when I was talking about 3 threads and 5 events). That was a use case with what you call "common objects" (however a case of wait-for-any, whereas the workerThreads case above is wait-for-all).

        Originally posted by oiaohm View Post
        The problem here you cannot look at the WaitForMultipleObjects in the single solo case and say I have a replacement that works. You need to cover the many case where you have overlapping sets between multi active WaitForMultipleObjects that is the problem case the wine developers are dealing with. This is the problem case that comes out your more complex Direct X only game engines. Some of the reason why those game engines are not ported to Linux native is how to properly solve this problem and it also why games based those game engines commonly have poor ratings in wine appdb.
        We are talking about the problems that the WINE developers are currently trying to solve, and I'm sure they include those. I understand that there are problems that need to be solved, but I disagree that this requires kernel patching.

        Originally posted by oiaohm View Post
        As I said this is quite a horrible usage and its quite a complex one with no really simple solution with existing Linux kernel locking primitives. Yes there was that solaris attempted solution but it has its limitations and issues. Of course people did not look in the wine source code history to see that method had been tried. Its really simple to forgot sun developers worked on wine to bring solaris support at one point in wine history.
        There currently is no really simple solution because that functionality is not part of pthreads / POSIX or glibc (not sure about Boost), and apparently there is no other library that can be used as a direct replacement for Windows Event objects, either. However that doesn't mean that there couldn't be one, using the existing kernel synchronization primitives.

        You are not making a technical argument in that sense either, you are just describing why you think it is difficult. Yes, it isn't easy. And a good bit of work.

        Comment

        Working...
        X