Announcement

Collapse
No announcement yet.

NVIDIA 510.68.02 Released As A Minor Bug Fix Update

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

  • BadGuitarist
    replied
    Looks like with this version they've introduced a new bug, because after this update now my Ubuntu 22.04 with kernel 5.17 doesn't suspend anymore.

    Leave a comment:


  • Myownfriend
    replied
    [QUOTE=piotrj3;n1321459]
    James Jones is a little wrong here. I mean it is not wrong that Wayland does support experimental explicit sync extension, the issue is, it doesn't quite work because:
    a) it would require that every single compositor like kwin is written using it.
    b) it doesn't work because moment you want to flip the buffer you realize KMS doesn't support it. So everything you flip is going through entire compositor and cannot be scanned out directly. And since compositors are implicit sync, you end up implicitly syncing window as well.

    The reason I quoted that was more to do with X not supporting explicit sync so the idea that this is all a Wayland problem is very wrong. Wayland is the part of the stack that does support explicit sync, it's X and the rest of the stack that don't.

    I don't think every compositor would need to support it before it's of any use. Jason Eckstrand's proposal would allow the driver to handle the conversion from implicit to explicit sync.


    Leave a comment:


  • piotrj3
    replied
    Originally posted by Myownfriend View Post

    How is it that Wayland is stuck in the 90s? Were compositing window managers even a thing in the 90s? If you're just talking about implicit vs explicit sync, that's not a Wayland problem, that's a Linux problem. As dragon mentioned, there is an unstable Wayland protocol for explicit sync and according to James Jones, "The only major component of the graphics stack that doesn't support explicit sync is X"
    James Jones is a little wrong here. I mean it is not wrong that Wayland does support experimental explicit sync extension, the issue is, it doesn't quite work because:
    a) it would require that every single compositor like kwin is written using it.
    b) it doesn't work because moment you want to flip the buffer you realize KMS doesn't support it. So everything you flip is going through entire compositor and cannot be scanned out directly. And since compositors are implicit sync, you end up implicitly syncing window as well.

    Leave a comment:


  • Myownfriend
    replied
    Originally posted by piotrj3 View Post

    More like Wayland is stuck in 90s, and Nvidia was leading innovation and now they cannot implement properly all backwards tricks.
    How is it that Wayland is stuck in the 90s? Were compositing window managers even a thing in the 90s? If you're just talking about implicit vs explicit sync, that's not a Wayland problem, that's a Linux problem. As dragon mentioned, there is an unstable Wayland protocol for explicit sync and according to James Jones, "The only major component of the graphics stack that doesn't support explicit sync is X"

    Leave a comment:


  • Myownfriend
    replied
    Originally posted by openminded View Post
    Well, I phrased it wrong way, I meant there're still many projects that cannot interact with screen content as easily as they do it when running in Xorg session, e.g. hyperion-project. Quirks here and there, that's what I meant.
    X doesn't really offer a proper solution for screen capture. Applications essentially just take advantage of a vulnerability in X that lets all applications see every other applications content.

    Hyperion would be able to support screen capture under X11 and Wayland just by using Pipewire. I'm assuming it doesn't because it mentions that its most commonly used on the Raspberry Pi and Raspberry Pi OS only just started supporting Wayland.

    Leave a comment:


  • Myownfriend
    replied
    Originally posted by openminded View Post

    This isn't hatred, just naked truth. There's no feature parity between X11 and Wayland still. Color correction, screen capture and so on - Wayland has a number of milestones to pass in order to become a viable alternative to X11. Aside from that implicit sync idiocy mentioned above.
    You can do screen capture on Wayland just not via Wayland. That's fine.

    What are you talking about in regards to color correction? DRM itself supports CLUTS whether or not a Wayland or X11 session is active and to my knowledge the gamma adjustment that X11 supports is full-screen only as was used by some games to adjust their own gamma. The color extensions that Wayland will support will support per-application color and HDR which will allow SDR and HDR applications to both be displayed correctly next to each other on the same screen.

    As for the implicit vs explicit sync thing, Nvidia is correct that Linux should be moving towards explicit sync, that being said, they're not doing much to help it. One of the heads of Mesa has been trying. Also James Jones said years ago that GBM could be modified to support explicit sync and others working on the Linux graphics stack thought that was a good idea since things were already using it but Nvidia decided to keep push EGLStreams instead.

    Leave a comment:


  • openminded
    replied
    Well, I phrased it wrong way, I meant there're still many projects that cannot interact with screen content as easily as they do it when running in Xorg session, e.g. hyperion-project. Quirks here and there, that's what I meant.

    Leave a comment:


  • dragon321
    replied
    Originally posted by openminded View Post

    This isn't hatred, just naked truth. There's no feature parity between X11 and Wayland still. Color correction, screen capture and so on - Wayland has a number of milestones to pass in order to become a viable alternative to X11. Aside from that implicit sync idiocy mentioned above.
    There is no feature parity between X11 and Wayland and won't be. It's not needed because there is no point of creating yet another big server that does everything. This is also "naked truth". I wonder why you mentioned screen capture. It was solved months ago and in better way than X11 does. As for implicit sync - X11 does this as well.

    Originally posted by piotrj3 View Post
    But Wayland does something inexplainably stupid, it combines low level with implicit sync.
    Wayland was created for desktop and before low level APIs with explicit sync like Vulkan even existed. Implicit sync for desktop it's not terribly wrong idea. It's also not just Wayland issue - X11 assume this as well, so this point is not very good for proving X11 superiority. And this is not even the biggest issue in X11 sync. Wayland has protocol for explicit synchronization for buffers on a per-surface basis. I believe there was open merge request to add something similar to X11 as well but I don't know any details.
    Last edited by dragon321; 27 April 2022, 04:02 AM.

    Leave a comment:


  • openminded
    replied
    Originally posted by Hibbelharry View Post

    Haters gonna hate.
    This isn't hatred, just naked truth. There's no feature parity between X11 and Wayland still. Color correction, screen capture and so on - Wayland has a number of milestones to pass in order to become a viable alternative to X11. Aside from that implicit sync idiocy mentioned above.

    Leave a comment:


  • piotrj3
    replied
    Originally posted by bearoso View Post
    The driver is actually stuck in the 1990s. Nvidia only seems to want to focus on the use-case of one hardware-accelerated application at a time taking up the whole screen. That seems to work well. But add a second program multitasking or redirection like a compositor and it chugs. It's a shame, since they made it work fine on Windows.
    More like Wayland is stuck in 90s, and Nvidia was leading innovation and now they cannot implement properly all backwards tricks.

    Leave a comment:

Working...
X