Announcement

Collapse
No announcement yet.

A Major Rework To The X.Org Video Driver ABI

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

  • #16
    Originally posted by jrch2k8 View Post
    * you are assuming that Xorg X11 and wayland can't coexist, good news they can, in fact wayland faq (free to read btw) state this scenario and there is a ton of mailing list messages about this with many good ideas.
    They don't coexist in a way that's useful for workstation people, though. They use a lot of features that I don't think Wayland supports (though I'd love to be proven wrong). Can you span your Wayland desktop over 8 GPUs? With the displays framelocked? With stereoscopic 3D enabled? Can you use your CAD program written a decade ago and requires overlays in your X-on-Wayland emulator?

    Comment


    • #17
      Originally posted by jrch2k8 View Post
      BTW nvidia is not against wayland is against to do the job so early in the development process which make sense, wayland will require some drastic changes for nvidia and is not even installed on distros not even QT or GTK are fully there yet. Once wayland is fully supported on KDE and GNOME and installed by default (probably ubuntu) then nvidia will support it.
      I absolutely agree... It costs nVidia big money to support a platform (whether it be Linux or Windows). nVidia has said in the past, that they already spend more money researching and developing software (drivers / games / etc) than they do hardware and so they consider themselves a software company..

      They're not going to be making two separate drivers for Linux , that's just a waste of money. As a Linux user and also nVidia investor, I'm glad they're not making drivers for both Wayland and X11.. Too expensive to support and too few people running Wayland..

      Wayland is far too unstable and undeveloped to be putting serious resources into it.. Let Intel run their little toy graphics hardware on Wayland with their drivers to get the bugs and features worked out in Wayland before the heavyweights (nvidia & AMD) make the switch.

      Comment


      • #18
        Originally posted by md1032 View Post
        They don't coexist in a way that's useful for workstation people, though. They use a lot of features that I don't think Wayland supports (though I'd love to be proven wrong). Can you span your Wayland desktop over 8 GPUs? With the displays framelocked? With stereoscopic 3D enabled? Can you use your CAD program written a decade ago and requires overlays in your X-on-Wayland emulator?
        wayland is an extensible compositor so in theory in a more mature stage it probably can sync and render in many gpus as long those have proper KMS support since its only matter of managing wich data goes to which mapped framebuffer.

        stereoscopic 3d has nothing to do with wayland, that is MESAs job

        overlay is a MESA job too

        your cad program can run in 2 scenarios

        1. in a native X11 ambient (like i said a zillion times before wayland and X11 libraries can even be installed at the same time and with a wrapper or distro provided tool you can switch between both since for that time KDE and GNOME and others will support both 100%)

        2. in theory when using wayland first and x11 on top it should work without much hassle because x11 will have drivers DDX and input drivers (someone is working on this, check mailing list) that inform wayland what and how to render from the Xserver and as long MESA support overlay this app should work fine since the apps will never interact with wayland directly. now some very old extensions of X11 could be problematic but in that case you can always go to 1.

        just a note, wayland target in the short timeline is not RHEL for god sakes even today redhat 6 don't support even composited desktops (not 100% sure but last beta i tested of 6.0 didnt have aiglx active) so for workstation users it probably won't matter since probably redhat will support X11 for much more time and in the case they support wayland they will always provide an alternative installation or userspace tool to go back to X11 to keep supporting Legacy Apps. are you really a workstation user?

        wayland target is the 6 months distro like ubuntu or fedora which always come with the latest software and this Distro ARE NOT MEANT FOR WORKSTATION USERS since these distro are extremely variables so i really doubt you CAD 10 years old app will run in ubuntu 11.10 or fedora 16 flawlessly to begin with, and even so im damn sure all distro will provide userspace tools to switch back to X11 in case you need to support legacy apps. IS COMMON SENSE

        Comment


        • #19
          Originally posted by allquixotic View Post
          3. With all this backwards compatibility (which will be needed for at least a decade for all but the most basic users) why not just stick with Xorg to begin with, and evolve the Xorg platform to be as good as Wayland?
          The reason not to do this, of course, is manpower. The X/Mesa projects are already incredibly short on it. Adding to their workload is the last thing we want to do, unless it really is necessary.

          I'm not sure I buy that something like Optimus will still be needed in X 10 years from now. It seems to me like that is a technology that could be worked into Wayland, and if you want it then you run Wayland and just nest X inside it as needed. I'm guessing that kind of support should be possible in 4 years, even if we need to keep X around to be nested for a lot longer.

          4. Proprietary driver companies have been strongly anti-Wayland up to this point
          They have? I don't think I've seen anything of that sort from either company - they've merely stated that Wayland isn't ready yet. I don't think anyone expects them to start supporting Wayland while it's still broken and constantly having it's API broken - that might even be counterproductive at this point. In the long run, supporting Wayland should be easier that X for AMD/NVidia, so I would be very surprised if they don't eventually start backing it.

          , so unless that attitude changes, there will be no way to have OpenGL 3.x or 4.x support on GNU/Linux. This, to me, is totally unacceptable. I'm not saying that every user needs GL 3 / 4, but those who do, should be able to get it.
          Well, GL3 support should be in Mesa by January. I assume what you really mean here is professional, high-performance drivers, more than just GL3 or GL4. I'd also like to just note that OSX doesn't even support GL3 yet, and no one seems to think that's killing it off.

          Wayland needs to continue to evolve at its own pace and prove itself, and gain vendor support (from proprietary driver teams at ATI and Nvidia, primarily). Wayland can be the future. But we shouldn't just abandon all efforts to make our current solution as good as possible while we're still using it.
          I actually agree with this 100%. There is a line, however, where you wonder if radical rewrites of APIs should just be put off for a while longer to see if it's really needed or not. That line is blurry, and a lot probably depends on how important Red Hat views the project and how far out they view Wayland as coming.

          Comment


          • #20
            Originally posted by cl333r View Post
            I wonder what's so wrong with the X.org video ABI that it needs a rewrite?
            Ditto...why not just clean up the bugs and streamline the ABI a bit so that both FOSS and proprietary drivers can be easier to maintain as well as having the ABI being stable.

            Comment


            • #21
              According to my info.
              Mac OS 10.7 supports OpenGL 3.2.
              http://developer.apple.com/graphicsi...1070_Core.html

              Comment


              • #22
                Originally posted by cl333r View Post
                I wonder what's so wrong with the X.org video ABI that it needs a rewrite?
                Originally posted by DeepDayze View Post
                Ditto...why not just clean up the bugs and streamline the ABI a bit so that both FOSS and proprietary drivers can be easier to maintain as well as having the ABI being stable.
                Newer laptops with nVidia optimus and other technologies that render with one GPU and then pass it through to another GPU that's attached to a monitor for display.. Apparently doing this in Xorg currently requires nasty hack-jobs to get the job done.. (ala BumbleBee)... That's why the ABI is changing.. Hopefully these ABI changes will bring better nVidia optimus compatibility as well as things like Hybrid SLI / Hybrid Crossfire..

                I was looking at buying a laptop with an nVidia GPU, but then realized that nvidia does not support their laptop GPUs on Linux anymore unless you buy a laptop with a hardware GPU switch / mux.. I wanted to blame nVidia for that, but really, the problem is in Xorg because it just can't switch back and forth between two completely different GPUs (nvidia and Intel) seamlessly while sending the video out to the same display... All Intel laptop CPUs now have GPUs in them and they're hooked up directly to the laptop's display whether you have another discrete GPU or not.. So that's a serious problem for Xorg unless you have a hardware switch where you can choose which GPU you connect your laptop's LCD display to.. Most nVidia optimus laptops don't have these hardware switches, but some laptop manufs. are providing them so that people can use their discrete GPU in Linux..
                Last edited by Sidicas; 09-22-2011, 04:53 PM.

                Comment


                • #23
                  Best of both worlds?

                  Merging the drivers back in isn't strictly necessary for a massive ABI rework. This ABI rework can be a cut off point like when Microsoft went from XP to Vista/7. Current drivers won't be expected to work with Xorg releases after the rework, and new drivers released after the masive ABI break won't be expected to work with older versions of Xorg.

                  For newer releases of Xorg after the ABI rework, we could go back to the current model of allowing drivers to work with multiple versions of Xorg (provided the Xorg versions in question have come after the ABI rework). Then we can repeat this process the next time a massive reworking of the ABI is needed.

                  Comment


                  • #24
                    These constant large changes to the linux graphics framework is probably one of the reasons hardware manufactorers don't like supporting linux.

                    Comment


                    • #25
                      Originally posted by bwat47 View Post
                      These constant large changes to the linux graphics framework is probably one of the reasons hardware manufactorers don't like supporting linux.
                      is unavoidable for now, remember that unlike windows or other commercial OSes linux didn't have a graphic framework or something close enough to handle anything beyond opengl 1.X and basic Xrender accel.

                      so is not like linux have an stable framework and developers are messing with it cuz the fun of it, is more like linux next generation graphic framework is still on early alpha state (nobody has say is stable to begin with) in which state is normal and necessary to mess with the API until you reach certain goals and pass it to production level.

                      this process from thinking the platform up to today alpha code has taken like 5 years and i believe it will take another year at least to have something close to a beta more stable codebase with at least GL 3 and other goodies like openVG, etc.

                      why has taken so long? you may ask

                      1. if you have to put a scale in the quality of developers needed to write gpu drivers and the entire graphic subsystem from 1 to 10, it would require level 11 developers and those are not easy to find and is especially hard to find them to work in an open project, so right now in the entire graphic stack linux have like 10 developers that commit code in their free time and like 3 or 4 full time to contrast it with something, is pretty close to say that microsoft and nVidia for example have around 300 developers full time dedicated to this task on windows and drivers respectively and still you found serious bugs in windows/DirectX (remember windows vista nasty bugs in directx that at the end forced microsoft to rebrand Vista SP2 + some goodies into windows 7 and that even required a massive patch in the Directx subsystem and drivers)

                      2. unlike windows or Mac that had incrementally reached a moderm graphic framework over years of releases this 4 + 10 ish guys have to do it from scratch and in a way that can be maintained over time without years of previous experience or code before them, so is easy to complain but is a real titanic task that these guys are taking off and so far is pretty damn impressive work considering the facts

                      Comment


                      • #26
                        Originally posted by hiryu View Post
                        Merging the drivers back in isn't strictly necessary for a massive ABI rework. This ABI rework can be a cut off point like when Microsoft went from XP to Vista/7. Current drivers won't be expected to work with Xorg releases after the rework, and new drivers released after the masive ABI break won't be expected to work with older versions of Xorg.

                        For newer releases of Xorg after the ABI rework, we could go back to the current model of allowing drivers to work with multiple versions of Xorg (provided the Xorg versions in question have come after the ABI rework). Then we can repeat this process the next time a massive reworking of the ABI is needed.
                        Very good point, or at least merge the drivers temporarily while the rework is being done so that the drivers also get equal attention, then once the new ABI is stable and relatively bug-free split the drivers out again

                        Comment


                        • #27
                          Originally posted by plonoma View Post
                          According to my info.
                          Mac OS 10.7 supports OpenGL 3.2.
                          http://developer.apple.com/graphicsi...1070_Core.html
                          Ah, that's interesting. I hadn't heard that 10.7 had added that. Looks like you only get 3.2 in Core mode, though, so most apps will continue seeing only GL2 support while it allows new ones to access GL3.2.

                          Comment


                          • #28
                            Originally posted by DeepDayze View Post
                            Very good point, or at least merge the drivers temporarily while the rework is being done so that the drivers also get equal attention, then once the new ABI is stable and relatively bug-free split the drivers out again
                            I thought of that too, and it might work, but I think a temporary merge would find itself becoming permanent given the circumstances.

                            Comment

                            Working...
                            X