Announcement

Collapse
No announcement yet.

Whoops, There's A Big Problem For Wayland GTK+

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

  • #31
    Wayland requires kernel modesetting, or kms. It DOES NOT require KMS. Notice the difference in capitalization.

    The nvidia and fglrx blobs already contain working kms systems in their drivers - they just use a different API than the open source drivers do (KMS).

    That means those drivers just have to patch Wayland to interact with their own kernel drivers instead of the OSS APIs. That should be very simple to do, as Wayland handles that code very cleanly. Their drivers already have to heavily patch X to get it to work, so they just have to do the same thing to Wayland, but it will be much easier.

    Comment


    • #32
      Originally posted by smitty3268 View Post
      That means those drivers just have to patch Wayland to interact with their own kernel drivers instead of the OSS APIs. That should be very simple to do, as Wayland handles that code very cleanly. Their drivers already have to heavily patch X to get it to work, so they just have to do the same thing to Wayland, but it will be much easier.
      They also require being able to access the graphics drivers and GL calls from outside of the GLX-based libGL API and via EGL.

      I do not believe that the binary drivers offer any of that right now.

      Comment


      • #33
        Originally posted by elanthis View Post
        They also require being able to access the graphics drivers and GL calls from outside of the GLX-based libGL API and via EGL.

        I do not believe that the binary drivers offer any of that right now.
        I thought every GL ES driver had EGL support in it, but i guess i could be wrong. EGL support is about more than just Wayland or linux, though, so i definitely think the binary drivers will want to support that eventually if they don't yet.

        Comment


        • #34
          Originally posted by elanthis View Post
          They also require being able to access the graphics drivers and GL calls from outside of the GLX-based libGL API and via EGL.
          I do not believe that the binary drivers offer any of that right now.
          Originally posted by smitty3268 View Post
          I thought every GL ES driver had EGL support in it, but i guess i could be wrong. EGL support is about more than just Wayland or linux, though, so i definitely think the binary drivers will want to support that eventually if they don't yet.
          http://phoronix.com/forums/showthrea...869#post254869

          Comment


          • #35
            Originally posted by RussianNeuroMancer View Post
            Tegra has nothing todo with the Geforce cards. And they Support egl because tegra is there embedded gpu and kms is supported because the kernel module is GPL compatible.

            Comment


            • #36
              Originally posted by Nille View Post
              Tegra has nothing todo with the Geforce cards. And they Support egl because tegra is there embedded gpu and kms is supported because the kernel module is GPL compatible.
              Some people in this thread really believe that EGL and KMS never can be implemented in proprietary drivers. AMD embedded drivers and nVidia Tegra drivers is good living example that proof one simple fact - this is possible. So when Wayland will be ready - nVidia and AMD driver developers have no choice but implement needed functional in proprietary drivers for desktop and laptops GPU's.

              Comment


              • #37
                Originally posted by RussianNeuroMancer View Post
                Some people in this thread really believe that EGL and KMS never can be implemented in proprietary drivers.
                Maybe but this is not opinion. My post is only related to you tegra comment The tegra driver is different from the "nvidia" driver so you can't compare both drivers.

                Comment


                • #38
                  Originally posted by Nille View Post
                  The tegra driver is different from the "nvidia" driver so you can't compare both drivers.
                  I doesn't compare it, if you didn't notice.

                  Comment


                  • #39
                    Originally posted by RussianNeuroMancer View Post
                    Some people in this thread really believe that EGL and KMS never can be implemented in proprietary drivers. AMD embedded drivers and nVidia Tegra drivers is good living example that proof one simple fact - this is possible. So when Wayland will be ready - nVidia and AMD driver developers have no choice but implement needed functional in proprietary drivers for desktop and laptops GPU's.
                    I for one am not saying it can't be done, I'm saying I believe said companies won't be bothered to do so. As I said before, X isn't going anywhere for a while, binary blob primary targets being workstations, what is their incentive? Someone mentioned using wayland on a worksation is possible, I agree, but AFAIK most workstations use applications written for X, some of them proprietary. I'm not saying it won't happen, I just don't believe it will; but would however love to be proven wrong.
                    As for the not having any choice, I'm afraid they do have a choice : they can simply flip us off.

                    Comment


                    • #40
                      Originally posted by Serafean View Post
                      As for the not having any choice, I'm afraid they do have a choice : they can simply flip us off.
                      They doesn't have reasons to flip us off because all needed stuff is already written, they just need to port it from embedded drivers to desktop drivers.

                      Comment


                      • #41
                        Originally posted by RussianNeuroMancer View Post
                        They doesn't have reasons to flip us off because all needed stuff is already written, they just need to port it from embedded drivers to desktop drivers.
                        They do have reasons, the main one would be they must pay for that porting, and it's not focused to their main target.

                        Comment


                        • #42
                          Originally posted by mrugiero View Post
                          They do have reasons, the main one would be they must pay for that porting, and it's not focused to their main target.
                          Laptops with hybrid graphics is not main target for AMD, but they support it in fglrx, HTPC is not main target for nVidia, but they support HDMI audio bitstreaming. They already pay for support this and other features, even less important. Since Wayland is more important they will support it anyway.

                          Comment


                          • #43
                            Originally posted by RussianNeuroMancer View Post
                            they just need to port it from embedded drivers to desktop drivers.
                            In case of AMD the have an egl Implementation in the fglrx driver.

                            Comment


                            • #44
                              Originally posted by Nille View Post
                              In case of AMD the have an egl Implementation in the fglrx driver.
                              Really? Bridgman say some time ago there is packaging problems with EGL in desktop driver. You mean desktop driver or embedded driver? Embedded driver have EGL, yes.

                              Comment


                              • #45
                                5 pages of comments and nobody read/understood the article, the usual for Phoronix. Anyway, if anybody is interested in the real problem here is a summary:

                                1. When building GTK+ with Wayland support memory usage will increase when running on regular X11, so it has nothing to do with nVidia supporting Wayland.

                                2. This is because nVidia builds their drivers with position dependant code, which is slightly faster but can not be shared between different programs (so it gets duplicated for each program running that uses GTK+)

                                3. It only happens for 32 bit applications, because the AMD64 architecture doesn't support shared libraries built with position dependant code so nVidia was forced to fix their 64 bit driver.

                                Comment

                                Working...
                                X