Announcement

Collapse
No announcement yet.

AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

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

  • #31
    Originally posted by agd5f View Post
    There are lots of workstation customers that need high performance OpenGL 4.x and OpenCL 1.x support right now. While it would be nice to focus on a solely open source user mode drivers, it's not really feasible in the short term.
    Does this mean AMD plan a migration from Catalyst in the medium to long term if and when the FOSS drivers reach feature compatibility?

    Comment


    • #32
      Originally posted by d2kx View Post
      Personally, I think that most of Michael's concerns are not as problematic as it sounds like, and that this approach is very much doable
      Agreed. The solution they are discussing is not something that is going to drop next week. Additionally, they have already stated that they have a semi-working prototype. While there may be a LOT of pieces to put together, none of Michael's issues stood out to me as a huge issue. Just to hit a few:
      1) Significant code re-factoring: that would be expected. Devs refactor every day. This may be on a larger scale than usual, but not a blocker.
      2) new user-space interfaces: this just goes along with the significant refactoring since they would need to use the DRM interfaces instead of the catalyst kernel driver interfaces. You could view this as simply a part of refactoring.
      3) features currently missing from linux driver: sweet - so when they port it over, open source driver gets the new features for free
      4) It's not clear how AMD would handle patent-encumbered or legally risky code: you then go on a few paragraphs later saying that there isn't too much in the kernel side of the catalyst driver. It's all in the user-space side, which won't be open.
      5) new IOCTL interfaces for just the Catalyst driver: Linux might have a problem with this. The solution is simply to have interfaces that both the closed AND open source driver can use. This seems like a win to me.
      6) clear legal/technical review: they already need to do this when dropping new features in the open source driver

      It would be awesome if this really comes to fruition. Correct me if I'm wrong, but wouldn't this mean that I could have both drivers installed and switch between them on a per-application basis since I wouldn't need to change the kernel back-end driver?

      Comment


      • #33
        Hopefully that means AMD users will finally be able to Fold natively in Linux on their gpu's like Nvidia users have been able to for awhile now.
        The forme post with radeon-kdf does that and it is an alpha driver for hsa on Kaveri, so this should work in a year if amd finishes its hsa support as announced at the start of the year, but sadly no amd dev here comments on that, as far as I remember. To fold natively in linux would just need a hsa application of the project which not exist at time beeing.

        Comment


        • #34
          Does this mean AMD plan a migration from Catalyst in the medium to long term if and when the FOSS drivers reach feature compatibility?
          No, as long as application developers don't implement the graphics features like in the spec., AMD needs to have workarounds for that programs insider der prop. driver, to not loose customer which use that programs. Given that the joke with nv dont get that many errors because they don't implement the spec that strict like amd does, but that my not apply to de oss driver.

          Comment


          • #35
            This is a step in the right direction. I'd prefer full open source, but I won't say no to just more open source. I wonder, why can't the release the shared parts with a permissive licence, and make it possible to install the "secret sauce" as binary extensions? Especially if it's just userspace extensions.

            Comment


            • #36
              Originally posted by Luke View Post
              I have come to suspect that the cause of the speed disadvantage both Nvidia and AMD closed drivers get on Linux as compared to Windows comes from the fact that they don't get KMS on Linux.
              Well the NVIDIA Linux driver is exactly as fast as on Windows so that doesn't seem to be a problem.

              Comment


              • #37
                Than perhaps Nivida could run faster on LInux than WIndows?

                Originally posted by blackout23 View Post
                Well the NVIDIA Linux driver is exactly as fast as on Windows so that doesn't seem to be a problem.
                If that's the case, Nvidia might be able to make their Linux blob beat the Windows framerate if they follow AMD's lead, given the fat-pig nature of WIndows 8. Then again, maybe that would screw up their business arrangements with Microsoft.

                Comment


                • #38
                  Originally posted by _ONH_ View Post
                  The forme post with radeon-kdf does that and it is an alpha driver for hsa on Kaveri, so this should work in a year if amd finishes its hsa support as announced at the start of the year, but sadly no amd dev here comments on that, as far as I remember. To fold natively in linux would just need a hsa application of the project which not exist at time beeing.
                  Amd users shouldn't have to wait for HSA just to fold on their Gpu's. All Amd needs to do is fix their buggy OpenCl portion of the linux driver. According to Vijay Pande and proteneer anyway. I'd welcome using Catalyst until the open drivers were ready
                  Those who would give up Essential Liberty to purchase a little Temporary Safety,deserve neither Liberty nor Safety.
                  Ben Franklin 1755

                  Comment


                  • #39
                    My suspicion is that ultimately resources will be drawn down from the "full" Radeon driver and that part will, in time, die on the vine. Then FOSS fans will have to, in practice, accept a compromise of a half-free, half-non-free GPU driver. So I will be eagerly awaiting the FOSS fans here to express their outrage as they are so apt to do.

                    Trying to take a business perspective look at it, I'm sure saving money is one of the primary motivations. So having the community handle the kernel and X.org updates serves that end no doubt.

                    AMD must be in serious financial trouble.

                    Comment


                    • #40
                      Originally posted by Luke View Post
                      If that's the case, Nvidia might be able to make their Linux blob beat the Windows framerate if they follow AMD's lead, given the fat-pig nature of WIndows 8. Then again, maybe that would screw up their business arrangements with Microsoft.
                      You are misled if you think the blob drivers don't have KMS support.

                      Comment


                      • #41
                        Hmm, this is quite along the lines of what I was suggesting earlier. Though my idea was more akin to refactoring Catalyst into closed plugins for the FOSS driver (something like the S3TC situation is now). That would mean even less Catalyst and more radeon[si].

                        Originally posted by blackout23 View Post
                        Highly doubt that NVIDIA is interested in AMDs OpenGL "secret sauce" since they clearly don't need it. AMD doesn't have a competitive advantage over NVIDIA when it comes to OpenGL so what's there to lose?
                        Yea, plus, isn't that what patents are supposed to be for?

                        Comment


                        • #42
                          Too bad, they said nothing about the firmware which is still proprietary (it's not like they didn't avoid that intentionally).

                          Comment


                          • #43
                            Originally posted by GreatEmerald View Post
                            Yea, plus, isn't that what patents are supposed to be for?
                            Patents are a really expensive way of protecting IP, and don't work particularly well in a closed source environment since you have no obvious way to know if a violation occurred. You also have to make the information public as part of the patent process, and in many cases the idea is more useful than the patentable details (since patents really describe a specific implementation rather than an underlying idea).

                            Patents work well when the IP is visible to the general public by virtue of how it is used in a product, but in a closed-source environment using trade secrets requires less effort, less expense, and is generally more effective... and yes that does make closed source software a bit of a self-perpetuating thing.

                            Someone asked earlier about making everything open source except a few small binary modules containing the secrets. Problem is that reverse engineering small binary modules surrounded by open source is really easy. The idea has been tried a few times already (IIRC Intel used to have a binary shader compiler module, for example) but never seemed to work for anyone.
                            Last edited by bridgman; 03-22-2014, 02:28 PM.

                            Comment


                            • #44
                              bridgman, how long do you reckon it will take until catalyst's performance is about the same as the windows version?

                              Comment


                              • #45
                                Originally posted by hajj_3 View Post
                                bridgman, how long do you reckon it will take until catalyst's performance is about the same as the windows version?
                                I think it's a function of what you test with. Performance work on the Linux Catalyst stack is mostly focused on workstation apps, and I suspect the performance delta relative to Windows is already pretty small.

                                Comment

                                Working...
                                X