Announcement

Collapse
No announcement yet.

NVIDIA's List Of Known Wayland Issues From SLI To VDPAU, VR & More

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

  • #81
    Originally posted by wertigon View Post
    mdedetrich, You seem to be more willing to point the finger on who is to blame here, than actually provide solutions.
    There are many solutions which have been discussed. Its just that the most sensible solution is one that you aren't willing to accept because it doesn't make NVidia look bad (and no that solution doesn't involve breaking userspace incase you want to pull that "trick" again)

    Originally posted by wertigon View Post
    You are arguing semantics.
    Protip: If you don't like arguing about semantics/details then don't come up with make believe problems to use as excuses for your own arguments.

    Originally posted by wertigon View Post
    Even if it is true that Nvidia code doesn't break userspace, but instead just force every other stakeholder to go out of their way to appease Nvidia, this still isn't a viable solution.
    Stakeholders already had to do this because of Wayland. SInce Wayland had the "intelligent" design of just being a protocol, every single compositor out there (Gnome/KDE etc etc) had to manually implement their own codepaths specifically for Wayland.

    For the codepaths which are specific to NVidia (which is not what is being proposed now), NVidia actually upstreamed themselves, one case in the past being EGLStreams with KDE.

    Originally posted by wertigon View Post
    Nvidia has the incentive and initiative here, therefore if Nvidia wants to resolve this quickly they need to start collaborating with the rest of the vendors on an API or set of API changes that resolve their issue, is backwards compatible and
    They already did this but since it seems you are either unwilling or unable to read the thread that was linked before therefore there is not much I can do ¯\_(ツ)_/¯.

    Originally posted by wertigon View Post
    does not (significantly) hurt their competitors.
    You would be happy to know that their solution actually increases the performance of their competitors, thats why AMD and Intel are also pushing for this.

    Originally posted by wertigon View Post
    If the Nvidia solution require more than 40 hours of development time from any competitor then there is a strong chance it will be vetoed down.
    You clearly have no idea how software development works, lets just leave it at that.

    Originally posted by wertigon View Post
    Meanwhile their competitors will slowly move towards a solution that may or may not be compatible with Nvidias hardware design. Nvidia is free to collaborate on that, of course.

    It is up to Nvidia if they want to stay compatible and collaborate. Any effort to do so is encouraged, but failure to do so will mean the rest of the world moves on regardless.
    Here is a tip, stop acting like some project manager who thinks they know what they are talking about but they really don't in order to try and make some asinine point that is somewhat but not really related just to boost their own ego or make themselves look important.

    If you don't care about semantics (which you just implied earlier) and you aren't even willing to read the content that directly answers your questions/comments then its probably a good idea to exit from the discussion.
    Last edited by mdedetrich; 25 May 2022, 09:10 AM.

    Comment


    • #82
      Originally posted by oiaohm View Post

      DMA-BUF and GBM does in fact have official extensions with the kronous group.



      There is a problem here. You get marked as Opengl 4.6 conforming without passing the test prior to Opengl 3.0. You still have people running opengl 1.2 applications at times. As I said Nvidia wrote the tests and they are in the conformance suite. Mesamatrix does not display the result early tests but all open source drivers do in fact pass them.

      There are no such things as test prior to OpenGL 3.0. And according to what i know from various developers again, they claimed Nvidia implementation of OpenGL was the best.

      Actually Nvidia has submitted to Khnosos compliance against OpenGL 4.3, 4.4 4.5 4.6 MesaMatrix is not giving you results of nvidia propertiary driver, but Nouveau.

      Ok, but let me explain you why implicit sync for opengl is not such pain in the ass for Nvidia as Linux buffer system (That has from perspective of OpenGL driver nothing to do with).

      Generally implicit sync means synchronization is automatic. So simplified:

      The way something like 3D graphics works is you batch some information for rendering:
      * here's my list of vertices
      * here's my list of indices (the way vertices are related)
      * here's my texture
      -> please render this on screen.

      Now OpenGL (or old DirectX) synchronization is automatic so if you want to be absolutly pragmatically accurate, you should synchronize after every step. The issue is that it is stupid, you know you can synchronize just before rendering that everything is loaded and after loading make render. So instead of 3 synchronizations you do 1. Practically that would be way more on both sides.

      So what GPU drivers developers do - they create generic conformant driver that works as it is told unless it is absolutly sure it can drop some synchronization fences because they are useless. When new popular game out, developers of Nvidia (Especially them!), AMD and Intel are brainstorming to create a specific profile that will work in that specific game that will drop certain synchronization fences or like Nvidia sometimes even replace shaders. So game works fast, gamers are happy, wasteful work is not done so efficiency is happy the issue is, it is still quite painful in the ass for developers. This is also why standard GTX/RTX drivers don't work so well with workstation software like CAD, but Nvidia optimized drivers for Quadro/Titan will perform a ton better in Catia or something like that. But generally that is not the worst thing that can happen for developers. You see OpenGL or DX10 or older are fairly high level APIs. So you have big calls that do big things and synchronization fence after it even if you did "by default" isn't that bad. Also devices of the past were simple, Xorg was simple, there were few cores, only 1 queue in driver, everyone was relativly happy with implicit sync because even if sync did happen there wasn't much to sync anyway.

      So what did change?

      1st. we got low level APIs. Vulkan, Mantle, DX12, Metal are all low level meaning they do way more basic operations. Now imagine you have implicit sync on them. You are in hell because instead of 3 operations you do 30, and you have 30 potential synchronization fences. Now driver good luck optimizing it!

      2nd. Devices got complex. We have multicore systems, with many queues with 10496 cores (RTX 3090) or like Vega graphics having 4 asynchronous compute engines.

      3rd. We got way higher refresh rates. So certain things that were done let's say 30 times per 1 second, now we have use cases of incomming 500 times per 1 second (yes monitor 500Hz is announced already!).

      4th. Graphics got complex. Yes that is natural thing with evolution of graphics.

      So we have way more graphic calls per frame (1(if low level API) and 4), with way more frames per second (3), with way more stuff sleeping idle (2) because synchronization that doesn't need to happen, does happen. So are we clear now why not necessery synchronization is bad for end user? And this 30% performance penalty Nvidia claims is today, it will be worse in future because things does evolve.

      Now how it goes with graphics of linux? Well... we have buffer managment that is low level with... implicit sync? So we have OpenGL running on X server, fine relativly high level on high level, some bad synchronization will happen, but well it is legacy and mostly doesn't need "that" high performance. That is if X server is wired up directly to driver, but again X works partly explicit, partly implicit and is still relativly high level (explicit shmfence objects that order OpenGL calls, synchronization itself is implicit). So nvidia or any driver doesn't have that big problem in the end, there is some implicit syncs when driver has to assume things, but things are ordered right way and driver can swallow a little oversynchronization.

      Now how it eats with Wayland? Well Wayland current way is full implicit. It has sync_files that could be passed around for explicit synchronization but doesn't. So we have implicit sync OpenGL running on xwayland (X mostly implicit sync) going to window system (Wayland) that is implicit with buffer system that is implicit. Add KMS and we have even more implicit. In the end everything synchronizes with everything. As long as stuff is single threaded that is not that bad as calls happen in particular order. The issue is with multithreading everything becomes a problem (quoting Ekstrand):

      The 1# problem with implicit synchronization (which explicit solves) is that it leads to a lot of over-synchronization both in client space and in driver/device space. The client has to synchronize a lot more because it has to ensure that the API calls happen in a particular order. The driver/device have to synchronize a lot more because they never know what is going to end up being a synchronization point as an API call on another thread/process may occur at any time. As we move to more and more multi-threaded programming this synchronization (on the client-side especially) becomes more and more painful.
      The 2# problem with implicit synchronization is that when explicit sync is around things are 1-1. There is explicit sync in Vulkan? You pass it down the line to window system. Window system has explicit sync ? You pass it down to driver. Driver knows when to sync no guessing with multithreading, no oversynchronization, everyone is happy. Vulkan has extensions for exporting/importing sync files so even could be used to make entire compositor and everything down the line. It currently does some implicit synchronization when interacting with window system but that is very "fixed" cost that won't increase in future with complexity and it is obvious why it is implicit here (synchronization has to happen, and window system itself has to decide when to synchronize stuff).

      Now can you implement Implicit sync over explicit ? Yes. This is how DXVK works, this is how Zink works. And Nvidia also doesn't have problems with OpenGL on X server (I fucking don't know why you are lie it doesn't work, but i can tell as hell it does) and as far as i know propertiary drivers of Intel or AMD doesn't have problems with OpenGL on windows either.

      So now the last part, why Nvidia has problem?
      Quoting James Jones
      And how exactly does this happen? If we're implementing implicit sync, it's the responsibility of the GL driver in use by glamor (and any kernel driver backing it), correct? That's where things get complicated. There's no clear command that signals the GL driver to "latch" the implicit sync fence from the dma-buf by using the ioctl() that converts it to an explicit sync FD, so we just have to continuously monitor all textures/images/whatever in use by any command buffer and try extracting an implicit fence from any of them that are backed by imported dmabufs every time we want to submit commands down the the hardware, in every application, not just Xwayland+glamor, because Xwayland+glamor use the GL driver just like any other app does. That's what I'm talking about by the complexity that I'd prefer to avoid. The performance benefit is precisely avoiding that complexity running in every app.

      The thing is they cannot know when to latch synchronization fence, because system is multithreaded in nature. So they would have to monitor commmand buffer to know when to latch that fence. Are we getting to a point it becomes extreme complexity and performance loss? A lot of which Open source stack has to do as well?

      So you have 3 options:
      - extremly oversynchronize everything, and keep Linux a trash system for most normal users, hey let's keep it 1% popularity or even go below, who cares about performance right?

      - making explicit sync work alongside implicit sync (funny the only thing that makes 2 work kind of along is X server) and that is proposition made by Ekstrand (former Intel) and Erik (Nvidia) basicly add some explicit sync to resolve issues of implicit sync, also the most realistic aproach to keep switching piece by piece parts to explicit sync, there are some annoying parts like KMS being entirly implicit but i hope things will get better,

      - move entirly to explicit sync (from AMD employee LOL).

      I find it very funny that Intel and AMD employees could easly fuck Nvidia around and say we want to keep things they are. Deal with it, it is your problem for competitive advantage. But instead they want explicit sync themselves because they are so sick of working in linux graphic system. And again, there is no breaking userspace by moving to explicit sync.
      Last edited by piotrj3; 25 May 2022, 12:04 PM.

      Comment


      • #83
        Originally posted by piotrj3 View Post
        ...

        I find it very funny that Intel and AMD employees could easly fuck Nvidia around and say we want to keep things they are. Deal with it, it is your problem for competitive advantage. But instead they want explicit sync themselves because they are so sick of working in linux graphic system. And again, there is no breaking userspace by moving to explicit sync.
        Completely agree with everything you say but was this the case? As far as I am aware it wasn't AMD/Intel engineers that was shitting on NVidia for explicit sync but rather mesa devs. I got the general impression that AMD/Intel just went with the flow without really caring about performance that much.

        I mean if they did it for a competitive advantage I don't see how it helped, no one seriously uses Linux desktop in the market. The main use for Linux is for compute where NVidia completely dominates and none of these desktop compositing problems are actually relevant.

        Could be wrong but I don't feel like going back through a decade of mailing lists.
        Last edited by mdedetrich; 25 May 2022, 04:46 PM.

        Comment


        • #84
          Originally posted by mdedetrich View Post

          Completely agree with everything you say but was this the case? As far as I am aware it wasn't AMD/Intel engineers that was shitting on NVidia for explicit sync but rather mesa devs. I got the general impression that AMD/Intel just went with the flow without really caring about performance that much.

          I mean if they did it for a competitive advantage I don't see how it helped, no one seriously uses Linux desktop in the market. The main use for Linux is for compute where NVidia completely dominates and none of these desktop compositing problems are actually relevant.

          Could be wrong but I don't feel like going back through a decade of mailing lists.
          I am saying more they could do it, but chose not to, because well it was not beneficial to them.

          Comment


          • #85
            mdedetrich,

            respectfully, you are arguing about woodpeckers destroying your forest while a forest fire is happening a mile down the road. Here are the facts, again.

            * Everyone agree full explicit sync would be a Good Thing(tm). You keep arguing the point. Why?
            * Only Nvidia insist it must be implemented yesterday - since they bet the farm on the technology. Why are kernel / mesa devs obligated to care about that?
            * Nvidia has yet to start cooperating on this issue. Why is this so hard to understand?

            No, cooperation is not "Here is the code, now implement it in the kernel thankyouverymuch," which is essentially what Nvidia did so far. Nvidia is currently showing just about as good a cooperation level as, say, the Microsoft / Nokia partnership.

            These are well documented facts, you living in denial on this issue does not make it better. The issue is Nvidia is not very good at cooperation. The symptom is what you are seeing here - explicit sync being unnecessarily delayed, because noone at Nvidia bothered to ask where the Linux graphics stack was headed.

            Does this make Nvidia evil? No. Merely incompetent.

            Is Nvidia the main stakeholder to see this implemented? Yes. The rest are interested but have already implemented performant implicit codepaths, so they have pretty much no real incentive to change stuff. Even less incentive to not change stuff either, though.
            Last edited by wertigon; 25 May 2022, 08:10 PM.

            Comment


            • #86
              Originally posted by wertigon View Post
              mdedetrich,

              respectfully, you are arguing about woodpeckers destroying your forest while a forest fire is happening a mile down the road. Here are the facts, again.

              * Everyone agree full explicit sync would be a Good Thing(tm). You keep arguing the point. Why?
              * Only Nvidia insist it must be implemented yesterday - since they bet the farm on the technology. Why are kernel / mesa devs obligated to care about that?
              * Nvidia has yet to start cooperating on this issue. Why is this so hard to understand?

              No, cooperation is not "Here is the code, now implement it in the kernel thankyouverymuch," which is essentially what Nvidia did so far. Nvidia is currently showing just about as good a cooperation level as, say, the Microsoft / Nokia partnership.

              These are well documented facts, you living in denial on this issue does not make it better. The issue is Nvidia is not very good at cooperation. The symptom is what you are seeing here - explicit sync being unnecessarily delayed, because noone at Nvidia bothered to ask where the Linux graphics stack was headed.

              Does this make Nvidia evil? No. Merely incompetent.

              Is Nvidia the main stakeholder to see this implemented? Yes. The rest are interested but have already implemented performant implicit codepaths, so they have pretty much no real incentive to change stuff. Even less incentive to not change stuff either, though.
              Because you can rotate question around.

              Why kernel/Mesa drivers should care about it? Isn't it obvious? It affects every single desktop user in performance, and affects every single user in stability of desktop enviroment. Wayland simply fails stability checks even on Intel/AMD comparing to Windows/MacOS/Android.

              Heck, if i would be person developing for 1% desktop users OS my incentive would be primary not to hold status quo but to actually make working system that users can use and has actual advantages over competition. I am developing software and I genuinly love the feeling when software goes to production and actually does work. Holding status quo by MESA developers is absolutly not helping anyone, especially that Nvidia developer like Erik is willing to contribute necessery code to make his driver work. How did you know that EGLstreams had some issues in KDE? Because he himself told you.

              Actually I will rotate question around, with how many non-MESA systems, entire graphic system with Wayland of linux is working well with. Answear is NONE.

              Take biggest operating systems with fairly working well graphics stacks around:
              - Windows - supports Intel, AMD, Nvidia gpu stacks, also we had way more smaller players like Windows for ARM with Qualcomm based laptop.
              - Android - supports Intel, Nvidia, ARM, Qualcomm, Samsung, PowerVR (And way more similar designs to ARM mali like Mediatek), also a lot of those companies have absolutly garbage reputation for their drivers for supporting Opengl or Vulkan and they fail conformance tests,
              - MacOS - in the past AMD, now their own,
              - Linux - outside of MESA there is only Nvidia and propertiary AMD driver. Both fail to work. But even MESA graphic stack i would rate as less stable then ALL OF ABOVE. Most companies with propertiary drivers simply doesn't even think of supporting linux.

              Now again, who has issues with communicating and finding compromises? Microsoft? No. Google? Hella no. MacOS - well that was their design choice. Linux community? Definitly. Nvidia told for years they will have issues with GBM/DMA-BUF.. 90% of community didn't believe them. Well they implement them. Now we see those issues. Who again had issues with communication? The thing is that if you did believe them then either maybe today we would have superior system. Oh yea how long again Ekstrand patches are waiting? More then 2 years? How over 2 years you MESA developers didn't agree on thing between yourself. Fucking heck i made entire systems from analysis to production in less then 2 years. And you linux community can't agree on 1 pull request over 2 years?

              Comment


              • #87
                Originally posted by piotrj3 View Post
                So you have 3 options:
                - extremly oversynchronize everything, and keep Linux a trash system for most normal users, hey let's keep it 1% popularity or even go below, who cares about performance right?

                - making explicit sync work alongside implicit sync (funny the only thing that makes 2 work kind of along is X server) and that is proposition made by Ekstrand (former Intel) and Erik (Nvidia) basicly add some explicit sync to resolve issues of implicit sync, also the most realistic aproach to keep switching piece by piece parts to explicit sync, there are some annoying parts like KMS being entirly implicit but i hope things will get better,

                - move entirly to explicit sync (from AMD employee LOL).
                No there is a four options. AMD employee said move the core entirely to explicit sync but that same employee goes on and suggest a compatibility layer for legacy code.

                The syscalls into the Linux kernel for implicit sync nothing about the Linux kernel stable ABI rules forbids those being I cripple performance if used. Yes the AMD employee who you would have read suggesting the complete core as explicated sync also suggest having a common shared subsystem for legacy implicit sync that emulating implicit sync on top of the core explicit sync.

                The Intel and AMD suggested options both have implicit sync support by some means so not breaking the Linux kernel Stable ABI to userspace.

                The option 1 is not backed by anyone. Nvidia and AMD ideal of move entirily to explicit sync are different. AMD one is that implicit sync will still be support but if used you are using a legacy subsystem that will result in not ideal performance. For glamor doing X11 2d hardware acceleration it being under performing is not a problem. Remember your major applications these days on Linux don't use 2d X11 drawing at all.

                1) the old broken extremly oversynchronize no body wants. This supports implicit sync of course.
                2) Intel progressive mirgration over time while keeping implicit support for legacy on top of explicit sync.
                3) AMD move core completely to explicit sync keep a legacy subsystem for implicit sync so legacy syscalls and legacy code bases can work of course if used causing poor performance.
                4) Nvidia no implicit sync at all pure explicit sync. Any application depending on implicit sync will have to be altered or their will have to be userspace hacks.

                piotrj3 basically AMD and Intel are in kind of agreement here by some means implicit sync will work. If used does not have to perform well.


                And how exactly does this happen? If we're implementing implicit sync, it's the responsibility of the GL driver in use by glamor (and any kernel driver backing it), correct? That's where things get complicated. There's no clear command that signals the GL driver to "latch" the implicit sync fence from the dma-buf by using the ioctl() that converts it to an explicit sync FD, so we just have to continuously monitor all textures/images/whatever in use by any command buffer and try extracting an implicit fence from any of them that are backed by imported dmabufs every time we want to submit commands down the the hardware, in every application, not just Xwayland+glamor, because Xwayland+glamor use the GL driver just like any other app does. That's what I'm talking about by the complexity that I'd prefer to avoid. The performance benefit is precisely avoiding that complexity running in every app.
                What if the Nvidia developer is looking in the wrong place.
                https://01.org/linuxgraphics/gfx-doc...e-poll-support

                Any application using implicit sync on a DMABUF will be performing a poll syscall command on that buffer. Yes the Nvidia developers right this is not by ioctl but by syscall where the signal comes from that a DMABUF is implicit sync. AMD developer noted that.

                Then you go down to Reservation Objects. void dma_resv_init(struct dma_resv * obj) this also has to be called before you have implicit sync on a DMABUF. Then there is another command that free all dma_resv objects. No contents dma_resv buffer is implicit sync structure in fact.

                The dma fence structure reference inside the dma_resv is explicit fence. Just a pollable explicit fence for current status. So in reality all amd and Intel drivers end up doing is processing the list of dma fences to cover all implicit and explicit fences. DMABUF implicit fence is in fact implemented on top of explicit fence structure all the mainline graphics drivers.

                Remember what mdedetrich has written over and over again that implicit sync can be implemented on top of explicit sync. Yes the explicit sync file stuff the Linix kernel that is provided with DMABUF also uses the same dma fence sync explicit structure as the implicit sync of DMABUF uses. Yes android explicit sync uses the same dma fence structure system as the implicit sync does as well.

                So why is the Nvidia developer wanting to know if dmabuf FD implicit or explicit sync since either way it process the same dma fence list from the deep driver side. The difference really is implicit sync the application poll the kernel and its cpu access can be cut off until the sync is ready. This is why implicit sync can dead lock applications if the sync never happens.

                The fact that DMABUF done by AMD and Intel really is Implicit sync on Explicit sync. The results in the Implicit sync overhead being very light there is very little special processing for implicit sync. DMABUF Implicit sync that you have poll the kernel and the kernel can stop giving the application cpu time until the dma fence is ready. This can result in less wasted CPU cycles so a performance improvement in some cases.

                Interesting catch right. Reality if driver is coded right for DMABUF it does not need to know for the hot path that implicit or explicit sync is being used by applications only that all the dma fences that have been allocated have been cleared.

                DMABUF in it design did include the option of building with implicit sync disabled this was for particular devices that delays were a problem. Of course Nvidia seen that switch and gone hey lets switch implicit sync of then we don't have to implement the implicit sync exported functions. Of course they did not look properly at the AMD or Intel drivers mostly due to license to notice that implicit sync is just a wrapper on top of a explicit sync core. Yes DMABUF having explicit sync core was there from the first code of DMABUF.

                Nvidia just add the implicit wrapper code to your driver. Yes still just process the explicit dma fences on your hotpaths and everything will work.

                The fact DMABUF is implicit sync on top of explicit sync is why when it correctly done there is very little performance overhead. Yes magic you don't need to know what is a implicit buffer because everything is a explicit sync buffer with explicit sync structure just that pretends to be implicit buffer when need by having that implemented on top of the explicit sync structures..

                Comment


                • #88
                  Originally posted by piotrj3 View Post

                  Why kernel/Mesa drivers should care about it? Isn't it obvious? It affects every single desktop user in performance, and affects every single user in stability of desktop enviroment. Wayland simply fails stability checks even on Intel/AMD comparing to Windows/MacOS/Android.

                  Heck, if i would be person developing for 1% desktop users OS my incentive would be primary not to hold status quo but to actually make working system that users can use and has actual advantages over competition. I am developing software and I genuinly love the feeling when software goes to production and actually does work. Holding status quo by MESA developers is absolutly not helping anyone, especially that Nvidia developer like Erik is willing to contribute necessery code to make his driver work. How did you know that EGLstreams had some issues in KDE? Because he himself told you.
                  No, the question is not why they should care. The question is why Explicit Sync should be their priority, especially as it would require a rewrite of the entire functioning mesa stack. Sure it may be functioning in the sense of Ankh Morpork (that is, it is moving but far from optimally) - it still functions though.

                  If it doesn't require a rewrite of mesa, then the scope should be small enough for Nvidia alone to do it, and collaborate with rest of the ecosystem to do it.

                  Originally posted by piotrj3 View Post
                  - Windows - supports Intel, AMD, Nvidia gpu stacks, also we had way more smaller players like Windows for ARM with Qualcomm based laptop.
                  I hope you are aware Windows has a stack similar to mesa since Vista? Not 100% identical of course, but similar.

                  Originally posted by piotrj3 View Post
                  - Linux - outside of MESA there is only Nvidia and propertiary AMD driver. Both fail to work. But even MESA graphic stack i would rate as less stable then ALL OF ABOVE. Most companies with propertiary drivers simply doesn't even think of supporting linux.
                  You haven't been keeping tabs on mesa. At all. I am writing this on an Ubuntu 22.04 system with a 6600 running Wayland with two screens. Pretty much *no* hiccups here, apart from the retarded window handling that is a problem for all of Linux right now.

                  Now, are there problems to sort out still, edge cases etc? Yes. But does mesa work? Yes. Case closed.

                  Originally posted by piotrj3 View Post

                  Now again, who has issues with communicating and finding compromises? Microsoft? No. Google? Hella no. MacOS - well that was their design choice. Linux community? Definitly. Nvidia told for years they will have issues with GBM/DMA-BUF.. 90% of community didn't believe them. Well they implement them. Now we see those issues. Who again had issues with communication? The thing is that if you did believe them then either maybe today we would have superior system. Oh yea how long again Ekstrand patches are waiting? More then 2 years? How over 2 years you MESA developers didn't agree on thing between yourself. Fucking heck i made entire systems from analysis to production in less then 2 years. And you linux community can't agree on 1 pull request over 2 years?
                  Again, blaming the kernel devs instead of finding solutions. You seem to be under the misconception that this is ideologically driven. It is not. Nvidias current proposals would break all of backwards compatibility. Which has been explained several times by now. Do it over. Do it proper. Else it will not be accepted.

                  Comment


                  • #89
                    A simple question: the switching in explicit sync would bring benefits to Linux in general? Could vulkan replace Opengl and Egl stack in explicit sync terms? I note that there is a structural issue: the implicit symc implies the rewrite of all drivers for Nvidia and the explicit sync implies the rewrite of the kernel, the graphical environment and several applications for linux developers. I think that this problem cannot be solved.
                    Last edited by MorrisS.; 26 May 2022, 05:20 PM.

                    Comment


                    • #90
                      Originally posted by MorrisS. View Post
                      A simple question: the switching in explicit sync would bring benefits to Linux in general? Could vulkan replace Opengl and Egl stack in explicit sync terms? I note that there is a structural issue: the implicit symc implies the rewritten of all drivers for Nvidia and the explicit sync implies the rewritten of the kernel, the graphical environment and several applications for linux developers. I think tat this problem cannot be solved.
                      There are a few things here.
                      1) AMD and Intel drivers are explicit sync at core.
                      2) Implicit sync is more than one thing.

                      Intel and AMD implicit sync with DMABUF is really implicit sync on top of explicit sync.

                      There is a big difference between implicit sync in the core of the driver and implicit sync on to kernel interfaces.

                      Why is across the kernel boundary from userspace to kernel space having implicit sync beneficial everyone argueing has not thought about. Think about the kernel allocates time slices being able to check the explicit sync status in kernel space as in DMABUF style implicit sync means that if the buffer is not in sync application can be skipped from being give its next time slice then that time slice can be possible give to the process that will make the buffer in sync.

                      Yes the downside of Linux kernel DMABUF implicit sync that you have performed a context switch to kernel and downside it can dead lock your application if the sync never resolves but its dead locked without being giving CPU time it cannot do anything with. Upside you are not wasting CPU slices in basically a spinlock checking explicit sync status because the implicit sync is really checking the explicit sync status kernel side by having something like DMABUF implicit sync.

                      The Linux kernel for applications to work only need implicit sync at the kernel interfaces to userspace to work not that the core driver is explicit sync.

                      The problem here Nvidia examples and arguments don't make sense because most of them are based on the idea that you implement implicit sync in the core of driver not implement implicit sync on top of the drivers explicit sync interfaces as everyone in the Mainline linux graphics stack does. Yes AMD and Intel want more of the core of drivers to be explicit sync but they are not talking about doing in the implicit sync from userspace to kernel. This is part of problem Nvidia is not a major CPU designer or OS designer. Reality here is both AMD and Intel have at different times made their own OS.

                      Yes just because Windows does not do something does not mean Linux does not want it.

                      You are right it absolute dead lock because explicit sync only that Nvidia is offering does not support legacy applications and in particular use case makes the CPU side of the CPU/GPU combination perform badly due to the allocation of time-slice problem.

                      The hard reality is on the CPU side implicit sync where the kernel is able to allocate time slices to processes that can progress forwards and bipass those that cannot does at times result in better performance and better CPU utilisation . Note Nvidia is tunnelled visioned on how they will get better GPU utilisation.

                      With a GPU/CPU sync for graphical combination we don't have something like a futex that can be processed both by kernel and user-space. Lot of ways I think from the userspace side that both implicit sync and explicit sync are wrong because both have the advantages in particular use cases neither is a absolute rounder. This is like general CPU locking before the futex.

                      Yes Nvidia problem here NIH they are not considering what the other parties need. I also think that AMD and Intel are also partly tunnelled version with the split between implicit sync and explicit sync result that something like a futex is not coming into existing for graphical usage that can be processed both by userspace and kernel space equally well so having most of the advantages of both as in reduced context switches from being userspace processed and having to spin in userspace looking for a sync to be resolved so cpu time slices allocated better..

                      Comment

                      Working...
                      X