Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 51

Thread: An Update On The OpenGL 3 Support In Mesa

  1. #11
    Join Date
    May 2007
    Posts
    231

    Default

    Quote Originally Posted by RealNC View Post
    This was in response to various people claiming that the Linux driver model of requiring hardware vendors to open source their drivers and put them in the kernel is a good idea. When vendors don't do that, the next claim is that it's enough for them to open up their docs so that "the community will code the drivers and features."

    It doesn't look that way. Proprietary drivers support GL3 for ages now, while the open driver stack is still based on old, outdated specs. IMO this is proof enough that the Linux driver model is wrong and its supporters too. Otherwise the open graphics stack would have been feature complete years ago.
    I think it has more to do with the number of people and the size of graphic driver which are the biggest driver in the kernel (and not everythings is in the kernel). To me it's more like opensource is around 30 peoples accross all hw & core mesa while each closed source driver are likely done by way more than 300 people working full time.

    By the way the closed source driver on linux use the linux driver model (or maybe i am missing what you mean by the driver model).

  2. #12
    Join Date
    Jan 2009
    Posts
    621

    Default

    Note that even though you might not be able to see GL3/4 support due to some patent issues anytime soon, we will support (almost) all the functionality through extensions. Currently with a GL2.1 driver from Mesa, you already get nearly half the GL3.x features via extensions and you may start using them now if your driver supports them. Here's what's done:
    http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

  3. #13
    Join Date
    Dec 2007
    Posts
    2,360

    Default

    The hw documentation (at least from AMD) has everything you'd need for implementing the latest GL features. OpenGL is a huge API and it takes a lot of effort just to implement the infrastructure required to add driver support. As Jerome noted, it's an issue of man power, not lack of specs or bad design. The closed drivers have several hundred developers working on them, the open drivers have just a handful.

    It would have been nice if GL4 had dropped all the old fixed function stuff, but it didn't. It's a lot easier to implement a relatively legacy-free API like DX10/11 than GL3/4 and all it's legacy baggage.

  4. #14
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    By driver model I mean a driver ABI. Driver ABIs exist on all major operating systems, except Linux.

    Let me clarify, because I'm not a hater:

    Some people claim that all software should be Free and Open Source. Proprietary software should be banned from Linux. And proprietary drivers are "evil." Since they're evil, Linux should not provide a driver ABI (and it doesn't) and all drivers should be put into the kernel, without exception.

    What is a driver ABI? It's an interface that allows for writing binary drivers that work across kernel versions (like you can do on Windows, OS X, Solaris, and many others systems.) Linux lacks such an ABI, so vendors are forced to update their drivers on every kernel release and use internal kernel APIs that are not stable (= change between kernel versions.) Also, they are unable to interface properly with the kernel (DRM, KMS, whatever).

    According to those people, this is a good situation since those drivers are evil and Linux not providing a driver ABI means those driver will stay problematic and therefore will force the vendors to open source their drivers.

    And here comes the catch: the vendors don't open source their drivers. AMD didn't (fglrx is still closed), and neither did NVidia, and neither did Intel.

    So those people go on and claim that it's not really important for the vendors to open source their drivers, since "the community" will write their own drivers if they have the docs. Well, now they have the docs, but "the community" still lags behind. And the user is the one who suffers (can't have GL3, can't play games at native speed, etc, etc.) The proprietary drivers have blindingly fast 3D, support for latest GL versions, etc. The free drivers don't. So obviously the argument that "the community" can write drivers that are on-par with the closed ones didn't work out.

    I maintain the position that it's not important for the drivers to be free. It's important that they work. But they can't work unless the OS itself is friendly to binary drivers (Windows, OS X, etc), which Linux isn't. And it isn't because people claim that drivers should be open.

    It's just brain damage if you ask me. Give hardware vendors a proper interface to write their drivers and Linux will get a huge boost. Why should I use Mesa if both AMD and NVidia have good GL implementations tweaked for their hardware? Why should I use the open drivers if the binary blobs would work just as well? Why should I update my kernel just to get a new version of the driver? I should only need to download the driver and install it, not replace the whole bloody kernel. People have problems with their hardware on Linux more often than not. A driver ABI would make everyone happy.

  5. #15
    Join Date
    May 2007
    Posts
    231

    Default

    Quote Originally Posted by RealNC View Post
    By driver model I mean a driver ABI. Driver ABIs exist on all major operating systems, except Linux.

    [...]

    A driver ABI would make everyone happy.
    Stable ABI would only have solve your own use case where you want to use lastest bleeding edge kernel with closed source driver, i can understand that.

    But i think you are omitting the good of no stable ABI, the ability to fix the API kernel provide to driver, the ability to hugely modify and improve crucial part of the kernel without having to worry about ABI.

    And no we don't leave in fantasy world where everythings is in its own little isolated world, driver for GPU for instance heavily rely on the memory management of the kernel and linux kernel has seens major change to that. Others have made a far better point than me on why stable ABI is non sense.

    Also note that windows stable ABI seems to be a myth. I am pretty sure driver ABI severly evolved btw W95, XP, Vista, Win7. I am not an expert on windows side but to me it seems that a lot of hw stop working from one version to the other and need a new driver (something that happen only if the manufacturer feels the need for a new driver). DX also change the API at every major release. I guess most of this is hidden to end user so no one really notice it, you just endup with a tons of dll each supporting old old ABI.

    In the end i think no stable ABI also push hw manufacturer to consider an open source driver that can live upstream where it will get all the attention needed. So i think it has done more good and likely is one of the reasons why Linux is much better these days (this is my own personal feeling).

  6. #16
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    Quote Originally Posted by glisse View Post
    Stable ABI would only have solve your own use case where you want to use lastest bleeding edge kernel with closed source driver, i can understand that.
    It's not my own use case. It's the use case of millions of people. Also, closed source drivers suck partly because there's no good ABI.

    And don't forget that the radeon drm needed to be pushed into the kernel because there's no ABI. If you think logically about it, why put drivers into the kernel in the first place? Why not just download the latest radeon driver from x.org and install it, regardless of what version of the Linux kernel I'm using? Why should I update all the drivers in my system by doing a kernel update just to get a new radeon driver? If I download just the radeon driver, at most my graphics will break. If I update all drivers at once, a lot of stuff can break.

    If I just need to update my graphics driver, then I should be able to just update that, and only that. I don't see graphics drivers being bundled with my wi-fi drivers and filesystem drivers on other OSes....

    But i think you are omitting the good of no stable ABI, the ability to fix the API kernel provide to driver, the ability to hugely modify and improve crucial part of the kernel without having to worry about ABI.
    Other OSes seem to get by just fine. It seems Linux kernel hackers have nothing better to do than break APIs all day long for no good reason. It's insane.

    And no we don't leave in fantasy world where everythings is in its own little isolated world, driver for GPU for instance heavily rely on the memory management of the kernel and linux kernel has seens major change to that.
    Binary drivers have their own memory manager.

    Others have made a far better point than me on why stable ABI is non sense.
    How can you say it's nonsense if you can take a look at the situation and see how much breakage there is? Linux doesn't really work because of that. The only thing that somewhat works is NVidia's blob, and it would work really great if there was an appropriate ABI.

    Also note that windows stable ABI seems to be a myth. I am pretty sure driver ABI severly evolved btw W95, XP, Vista, Win7.
    Those are different operating systems and therefore have their own ABIs. The ABI in Windows 7 will stay as-is until Windows 8 comes around 4 years later. In Linux stuff breaks every other day.

    DX also change the API at every major release. I guess most of this is hidden to end user so no one really notice it, you just endup with a tons of dll each supporting old old ABI.
    DX major releases are far apart (years.) This is acceptable.

    In the end i think no stable ABI also push hw manufacturer to consider an open source driver that can live upstream where it will get all the attention needed.
    Which doesn't happen. Neither AMD, nor NVidia, nor Intel open sourced their drivers. And they probably never will.

    A stable ABI (at least stable for a few years) would be an inconvenience for kernel and X.Org devs, but a convenience for users and hardware vendors.

  7. #17
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    Quote Originally Posted by RealNC View Post
    A stable ABI (at least stable for a few years) would be an inconvenience for kernel and X.Org devs, but a convenience for users and hardware vendors.
    Which btw is needed for an operating system to succeed outside computer geek circles. You buy a new piece of hardware, there should be a CD in there with installable drivers. Yeah, good luck with that one on Linux. Tell the non-geek user to go hunt for a new kernel, breaking his system in the process.

  8. #18
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by RealNC View Post
    Which btw is needed for an operating system to succeed outside computer geek circles. You buy a new piece of hardware, there should be a CD in there with installable drivers. Yeah, good luck with that one on Linux. Tell the non-geek user to go hunt for a new kernel, breaking his system in the process.
    Your should really go ask Linus himself what he thinks on binary drivers and binary ABI.

    In short - IMHO - this is why linux is opensource. Kernel changes and so should anything of any importance that is within kernel space. Driver com protocol may be kind of help for driver developers, but if its not implemented yet, its not needed. Binary is crap for many many many reasons and only good for one reason - to work on specific system, at specific time, on specific software version and with support from only one specific vendor.

    To me, whole GPL model is not about "lunatism" or "communism". Its about information and matter having different natures. Information multiplies with every usage, where matter depletes; information vanishes with no one using it, where matter preserves. In GPL world programmers are paid for tasks done, not for package-ready end-result. Proprietary will never succeed, because software is always a process, not product. Your are not paying for box, you are paying for features to be implemented, features that YOU want and the result is open to be used and build-upon by everyone, for free. No bicycle re-invention, no stealing, no stupid patents. And you can pay with money, time or even appreciation.

    The thing that I dont understand, nor like is that AMD, till this time, did not allow me to register my card as being used with opensource linux drivers and so helping them identify and manage their driver team efforts. If Im buying AMD hardware, I really want for some of my money to go into xf-video-ati, mesa and dri development. NOT in some windows drivers that I dont use. Look at percentage of AMD-card owners that use opensource drivers, its HUGE.

  9. #19
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by RealNC View Post
    The only thing that somewhat works is NVidia's blob, and it would work really great if there was an appropriate ABI.
    I think the only realistic thing that would happen is most of drivers start releasing as blobs. Stability wont improve, see windows bluescreens. Hardware support will heavily decrease and no one will be able to make it work for unsupported kernel versions(just as with nvidia, esp. see nvidia optimus zero linux support). Aaand because of still-low linux desktop presence, barely ANY hardware vendor will join.

    With non-supported kodak printer, the end argumentation was like - we invested much in windows and linux does not have this, and we feel like zero to improve it to our taste, so no support. Still they managed to release Mac driver. Which means they simply lie and simply dont care, regardless how open or closed the state is.

    And if I read correctly, most of time when a blob got reverse-engineered, hackers discovered it being released as a blob for only one reason - very stupid implementation.

  10. #20
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by RealNC View Post
    It's not my own use case. It's the use case of millions of people. Also, closed source drivers suck partly because there's no good ABI.

    And don't forget that the radeon drm needed to be pushed into the kernel because there's no ABI. If you think logically about it, why put drivers into the kernel in the first place? Why not just download the latest radeon driver from x.org and install it, regardless of what version of the Linux kernel I'm using? Why should I update all the drivers in my system by doing a kernel update just to get a new radeon driver? If I download just the radeon driver, at most my graphics will break. If I update all drivers at once, a lot of stuff can break.

    If I just need to update my graphics driver, then I should be able to just update that, and only that. I don't see graphics drivers being bundled with my wi-fi drivers and filesystem drivers on other OSes....


    Other OSes seem to get by just fine. It seems Linux kernel hackers have nothing better to do than break APIs all day long for no good reason. It's insane.
    Well, from my experience nvidia blob on linux is on par to its windows version. So, as I see it, no, drivers don't suck because of semi-absent ABI. They suck for the lack of developers attention.

    The drivers in/out of kernel thing has something to do with "Tanenbaum vs Linus" aka "microkernel vs monolithic kernel" case. Linus argumentation was that drivers are very close in kernel anyway, so separate bus will only make things slower and unnecessary complex. Besides, look at NT4.0 performance; they moved the gfx driver part in-kernel since 5.0 and voila its quasi-monolithic again.


    ... And I dont see lastest nvidia drivers being available to pre-XP. You will have to backport them. Wait, you can't, its blob. Even if you have money or can code.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •