Announcement

Collapse
No announcement yet.

The Slides Announcing The New "AMDGPU" Kernel Driver

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

  • #91
    [QUOTE=dungeon;445773]Of course that is a problem, i only imagine some bug in future where kernel allocate resource which align to fglrx, while it does not work with mesa In that situation i will patch my mesa (or other opensource graphic stack) or use blob, there will be no other solution . Sooner or later that will happen, we all know what mimikry is

    It is a problem only if we are going to write "secret" code in amdgpu that will only work with closed-source UMD.
    I don't believe that is the case and from knowing the kernel maintainers, even if we try something stupid as that, they will be on top of it quickly.

    Comment


    • #92
      Originally posted by blackiwid View Post
      yes but we dont allow nvidia to do such thing
      We don't differenciate between AMD and nvidia. Nvidia could do the same, what's allowed and what not is clearly defined:
      - Add some API to userspace for a open source driver -> allowed.
      - Use existing kernel to userspace APIs with closed source driver -> allowed.
      So as long as AMD doesn't try to get some API into the kernel to use it with the closed source driver only everything is fine. Again: Nvidia could do the same if they wished to, they would just need a open source driver first.
      Again what next could happen would be taht nvidia tells that they send patches taht vesa can use some minor features for their new kernel-backend, but also their blob use it much more, then the vesa driver could use 2-3 minor features of it, and their blob use all features of this new thing.
      Nope, the features they want to add must be used by a open source driver. Else this would be:
      - Add some API to userspace for a closed source driver -> dissallowed.
      Maybe I am wrong but this kernel part can then even use the GPL_ONLY marked functions, so the blob can use through this Proxy stuff that non-gpl software should not be able to use.
      This is also defined, too, read the kernels license. In short:
      Yes, their kernel driver will be able to use GLP_ functions (as it will be GPL, too). Yes, it will be able to translate these functions to userspace. Yes, their closed-source driver will be able to benefit from it BUT only if the open source driver benefits from it, too.
      am I really the only one that sees here a problem?
      Yes, as you don't seem to understand the kernels license / code accepting requirements.

      Also see the pros of it: If they want a new feature in the closed-source driver that needs a modification of the kernel part they have to implement it in the open-source driver, too.

      Comment


      • #93
        Originally posted by odedgabbay View Post
        It is a problem only if we are going to write "secret" code in amdgpu that will only work with closed-source UMD.
        I don't believe that is the case and from knowing the kernel maintainers, even if we try something stupid as that, they will be on top of it quickly.
        That is the point - "quickly" cames from relative words category, so it can easely mean also - nearly never .

        There is no secret, this is how things will be . Well you will see, there are always bugs in userspace (different for both, with no easy workaround) and AMD will also wants blob to be best served of course , so default will be blob preferably and in the end most users who does not care is it opensource or not will start to use that
        Last edited by dungeon; 12 October 2014, 07:32 AM.

        Comment


        • #94
          Give users Mantle addon and few games and you will see who cares about opensource one .

          Comment


          • #95
            Originally posted by dungeon View Post
            That is the point - "quickly" cames from relative words category, so it can easely mean also - nearly never .

            There is no secret, this is how things will be . Well you will see, there are always bugs in userspace (different for both, with no easy workaround) and AMD will also wants blob to be best served of course , so default will be blob preferably and in the end most users who does not care is it opensource or not will start to use that


            What the hell is wrong with people like you? No seriously... AMD is becoming more open with their driver and all you can think about is some conspiracy for how they're subverting their open source driver which was mostly developed by themselves.

            What this all really means is that the opensource KMS driver for AMD Cards is now good enough that AMD feels comfortable with dropping the proprietary linux kernel driver and shifting all resources previously allocated to that over to the open source one. They cannot currently drop the userspace driver in favour of the open source one, but I have no doubt at all that once the open source userspace driver is good enough that catalyst on linux is going bye-bye. I wouldn't be surprised to learn at that point that Catalyst's OpenGL parts would be ripped out and completely replaced with Mesa at that point for Windows because there's no point in AMD maintaining 2 OpenGL stacks, it just makes business sense.

            Comment


            • #96
              Originally posted by Luke_Wolf View Post


              What the hell is wrong with people like you? No seriously... AMD is becoming more open with their driver and all you can think about is some conspiracy for how they're subverting their open source driver which was mostly developed by themselves.

              What this all really means is that the opensource KMS driver for AMD Cards is now good enough that AMD feels comfortable with dropping the proprietary linux kernel driver and shifting all resources previously allocated to that over to the open source one. They cannot currently drop the userspace driver in favour of the open source one, but I have no doubt at all that once the open source userspace driver is good enough that catalyst on linux is going bye-bye. I wouldn't be surprised to learn at that point that Catalyst's OpenGL parts would be ripped out and completely replaced with Mesa at that point for Windows because there's no point in AMD maintaining 2 OpenGL stacks, it just makes business sense.
              Yeah, that's exactly my thinking to. Everyone keeps asking for them to drop Catalyst entirely and focus on the open drivers, and here they are doing exactly that. (Well, starting with dropping half the driver which is good enough to be replaced, with the other half no doubt coming when it's ready). And everybody does nothing but complain.

              It's just like when they released the UVD1/2.0 support. Everybody had been complaining about that for years, and when it finally came... They still kept complaining, as if things had actually gotten worse.

              Comment


              • #97
                Originally posted by TAXI View Post
                We don't differenciate between AMD and nvidia. Nvidia could do the same, what's allowed and what not is clearly defined:
                - Add some API to userspace for a open source driver -> allowed.
                - Use existing kernel to userspace APIs with closed source driver -> allowed.
                So as long as AMD doesn't try to get some API into the kernel to use it with the closed source driver only everything is fine. Again: Nvidia could do the same if they wished to, they would just need a open source driver first.

                Nope, the features they want to add must be used by a open source driver. Else this would be:
                - Add some API to userspace for a closed source driver -> dissallowed.

                This is also defined, too, read the kernels license. In short:
                Yes, their kernel driver will be able to use GLP_ functions (as it will be GPL, too). Yes, it will be able to translate these functions to userspace. Yes, their closed-source driver will be able to benefit from it BUT only if the open source driver benefits from it, too.

                Yes, as you don't seem to understand the kernels license / code accepting requirements.

                Also see the pros of it: If they want a new feature in the closed-source driver that needs a modification of the kernel part they have to implement it in the open-source driver, too.
                The point is it's a bit of a slippery slope when the entire point of the closed user space driver is that it will be able to use the kernel driver more fully and implement more things through it than the open user space driver

                Comment


                • #98
                  Originally posted by TAXI View Post
                  Yes, as you don't seem to understand the kernels license / code accepting requirements.

                  Also see the pros of it: If they want a new feature in the closed-source driver that needs a modification of the kernel part they have to implement it in the open-source driver, too.
                  Its maybe true that I dont understand them, I said it was more a question, I am open minded on this matter. But if thats all true, were was the problem with nvidia using the bumblebee kernel parts or something, dont find the news right now to it, but there they used some gpl_only stuff and wanted taht some gpl_only markers got removed. when bumblebee was for nouvou as I understand it, is the case, why did people have a problem then, and why was there a need to remove gpl_only marker there?

                  To all of you I am a AMD Fan, but I am old enough to know that u cant fully trust a company, their goal is to maximise their profits even by law, if at one day as example a new manager think buy doing something evil they can raise their income they most likely will do so.

                  We have seen it before, as example nokia having a big team to develop a good linux phone plattform and then over night firing the whole team and use windows on their phones. So and again its not only about AMD, I just want to make shure all is right, because if maybe does in the end have really the goal to use the free drivers on linux only (at least they dont hurry there), it could make a case that a evil company like nvidia could use as argument to do really evil stuff.

                  If I am wrong here really, I have no problem with it. I just dont understand some stuff, as example opengl is something that happens with kernel parts too right? So when the blob can give us opengl 4.0 or later and the free driver not, isnt that then this, the blob at least uses this kernel parts than first? or is that completly kernel-independend stuff? Or do we get then full opengl levels from day 1 with the free driver, too?

                  Comment


                  • #99
                    Originally posted by Luke_Wolf View Post
                    What the hell is wrong with people like you? No seriously... AMD is becoming more open with their driver and all you can think about is some conspiracy for how they're subverting their open source driver which was mostly developed by themselves.

                    What this all really means is that the opensource KMS driver for AMD Cards is now good enough that AMD feels comfortable with dropping the proprietary linux kernel driver and shifting all resources previously allocated to that over to the open source one. They cannot currently drop the userspace driver in favour of the open source one, but I have no doubt at all that once the open source userspace driver is good enough that catalyst on linux is going bye-bye. I wouldn't be surprised to learn at that point that Catalyst's OpenGL parts would be ripped out and completely replaced with Mesa at that point for Windows because there's no point in AMD maintaining 2 OpenGL stacks, it just makes business sense.
                    AMD is not became more open, as Alex say nothing is changed in opensource one... so it is not at all more open, what they do and what is general idea is that they want to just unify driver offerings - both blob and opensource into one amdgpudriver. And both drivers need changes that way... what blob do here is just a drop their kernel part and starts to use newely designed which obviosly needs to be opensorce one. Both drivers needs chages for the userspace part, etc...

                    No one make flgrx (catalyst) driver stack more open!!! And again blob does not go away anywhere, it only have more bright future

                    Only thing what amdgpu driver is so special, came in hand to existing blob users who will suffer less with driver updates

                    How all this implicate to future, well i already give my opinion
                    Last edited by dungeon; 13 October 2014, 08:40 AM.

                    Comment


                    • Originally posted by dungeon View Post
                      AMD is not became more open, as Alex say nothing is changed in opensource one... so it is not at all more open
                      We can't make the open driver any more open

                      Originally posted by dungeon View Post
                      No one make flgrx (catalyst) driver stack more open!!! And again blob does not go away...
                      Today Linux Catalyst has a closed kernel driver and closed X driver but Catalyst/amdgpu will have an open kernel driver and open X driver. How is that not more open ?
                      Last edited by bridgman; 13 October 2014, 10:42 AM.
                      Test signature

                      Comment

                      Working...
                      X