Announcement

Collapse
No announcement yet.

Radeon OpenGL 2.0 support

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

  • #46
    Originally posted by Almindor View Post
    I know you dropped both windows and linux at 8.3. But if Windows service pack/vista/whatever caused the driver to stop working due to update you'd make a new one for the older cards (same features, just sort of recompiled). This didn't happen with the newer X (AFAIK it was only Xorg which caused problems?). That was my argument.
    Both the kernel and newer xservers can be problematic for the proprietary driver since the graphics stack touches both. On the windows side the interfaces stay stable even with service packs.

    Comment


    • #47
      Originally posted by Almindor View Post
      I know you dropped both windows and linux at 8.3. But if Windows service pack/vista/whatever caused the driver to stop working due to update you'd make a new one for the older cards (same features, just sort of recompiled). This didn't happen with the newer X (AFAIK it was only Xorg which caused problems?). That was my argument.
      I doubt that's even really possible for Windows. Windows graphics drivers get written against graphics API's that stay constant for usually more than one whole operating system version. Service packs should not be possible to break anything. I think they're currently going with http://en.wikipedia.org/wiki/Windows...y_Driver_Model

      Comment


      • #48
        Originally posted by bridgman View Post
        A number of OS functions (memory management is a good example) need to be implemented differently for graphics in order to provide optimal performance. As a result the graphics driver stack ends up having to re-implement some of the upper level OS functions and hook into the OS at a lower level than most other drivers.
        And couldn't you have some sort of open-sourced wrapper making the junction between the non-stable internal API and your closed-source driver, allowing developers to maintain this wrapper for older drivers/newer kernels ?

        Comment


        • #49
          We already have that -- it's called the Kernel Compatibility Layer -- but it is not always sufficient to cope with big chunks of functionality being marked off-limits to binary drivers.

          We would need to make the entire kernel driver open source, and that would mean that we could no longer share code with the drivers for other OSes (which is the big advantage of a proprietary driver in the first place).

          This is one of the reasons we think switching to the open source drivers for older GPUs makes sense.
          Last edited by bridgman; 10-13-2009, 04:55 PM.

          Comment


          • #50
            We would need to make the entire kernel driver open source, and that would mean that we could no longer share code with the drivers for other OSes
            Why ? The code used within other OSes drivers cannot be open-sourced ?
            Is it using some patented features, or things like that ?

            Comment


            • #51
              Mostly DRM - the bane of my existence

              All of the other OSes require robust Digital Rights Management implementations, and that requires DRM support all through the driver stack. In principle open source and DRM are not mutually exclusive, but today they are.

              Comment


              • #52
                I can't imagine any way that the DVD or Blu-Ray DRM requirements can be compatible with open source. How on earth is an open source stack supposed to "robustly" implement things like region codes or the Image Constraint Token, if a user can simply compile out these antifeatures?

                Comment


                • #53
                  Originally posted by Alex W. Jackson View Post
                  I can't imagine any way that the DVD or Blu-Ray DRM requirements can be compatible with open source. How on earth is an open source stack supposed to "robustly" implement things like region codes or the Image Constraint Token, if a user can simply compile out these antifeatures?
                  Well, for the region codes for example, you simply force the hardware to be placed in a region before it will function properly. And then you limit the number of times the region can be changed, so that the software can't just change it to whatever is being played.

                  So that kind of DRM can work with OSS, but only by moving all the secure stuff out of the software and into the hardware.

                  Comment


                  • #54
                    Originally posted by Alex W. Jackson View Post
                    I can't imagine any way that the DVD or Blu-Ray DRM requirements can be compatible with open source. How on earth is an open source stack supposed to "robustly" implement things like region codes or the Image Constraint Token, if a user can simply compile out these antifeatures?
                    I'm about the furthest thing from a crypto expert, but the quick answer is that you need *something* that can't be edited, it just doesn't have to be in the driver stack -- usually either firmware in the BD drive or a certified & digitally signed binary player app.

                    The lower levels of the stack still need to be certified by a third party at a binary level, and the "secure" player/firmware cryptographically validates that it is talking to a certified driver stack -- the "open source" part of it is that the source code for the driver stack can be made visible without weakening the robustness of the implementation.

                    All the papers I have seen over the years go as far as demonstrating the principle but I haven't seen any real world implementations yet.

                    The chicken-and-egg question is whether Linux's market share can grow enough to justify a separate, DRM-free proprietary driver (which then could be at least partially open sourced) without having to offer certified playback of protected content to obtain that market share (which would require DRM anyways).

                    Comment


                    • #55
                      Originally posted by bridgman View Post
                      The lower levels of the stack still need to be certified by a third party at a binary level, and the "secure" player/firmware cryptographically validates that it is talking to a certified driver stack -- the "open source" part of it is that the source code for the driver stack can be made visible without weakening the robustness of the implementation.
                      What you're describing isn't open source. It may be "shared source" or whatever Microsoft's bullshit marketing phrase is, but if you can't modify and recompile and have it still work, then it isn't open source.

                      DRM regimes that mandate antifeatures in software are, by nature, directly antithetical to open source.
                      Last edited by Alex W. Jackson; 10-14-2009, 01:09 AM.

                      Comment


                      • #56
                        I deliberately used "open source" rather than "free". DRM regimes that mandate antifeatures in software are, by nature, directly antithetical to free software. The term "open source" is more flexible. The generally accepted definition for "open source" is the OSI's Open Source Definition, which does not appear to prohibit an external certification mechanism granting additional rights to users of certified binaries. It's possible that GPLv2 could allow it as well, although GPLv3 tries hard to prevent any kind of DRM.

                        That said, we are not talking about the ability to recompile the full DRM-enabled driver anyways. The DRM-enabled driver would be for "one of those other OSes". We are talking about the ability to expose the portions of the shared code which are used by the Linux driver, where DRM is *not* implemented.

                        You could recompile the *Linux* driver and have it work, you just couldn't recompile the driver for the *other* OS and have it work -- but you wouldn't have full source code for that driver anyways, just for the portion which was shared with Linux.

                        The goal of the "open source DRM implementation" (if it ever turned out to be possible) would be to let us share code between drivers for Linux and for DRM-enabled OSes as we do today, but also to let us provide source code for the complete Linux kernel driver without putting our DRM implementation on other OSes at risk.

                        Anyways, this is all hypothetical and I haven't heard of any recent progress in that area; I just mentioned the possiblity for completeness and to avoid all the "open source DRM is possible, see xxx research paper" flames I usually get when discussing DRM on a public forum
                        Last edited by bridgman; 10-14-2009, 01:56 AM.

                        Comment


                        • #57
                          Originally posted by bridgman View Post
                          The generally accepted definition is the OSI's Open Source Definition, which does not appear to prohibit an external certification mechanism granting additional rights to users of certified binaries. It's possible that GPLv2 could allow it as well, although GPLv3 tries hard to prevent any kind of DRM.
                          It'd be more precise to say that the GPLv3 tries its best to prohibit "granting additional rights to users of certified binaries". I like that phrasing.

                          Originally posted by bridgman
                          You could recompile the *Linux* driver and have it work, you just couldn't recompile the driver for the *other* OS and have it work -- but you wouldn't have full source code for that driver anyways, just for the portion which was shared with Linux.

                          The goal of the "open source DRM implementation" (if it ever turned out to be possible) would be to let us share code between drivers for Linux and for DRM-enabled OSes as we do today, but also to let us provide source code for the complete Linux kernel driver without putting our DRM implementation on other OSes at risk.
                          If that's the case, then why do you keep bringing up the idea of "authorized" Linux BD playback in this and other threads? As you admit, that would require "tivoization" of, at a minimum, the player application, the entire driver stack, and probably the entire Linux kernel. At that point you might as well just be running OS X.

                          Comment


                          • #58
                            Originally posted by Alex W. Jackson View Post
                            If that's the case, then why do you keep bringing up the idea of "authorized" Linux BD playback in this and other threads?
                            I didn't, other than to the extent it was part of the answer to questions I was being asked. The problem is that the answer to most of the simple "why don't you do XYZ" questions is "DRM", and the answer to the follow-on questions usually touches on an OEM-friendly BD playback solution in one way or another.

                            I was asked why we couldn't open up source code of drivers for other OSes. My response was :

                            Mostly DRM - the bane of my existence. All of the other OSes require robust Digital Rights Management implementations, and that requires DRM support all through the driver stack. In principle open source and DRM are not mutually exclusive, but today they are.
                            You then challenged the statement about DRM and open source not being mutually exclusive in principle, and i gave you a summary of how it might work in principle. That left a number of possible approaches floating open, and I tried to resolve them all as a set :

                            - if we were to open source the Linux kernel driver while sharing code(the original question), the other option would be to write a completely different kernel driver for Linux, but with the current market share and lack of OEM preload business that isn't really viable.

                            - a significant increase in consumer PC Linux market share could justify writing a DRM-free open source kernel driver for fglrx, but most of the customer feedback we get ties significant Linux market share growth to availability of a "legal for OEM sale" BD playback system, which would mean that writing a separate DRM-free kernel driver wouldn't make sense even if the Linux market share *did* grow.

                            - the only scenario that could justify a fully open source kernel driver for fglrx is a significant (say 4-fold) consumer PC market share increase *without* BD or other protected content playback, which most market feedback says is unlikely.

                            The combination of these points covers the major options for providing a fully open kernel driver in the current market -- which was the "original original" question. Only one scenario works - significant consumer PC market share growth for Linux without requiring OEM-friendly BD playback.

                            It's all connected
                            Last edited by bridgman; 10-14-2009, 02:43 AM.

                            Comment


                            • #59
                              Originally posted by agd5f View Post
                              Apps are supposed to check if the driver supports an extension before using it.
                              Great.

                              Thats exactly why "wine" doesn't support oss radeon driver anymore.

                              wined3d_guess_vendor Received unrecognized GL_VENDOR "DRI R300 Project".

                              Comment


                              • #60
                                Originally posted by Mr_Ed View Post
                                Great.

                                Thats exactly why "wine" doesn't support oss radeon driver anymore.

                                wined3d_guess_vendor Received unrecognized GL_VENDOR "DRI R300 Project".
                                You need to update mesa. Newer versions report the vendor like this:

                                OpenGL renderer string: Mesa DRI R300 (R420 5D4F) 20090101 TCL DRI2

                                Comment

                                Working...
                                X