Announcement

Collapse
No announcement yet.

NVIDIA Delivers Beta OpenGL 3.0 Linux Driver

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

  • #21
    Originally posted by thacrazze View Post
    Catalyst 8.10 supports already a lot of parts of OpenGL 3.0.
    Without GLX_ARB_create_context, there is no OpenGL 3, at all. Saying that they have support for parts of GL 3 because they have some extensions that 3.0 has in core isn't a fair comparison, otherwise I can say nVidia's had parts of GL 3 for years, because they supported GL_ARB_texture_float (made core in GL3).

    Comment


    • #22
      Originally posted by 3vi1 View Post
      Ubuntu Intrepid, and other distros, use DKMS to achieve this effect with the current nVidia drivers.
      And that's wonderful, but it's a patch over the real problem, which is a stable kernel module API, or some kind of stable API somewhere to allow a driver to be installed on a system easily. You can have a stable API and still have feature improvement via forwards compatibility, and even if you switch APIs or have an unstable API, at least make it so all the APIs can be easily installed and used so that users with older drivers won't be left in the dark.

      Users don't want to wait around for a driver or some headers to recompile itself whenever they want to use it, nor should they have to and wouldn't if more planning went into the architecture of the system. It looks like they tried to with kernel modules and there are these PPD driver files for printers, but even those aren't using a standard it seems and need recompilation for use on whatever CUPS version is installed.

      Any way, it can be a pain, so I hope smarter ways of doing things take hold.

      Comment


      • #23
        Originally posted by Yfrwlf View Post
        And that's wonderful, but it's a patch over the real problem, which is a stable kernel module API, or some kind of stable API somewhere to allow a driver to be installed on a system easily. You can have a stable API and still have feature improvement via forwards compatibility, and even if you switch APIs or have an unstable API, at least make it so all the APIs can be easily installed and used so that users with older drivers won't be left in the dark.

        Users don't want to wait around for a driver or some headers to recompile itself whenever they want to use it, nor should they have to and wouldn't if more planning went into the architecture of the system. It looks like they tried to with kernel modules and there are these PPD driver files for printers, but even those aren't using a standard it seems and need recompilation for use on whatever CUPS version is installed.

        Any way, it can be a pain, so I hope smarter ways of doing things take hold.
        You might end up waiting a long time. Linux never has and never will have an internal stable abi or api. Much of the problems are reduced when the drivers are in the kernel tree (which is what the devs encourage). if you're interested about the reasons for this you can read here:
        http://www.mjmwired.net/kernel/Docum...i_nonsense.txt

        Comment


        • #24
          Originally posted by _txf_ View Post
          You might end up waiting a long time. Linux never has and never will have an internal stable abi or api. Much of the problems are reduced when the drivers are in the kernel tree (which is what the devs encourage). if you're interested about the reasons for this you can read here:
          http://www.mjmwired.net/kernel/Docum...i_nonsense.txt
          Yep thanks and I read it, and that's a really POS article. Any article that starts out with "you don't need to worry about it" and "only weirdos want to make kernel drivers any way" is stupid. There's no reason for not having stability in the inter-kernel API/ABI, it's entirely possible. It's stable between the kernel and programs, and it can be stable between drivers and the kernel too. Having a stable API does not mean not being able to improve the kernel and all it requires is documentation and communication. The reason they push for it is because they want all drivers to be open source and to be able to control them, so they want to give any drivers outside of the kernel a hard time. Also by screwing over everyone else repeatedly they can stay in control and have everyone dependent on them. Well, guess what, you just ended up giving Linux users a hard time instead, because now they don't have the freedom to install any standalone driver on any kernel without being required to know how to compile. Thanks a lot. I hope someone makes a kernel module which allows kernel modules to be attached to *it* instead, then it will add on a stable API, and we can have true modularity.

          Comment

          Working...
          X