Announcement

Collapse
No announcement yet.

An Update On The OpenGL 3 Support In Mesa

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

  • #31
    Originally posted by RealNC View Post
    The effort (in other words, cost) required to write a binary driver for Linux is higher compared to systems that use a driver ABI. So some vendors won't bother writing one. The quality of the binary drivers of vendors who actually write binary Linux drivers would probably increase if they were offered an ABI.

    Lower cost to support a platform means more support for that platform. You cannot really force vendors to offer source code and docs with Linux, because in order to do so you must be a force to be reckoned with. If sales of vendors are 95% Windows+Mac, then the rest can be ignored.
    What you are looking for already exists. It's called FreeBSD. A stable kernel ABI, great - now where are the drivers?

    In short, your whole argument is bogus.

    Comment


    • #32
      Originally posted by BlackStar View Post
      No, they don't. Proprietary Intel drivers do not support OpenGL 3 (nevermind 4), proprietary Ati R500 / Nvidia 6x00/7x00 drivers do not expose OpenGL 3 features (even though they could) and Apple does not support OpenGL 3 at all. Snap out of it.
      Compare the speed of the Intel binary driver with the open source one. Same for radeon vs fglrx and nuveau vs nvidia.

      Also, prop drivers support GL3 on newer cards for a while now. The open ones don't.

      And btw, "snap out" of what?

      OSS driver support has exploded since Ati released the docs. Just go install a 3-year-old distro and see what I mean.
      Needing 3 years to get usable is not my definition of "exploded." And we're still not there. Speed is slower, power management isn't that good, features are missing.

      Comment


      • #33
        Originally posted by BlackStar View Post
        What you are looking for already exists. It's called FreeBSD. A stable kernel ABI, great - now where are the drivers?

        In short, your whole argument is bogus.
        FreeBSD is something no one uses. Linux at least has its 2 or 3% market share. FreeBSD is like sub-zero market share. Vendors aren't interested at all.

        So how does that make my argument bogus?

        Comment


        • #34
          People are getting stuck on the issue of GPU drivers which are very important, but completely and utterly atypical when it comes to device drivers.

          GPU drivers are insanely complicated because supporting a GPU fully nowadays pretty much means that you have to write a complete operating system kernel (minus filesystems and mouse management, basically).

          For the VAST majority of devices out there, nobody would dream about having binary blobs injected into Linux.

          So it's expected that free drivers would lag behind when it comes to graphics, but it is all the more important that they continue to be developed, because GPUs are so central to modern computers that you simply CANNOT afford to have them all be hidden behind a thick layer of voodoo.

          A recent bug in nvidia drivers was apparently caused by the drivers intercepting kernel system calls in order to fix a GL+thread issue, and ended up breaking non-GL applications.

          Why the holy *^%$ does a GPU driver do this? WHAT does it do exactly?

          Comment


          • #35
            Originally posted by RealNC View Post
            Needing 3 years to get usable is not my definition of "exploded." And we're still not there. Speed is slower, power management isn't that good, features are missing.
            If you consider how complex these drivers are and how few people are working on them, then yes, they exploded. The R300 drivers are fully-featured, including powersaving, suspend, and full OpenGL support. On some hardware, they are even approaching the binary blob performance according to recent benchmarks and developer comments.

            THAT is what Linux needs, not sucking up to binary developers.

            Comment


            • #36
              Originally posted by RealNC View Post
              Compare the speed of the Intel binary driver with the open source one. Same for radeon vs fglrx and nuveau vs nvidia.

              Also, prop drivers support GL3 on newer cards for a while now. The open ones don't.

              And btw, "snap out" of what?
              Proprietary drivers from Intel and Apple still do not support OpenGL 3. Open-source Intel is *ahead* of its closed-source counterpart in extensions - not to mention much more stable. R600 is ahead of Apple's drivers in almost all areas. Even Nouveau runs my GL3-backported-to-GL2 apps almost perfectly (which is much more than can be said for Apple's driver stack).

              Snap out of your trance, obviously.

              FreeBSD is something no one uses. Linux at least has its 2 or 3% market share. FreeBSD is like sub-zero market share. Vendors aren't interested at all.
              Yeah, well, vendors aren't interested in Linux either. Yet we somehow manage to have more plentiful and more robust drivers, despite our lack of a stable kernel ABI.

              You argued that the unstable ABI hurt Linux, remember? If so, where's your evidence?

              Comment


              • #37
                Originally posted by pingufunkybeat View Post
                If you consider how complex these drivers are and how few people are working on them, then yes, they exploded. The R300 drivers are fully-featured, including powersaving, suspend, and full OpenGL support. On some hardware, they are even approaching the binary blob performance according to recent benchmarks and developer comments.

                THAT is what Linux needs, not sucking up to binary developers.
                Well said.

                Comment


                • #38
                  Originally posted by TemplarGR View Post
                  r600c never failed me. It may not play all games or play them fast, but it gives me no headaches on my everyday work, unlike catalyst before it(even on Ubuntu). The few times i wanted to play a game(3 games ME2 Creed 2 Starcraft 2), i installed Win 7(there is a handy 30 day trial period), played(or simply tested) it, and then formated it again. Yeap, that simple. I prefer the hustle of formatting than the hustle of Wine. If there were a few more games i 'd like to play, i would buy a console instead. Gaming on PC makes no significant difference anymore...

                  I would love to not have to do that. I would love the r600c to have a faster implementation plus GL3. But this is just a luxury feature for me. Although i want it, i am not bashing the devs for their efforts, they are doing everything they can and i am happy with their results. I am using their driver and will continue to use it no matter what. When the next games that interest me go out, i will play them on Win 7 again, and i will get back to Linux and radeon driver after that.

                  Instead of bashing and complaining, see if you can help them. A few days back i decided to help them with feedback on their driver. Installed almost all games and apps on this page

                  http://www.x.org/wiki/RadeonProgram

                  and updated the matrix with Mesa 7.9 results. It may not be code, but it is something... Everything helps.

                  I have been silently watching Mesa mailing list and studying the code, in order to be able to contribute. Unfortunately i have a lot of work at this time, and soon i will join the army for some months, so my plan to contribute has to wait until next Christmas. But my thoughts so far are that it is not that difficult. It surely is a lot of work, but if most of us who know how to code could contribute just a tiny bit, this driver would be the best in no time. So many of us use Mesa, imagine for a moment if say a thousand users, professional coders or students, would contribute an hour of their time daily to this project. In a few months, it would become much better. It is not hard, it is just that most of us are lazy bastards.

                  So quit bashing and start contributing, anything. Contribute code, contribute testing feedback, contribute documentation, anything. Just help make Linux better!
                  Very well put and even inspiring!

                  I pretty much stopped playing games a few years ago.
                  Nowadays I only need Armagetron Advanced!

                  Fact is if I get hardware video acceleration and working dynpm I will be happy and probably will care even less for GL 3+...

                  Comment


                  • #39
                    Originally posted by RealNC View Post
                    That's pretty much a thing of the past now. Windows grew up and became a real OS. It even allows for restarting or replacing drivers, including GPU ones, while the GUI is running without a restart or logout/login.
                    Can you please show me some proof of it? Video would be good. Should not necessary be AMD->Nvidia, but normal driver upgrade (ie catalyst 10.1->10.2 without reboot and without GDI shutdown).
                    That reminds me of Ksplice.

                    Originally posted by RealNC View Post
                    The effort (in other words, cost) required to write a binary driver for Linux is higher compared to systems that use a driver ABI. So some vendors won't bother writing one. The quality of the binary drivers of vendors who actually write binary Linux drivers would probably increase if they were offered an ABI.

                    Lower cost to support a platform means more support for that platform. You cannot really force vendors to offer source code and docs with Linux, because in order to do so you must be a force to be reckoned with. If sales of vendors are 95% Windows+Mac, then the rest can be ignored.
                    I dont see one thing: How swaping API for ABI is going to make things easier. In first case it is a binary interface, with some bits swaping from time to time according to specs. In the second case, you have funtions swaping from time to time according to changelogs.

                    In my optinion working with IDE and letting code compile is way easier than using assembler and binary alphabet. I mean, unless you're not human, words should do more sense than 1s and 0s.

                    And then, it still stays the code. The difference is either the code is closed (ABI) or not (API), and hence my previous post makes sense. Just look at FGLRX back some years - huge code mess and disorientation, as mentioned by AMD crew. Its better to have opensource, clean, documented code than binary mess by some guy from China(US, Korea, Russia etc) village. I think this is the reason linux is so stable to the point.

                    And I have own special policy with vendors ignoring linux. They ignore linux, I ignore them.

                    Its either you eat SLUM(tm) from crappy pandora box without even ingredients specified and have tons of it, or know exactly what you are eating, even if it is scarcer and not every one agree to sell you this good food.

                    Well, Im care for (linux) health more than for pops.

                    Comment


                    • #40
                      Originally posted by RealNC View Post
                      FreeBSD is something no one uses. Linux at least has its 2 or 3% market share. FreeBSD is like sub-zero market share. Vendors aren't interested at all.

                      So how does that make my argument bogus?
                      Im not offending or flaming you, RealNC. Everyone should have his own opinion, I just express my own.

                      Ladies and gentleman - THE BSD!

                      Comment


                      • #41
                        Originally posted by crazycheese View Post
                        Can you please show me some proof of it? Video would be good. Should not necessary be AMD->Nvidia, but normal driver upgrade (ie catalyst 10.1->10.2 without reboot and without GDI shutdown).
                        It's documented fact. Why is it someone else's burden to produce a video because you're too lazy to hit Google and spend a few minutes reading on WDDM?

                        That reminds me of Ksplice.
                        Ksplice is a crazy-ass insane technique for replacing running kernel code in a _monolithic_ kernel. The NT kernel system is a (hybrid) microkernel, and the video driver subsystem makes full use of that fact.

                        Windows applications are also written a bit differently than Linux ones, which helps out. Windows apps can lose their graphics context at any time and are expected to deal with this fact. Linux apps do not, because the current X protocol does not separate window and event management from rendering context management particularly well.

                        In my optinion working with IDE and letting code compile is way easier than using assembler and binary alphabet. I mean, unless you're not human, words should do more sense than 1s and 0s.
                        ABIs are directly derived from the APIs. They go hand in hand. If you have a stable API, you get a stable ABI almost for free. Many Open Source projects do this already, including Linux for its userspace API, as well as glibc, GTK+, Mesa, and most other libraries.

                        The problem is that the Linux driver interface doesn't even have a stable API. If you want to get a new piece of hardware to work, you have to upgrade EVERYTHING. Often by hand.

                        Why the hell should people be expected to piss away their time working around a broken-by-design driver interface instead of doing something useful, or fun, or useful AND fun?

                        Comment


                        • #42
                          Originally posted by crazycheese
                          Can you please show me some proof of it? Video would be good. Should not necessary be AMD->Nvidia, but normal driver upgrade (ie catalyst 10.1->10.2 without reboot and without GDI shutdown).
                          It is true. Starting with Vista GPU driver updates no longer require a restart (the screen blanks out for a few milliseconds, the new kernel module is inserted, driver installation complete).

                          Starting with Win7, you can even hotplug the GPUs themselves while the system is running (I hope noone is crazy enough to try this, though. Fire hazard and all that). The WDDM v1.1 also supports heterogenous hardware and can switch drivers on the fly (Intel & Nvidia and Ati & Ati are the most common combos).

                          This is nigh impossible to emulate on the current Linux DRI stack but it is said that Wayland might provide a solution. It's very very likely that this will come to the OSS drivers first, before the blobs support it (if ever).

                          Comment


                          • #43
                            Originally posted by elanthis View Post
                            Many Open Source projects do this already, including Linux for its userspace API, as well as glibc, GTK+, Mesa, and most other libraries.
                            In other words, APIs that external apps are supposed to use. Unlike an internal kernel API that no one should really be interfacing with at all.

                            The problem is that the Linux driver interface doesn't even have a stable API.
                            And why should it? What's the benefit? The benefit's of not having one are very clear to everyone involved, so what is worth giving that up? Clearly the benefits can't be that great or BSD would have taken off and left Linux behind - or someone would have forked linux to keep a stable API around, and that would have taken off. This wouldn't be that difficult to do - the fact that it hasn't should tell you something, and it's not that you just happen to be smarter than everyone who is involved with creating linux.

                            Comment


                            • #44
                              Originally posted by BlackStar View Post
                              It is true. Starting with Vista GPU driver updates no longer require a restart (the screen blanks out for a few milliseconds, the new kernel module is inserted, driver installation complete).

                              Starting with Win7, you can even hotplug the GPUs themselves while the system is running (I hope noone is crazy enough to try this, though. Fire hazard and all that). The WDDM v1.1 also supports heterogenous hardware and can switch drivers on the fly (Intel & Nvidia and Ati & Ati are the most common combos).

                              This is nigh impossible to emulate on the current Linux DRI stack but it is said that Wayland might provide a solution. It's very very likely that this will come to the OSS drivers first, before the blobs support it (if ever).
                              Thanks for the answer! I think it should be easy to implement with Gallium, KMS and udev. Detect gpu change via udev, set output to null, shutdown the driver, wait for new hw. Im not kernel hacker, but I think the technology is present. There is hotswap cpu and memory ability, whats the problem.

                              See:
                              http://en.wikipedia.org/wiki/Windows...y_Driver_Model
                              "If a WDDM driver hangs or encounters a fault(kernel watchdog, pinging grapic stack), the graphics stack will restart the driver(sending Xorg a message to switch output to null, force rmmod & modprobe, send Xorg a message again to switch).[1] A graphics hardware fault will be intercepted and if necessary the driver will be reset.

                              Drivers under Windows XP were free to deal with hardware faults as they saw fit either by reporting it to the user or by attempting to recover silently. With a WDDM driver, all hardware faults cause the driver to be reset and the user will be notified by a popup(libnotify lol); this unifies the behavior across vendors.

                              Previous drivers were fully implemented in kernel mode, whereas WDDM is implemented partly in user mode. If the user mode area fails with an unrecoverable error, it will, at the most, cause the application to quit unexpectedly instead of producing a blue screen error as it would in previous driver models.

                              WDDM also allows the graphic hardware to be reset or unplugged without a proper reboot. In practice, a driver update should not necessitate a reboot."
                              From what I see vital part of gfx stack is still running in 0 ring, hardfreezes very possible.


                              Wayland is just a FB, personally I care about X12 more than about Wayland because to me, its just making a bicycle from scratch because automobile engine is not sometimes required. I think Wayland is designed for low capable hw, like consoles or pdas, not for desktop where additional functionality using a bit of resources is a problem.

                              Originally posted by elanthis View Post
                              It's documented fact. Why is it someone else's burden to produce a video because you're too lazy to hit Google and spend a few minutes reading on WDDM?
                              I cannot find it thats why I'm asking. You told me something new, Im asking for confirmation, you fail to deliver it. It is my fault? I cannot find a video of successful driver update till this point.

                              Originally posted by elanthis View Post
                              Ksplice is a crazy-ass insane technique for replacing running kernel code in a _monolithic_ kernel. The NT kernel system is a (hybrid) microkernel, and the video driver subsystem makes full use of that fact.
                              Linux is as monolithic, as NT is micro. They are both hybrid to large degree.

                              Originally posted by elanthis View Post
                              Windows applications are also written a bit differently than Linux ones, which helps out. Windows apps can lose their graphics context at any time and are expected to deal with this fact. Linux apps do not, because the current X protocol does not separate window and event management from rendering context management particularly well.
                              I have seriously much much more positive experience switching to tty and back on linux than alt-tabing in windows, especially under heavy system load, not mentioning crashes where reboot was the only option. I think the only problem(bug) in X is managing fullscreen apps efficiently. I.e. something in fullscreen hangs, cannot alt-tab, user has to switch to tty and kill the app. Which at least works 99,9% of time, where in windows it is 50/50 bet.

                              Originally posted by elanthis View Post
                              ABIs are directly derived from the APIs. They go hand in hand. If you have a stable API, you get a stable ABI almost for free. Many Open Source projects do this already, including Linux for its userspace API, as well as glibc, GTK+, Mesa, and most other libraries.
                              They go hand in hand only if the developer designs it so or if compiler/linker is very conservative. Glibc update is almost never easy on gentoo. "If you stable API" thing will introduce DLL hell(.o'hell). Other method is pinning and mapping new to old, which is an overhead. So the "best" method is some kind of "standard ABI" which will spawn in multitude of binaries, extra mess, several drivers going closed-source.

                              It seem that make is able to determine itself what part of kernel should be recompiled, which means it is not a problem to make a binary package provided the package manager supports it; which again means binary-based distros are perfectly capable to provide multi-version driver packages for same kernel, they should just package it.

                              Comment


                              • #45
                                heh, i have ssh server installed on my Windows™ 7 just for sole purpose of killing stupid apps which messed up screen and blocked switching. i sshing on it from nearby laptop with Gentoo to clean this shit up. it GUI issue however and not driver one (if you not count that almost all GUI stuff is build in kernel which makes it "a driver" of its own).

                                with all the crashes, freezes, resets on false lockup detection, inability to make use of new "clean" API, and wide usage of DX9 D3D variants with incompatible ABI (hello, d3d9_*.dlls) you should be out of your fucking mind to suggest that it's done better in Windows™ and it's good example for imitation. those people really should make better use of their time and port ttm/kms on *BSD.

                                Comment

                                Working...
                                X