Announcement

Collapse
No announcement yet.

Microsoft Enables OpenGL 4.6 Support Over Direct3D 12

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

  • #31
    Originally posted by ezst036 View Post

    Do you know if someone has put a feature enhancement into the KDE bugtracker to hopefully discuss and implement KWin-WL-Roots? (and move off of whatever internal/custom implementations they have)
    No, but KWinFT uses wlroots. I've only seen anecdotal comments from people involved with KDE over the years about it being in KWin actual.

    Comment


    • #32
      Microsoft has a long history of perverting open standards, developing forks that only work on Windows. Aka EEE. They heavily promote their broken bastardized version for financial benefit, via vendor lock-in. This is not opinion, this is historical record. For this reason, anytime Microsoft claims to have adopted a new open standard, those who have been around this industry for a while are rightly concerned. We know the beast, we know its patterns. Microsoft developing an OpenGL compatibility layer is not EEE on it's own... but history tells us it's step 1. Step 2 is to break compatibility via proprietary extensions, or otherwise incentivize developers to write code that only works on Windows. We've been down this path many times before. If you think Microsoft is doing this for any reason other than to move developers from Linux to Windows, you must be new around here.

      Comment


      • #33
        Originally posted by skeevy420 View Post

        Like piotrj3 said, open standards are precisely how you infiltrate and EEE because Extend isn't normally done on proprietary applications. [...]
        Originally posted by piotrj3 View Post

        Exactly opposite. You need open standard to make EEE work. You take standard, you extend it in proprietary way, and you disadvantage competitors from not supporting them. [...]
        Originally posted by coder View Post
        Depending on what you mean by that, it definitely applies to open standards. The "extend" phase is where someone adds a nonstandard extension to their implementation, but has enough market power to make it defacto-standard.
        ​​You're right, "extend in proprietary way". That's why it clearly doesn't apply to Wayland (or X11 and Linux) in any way because Wayland is extended in open way. It's not like GNOME or somebody else want to have something in Wayland so it just throws it and tells to others that they need to support it. Creating new standard in Wayland requires agreement from compositors developers. Just take a look at merge requests for wayland-protocols repository and you will see that not only GNOME developers are participating in discussions there but also KDE and wlroots/Sway developers. How is that EEE?

        Microsoft work on Mesa is also not an example of EEE. It would be if they would fork Mesa and create their own "enhanced" Mesa with those features (just like they did with Java) but since they upstream all of their code, there is no EEE here. EEE is not an insult to describe whatever somebody may don't like or when some corporation add their stuff to open source project. It's specific term that clearly doesn't apply here.
        Last edited by dragon321; 22 November 2023, 11:33 AM.

        Comment


        • #34
          Originally posted by dragon321 View Post





          ​​You're right, "extend in proprietary way". That's why it clearly doesn't apply to Wayland (or X11 and Linux) in any way because Wayland is extended in open way. It's not like GNOME or somebody else want to have something in Wayland so it just throws it and tells to others that they need to support it. Creating new standard in Wayland requires agreement from compositors developers. Just take a look at merge requests for wayland-protocols repository and you will see that not only GNOME developers are participating in discussions there but also KDE and wlroots/Sway developers. How is that EEE?

          Microsoft work on Mesa is also not an example of EEE. It would be if they would fork Mesa and create their own "enhanced" Mesa with those features (just like they did with Java) but since they upstream all of their code, there is no EEE here. EEE is not an insult to describe whatever somebody may don't like or when some corporation add their stuff to open source project. It's specific term that clearly doesn't apply here.
          Propertiary way doesn't mean necesserly closed source in this case. Let's imagine abstract situation:

          - Google tomorrow (well ad company loves fingerprinting users) says tomorrow we will make Motherboard API in google chrome that will expose motherboard number to internet. They give some bullshit reason like autodetectecting what mobo you have to download drivers from internet. They literally read string from system info or other place and pass it to internet. They don't give a shit about standards. For some reason they also make it necessery to let's say use youtube.
          - Firefox is in wierd situation. They have to support it but obviously don't want to send to internet such thing. So Mozilla now brainstorms what to do. Every hour they lose users because youtube doesn't work. But it is obvious they cannot expose such thing to internet. So they make a new thing that fakes it. Random string. Well it kind of works. Until some legitimate use case like OEM manufacture want to use that feature for sake of giving drivers and Firefox won't work again. So mozilla implements entire settings page to be able to pick when to use fake and when to use real whitelist page settings, dialogues GUI etc.

          Not only Mozilla lost on it, they also spend way more engineering hours while technically chromium shows greatly how it exposes such info to internet.

          So when such things don't happen - well when you make API/standard/anything you make RFC (Request for comment) or standard and publish it somewhere and ask for opinions suggestions criticism from other sides and generally in the end you need some sides to shake hands. Gnome/Mutter developers in my opinion do not shake hands to a lot of things that competitor wants or need. Explicit sync is hilarious case like every GPU maker wants it, KDE is fine with it, WLroots want it, and gnome people still want implicit and don't care about problems Nvidia has or someone else..

          Comment


          • #35
            Originally posted by piotrj3 View Post

            Propertiary way doesn't mean necesserly closed source in this case. Let's imagine abstract situation:

            - Google tomorrow (well ad company loves fingerprinting users) says tomorrow we will make Motherboard API in google chrome that will expose motherboard number to internet. They give some bullshit reason like autodetectecting what mobo you have to download drivers from internet. They literally read string from system info or other place and pass it to internet. They don't give a shit about standards. For some reason they also make it necessery to let's say use youtube.
            - Firefox is in wierd situation. They have to support it but obviously don't want to send to internet such thing. So Mozilla now brainstorms what to do. Every hour they lose users because youtube doesn't work. But it is obvious they cannot expose such thing to internet. So they make a new thing that fakes it. Random string. Well it kind of works. Until some legitimate use case like OEM manufacture want to use that feature for sake of giving drivers and Firefox won't work again. So mozilla implements entire settings page to be able to pick when to use fake and when to use real whitelist page settings, dialogues GUI etc.

            Not only Mozilla lost on it, they also spend way more engineering hours while technically chromium shows greatly how it exposes such info to internet.

            So when such things don't happen - well when you make API/standard/anything you make RFC (Request for comment) or standard and publish it somewhere and ask for opinions suggestions criticism from other sides and generally in the end you need some sides to shake hands. Gnome/Mutter developers in my opinion do not shake hands to a lot of things that competitor wants or need. Explicit sync is hilarious case like every GPU maker wants it, KDE is fine with it, WLroots want it, and gnome people still want implicit and don't care about problems Nvidia has or someone else..
            I didn't say that it needs to be closed source. Still Wayland is not example of that when not only GNOME developers are working and approving new interfaces.

            As for the GNOME "not shaking hands with competitors" - this is not always true. For example GNOME implemented fractional scale protocol despite the fact that they don't support it on GTK so it's not needed for them. As for the explicit sync, there is PR for GNOME but it's not merged due to fact that it's still not complete. GNOME doesn't implements interfaces that are not part of Wayland and explicit sync interface is still not (merge request is still open). wlroots didn't implement this as well for same reasons. No idea about KDE.

            Comment

            Working...
            X