Announcement

Collapse
No announcement yet.

When'll AMD Opensource Drivers be feature-complete for Evergreen chips

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

  • #31
    Originally posted by bridgman View Post
    I believe AMD invests more in Linux relative to the size of the company than Intel does.

    What "position" you are talking about -- being smaller ?
    bridgman,

    First of all, thank you very much for your hard work and great support you give to the community. Please note that I very much appreciate the work you and the whole AMD team at AMD do.

    That being said, the position I'm refering to is this.

    There is no AMD system that I know of that ships with linux installed. AMD is not confident enough to provide linux support for OEMs or consumers. Intel is. There are several intel laptops shipping right now with linux. There are also a few smartphones. Even nvidia is shipping products with linux right now, and a lot by the way (see nexus 7).

    What products ship with AMD chips? windows PCs, XBox 360, and if the rumors are true, the next gen xbox and playstation. Where's linux in this mix? Nowhere to be seen...

    I really hope that valve is able to persuade some high execs over there into supporting linux. AMD already lost OYUA to nvidia, and every rumor i've seems hints toward nvidia on the steambox. So in my mind, we're a living the gaming revolution on linux right now, and AMD is missing the boat as we speak.

    AMD may invest more on linux relative to its size than intel, but that changes nothing for the consumer. The same way that relative to the size of the company, FX processors are probably blazing fast, but it doesn't sell any more chips because of that.

    It's just a shame really, because I would love to have an APU based steambox...

    Anyway, keep up the good work. I sincerely hope you guys manage to achieve your objectives.

    Comment


    • #32
      AFAIK there are a number of AMD-based systems shipping with Linux preloaded. I know there were last year, but haven't been involved for a while so not sure of current status. The preloads are generally using fglrx, however, not the open source drivers. Will take a quick look and see what I find...

      EDIT -- wow, I'm not seeing many Linux preloads this year on *anyone's* hardware, even in the workstation corner. Lots of Win8 and Win7 on clients, RHEL and SLES on servers and the occasional Ubuntu client, but a *lot* less than last year.

      ... so you might be right. Hopefully that will change once everyone recovers from the Win8 transition.

      BTW you mentioned "NVidia shipping with Linux on Nexus7" -- while it's true that Android uses a kernel so it is absolutely correct to call an Android product "Linux", but since the graphics driver stacks are so different between Android Linux and typical PC Linux/Gnu/X/Mesa/DRI that they really need to be kept separate from a practical perspective. You can share a KMS kernel driver and 3D driver between the two stacks (so Android-x86 works with both intel and radeon), but that's pretty much where it ends.
      Last edited by bridgman; 01-17-2013, 11:45 AM.

      Comment


      • #33
        Originally posted by bridgman View Post
        EDIT -- wow, I'm not seeing many Linux preloads this year on *anyone's* hardware, even in the workstation corner. Lots of Win8 and Win7 on clients, RHEL and SLES on servers and the occasional Ubuntu client, but a *lot* less than last year.

        ... so you might be right. Hopefully that will change once everyone recovers from the Win8 transition.
        How should I read this?
        - we will hold every platform support, until our windows 8 driver is polished so that people are forced on windows 8 - We compensate ugly interface with stable driver - crashing/underdeveloped driver for other platforms.
        or
        - we put every effort into windows 8 right now, so others are not important, regardless of what crowd and Gaben says?

        Also, *source* on *a lot less Linux preloads* please..?
        Fact is, mobile non-x86 processors are dominating this year, with a LOT of Linux Android/or full-blown hatching, incl. gaming. These are not powered by AMD GPUs/APUs, so thats obvious.
        However, why should relative preload marketshare of x86 change due to this?
        Last edited by crazycheese; 01-17-2013, 12:31 PM.

        Comment


        • #34
          Originally posted by bridgman View Post
          I guess the most important part of the answer is that the addition of a feature to the list doesn't necessarily mean that anyone expects to ever work on it -- sometimes features are added just to make it clear what is and is not included.

          Most of the features you mentioned are discussed here on a regular basis, but here's a quick summary off the top of my head :

          * Video Decode (XvMC/VDPAU/VA-API) on the 3D engine -- Christian and others put a lot of work into this and concluded that it wasn't likely to work particularly well for H.264 using the graphics pipeline. Christian thought that compute shaders (with their lower overhead) might be a sufficient improvement but at the time the compute infrastructure wasn't in place. Short term focus is on investigating whether we can expose UVD support (internal), and building up compute infrastructure via OpenCL efforts below.

          * Video Decode (XvMC/VDPAU/VA-API) on UVD - see above

          * Hybrid Graphics - lots of work on this over the last year, mostly by airlied

          * Stippled Primitives - don't think anyone is looking at this, or if there is much use outside of a few workstation apps

          * Smooth Primitives - ditto

          * Tessellation Shader Stages - believe this is GL4 functionality so would probably get looked at after 3.3 is done

          * Geometry Shaders - this is GL3.2 so "it's number just came up" -- article in the last few days about work on this by airlied

          * Hyper-Z - lots of work on this over the last year but don't think it's ready to turn on by default yet

          * CrossFire (multi-card) - don't think anyone is looking at this -- improving performance of single card 3D is generally felt to be better use of time

          * Compute (OpenCL) - lots of work on this over the last year by tstellard and a some community developers

          BTW I only counted 10 -- what did I miss ?


          Hello, are you shure that you know what are you talking about???

          support for vaapi was removed with this commit
          http://cgit.freedesktop.org/mesa/mes...61cf0955c33072

          and for vdpau acceleration is working only mpeg2 and for this codec not even all profiles, just simple I belive!!

          Comment


          • #35
            Originally posted by crazycheese View Post
            How should I read this?
            - we will hold every platform support, until our windows 8 driver is polished so that people are forced on windows 8 - We compensate ugly interface with stable driver - crashing/underdeveloped driver for other platforms.
            or
            - we put every effort into windows 8 right now, so others are not important, regardless of what crowd and Gaben says?
            or, OEMs are not asking for Linux pre-loads at the moment?

            Comment


            • #36
              Originally posted by crazycheese View Post
              How should I read this?
              - we will hold every platform support, until our windows 8 driver is polished so that people are forced on windows 8 - We compensate ugly interface with stable driver - crashing/underdeveloped driver for other platforms.
              or
              - we put every effort into windows 8 right now, so others are not important, regardless of what crowd and Gaben says?
              Read it as "there seem to be a lot fewer Linux preloads overall, and the ones that are there seem to be going for IGP-level graphics rather than dGPU so we don't seem to have as much of a share as in previous years. Our share is probably the same for dGPU ("traditional workstation") but right now those SKUs seem to be largely Windows-only no matter which GPU vendor you look at.

              Originally posted by crazycheese View Post
              Also, *source* on *a lot less Linux preloads* please..?
              I spent a few minutes looking at web sites for a few major OEMs and compared what I saw to my recollections from previous years.

              Comment


              • #37
                Originally posted by lucx View Post
                Hello, are you shure that you know what are you talking about???

                support for vaapi was removed with this commit
                http://cgit.freedesktop.org/mesa/mes...61cf0955c33072

                and for vdpau acceleration is working only mpeg2 and for this codec not even all profiles, just simple I belive!!
                Nope, but in this case I don't understand what point you are trying to make.

                How is what you are saying inconsistent with what I said ?

                Comment


                • #38
                  Originally posted by bridgman View Post
                  Nope, but in this case I don't understand what point you are trying to make.

                  How is what you are saying inconsistent with what I said ?
                  sorry for that I just misunderstood your post!

                  Comment


                  • #39
                    Originally posted by agd5f View Post
                    What does this mean? Comes up in a mode you don't like? dualhead vs. clone? something else? The driver just generates an event when a monitor is plugged or unplugged. It's up to your desktop environment to decide what to do with that event.
                    I have the same issues on my 6650. I have 2 heads connected, one via DVI and one via Displayport with both a HPLP2475w. When I even hit the 'scan' button to scan for inputs, the system thinks the head got disconnected. I have to do an ctrl-alt-f2 ctrl-alt-f1 to switch out/in to graphical mode to re-activate the port.

                    Comment


                    • #40
                      question, questions

                      Thanks for the update John!

                      Can you (one of the devs) explain a bit more about the VBIOS tables?
                      Can that be compared to something like the ACPI tables (eg. DSDT) or is it just the several states like "video watching" (GPU on xxx MHz, VRAM on xxx MHz) and "gaming" (with GPU on yyy MHz etc.)? Why do these tables lack information?

                      I personally always used Sapphire cards which afaik are close to AMD's reference design and they normally work nicely - also in terms of power consumption. Actually I have with profile=low (free driver stack) same or even 1-2 W better overall (power plug wall measured) wattage like I have in Windows XP with Catalyst. It's like 83 W (Linux free) idle vs. 85 W idle (W32). (Didn't try fglrx/Linux for a long time )
                      So I personally am really fine with power side of the free stack (just sad that dynpm does not use low profile!). But I see complaints from others sometimes.

                      So do some vendors provide clean implementation of VBIOS tables (like some mainbaord people provide good DSDTs) and some do not? How many quirks are allowed for a vendor that sells a Radeon GPU somewhere in a solution?

                      edit: And yes please for any kind of video accel (your E-350 Mini-ITX style boards would be perfect HTPCs then!) (low power, passively cooled and so on)

                      Comment


                      • #41
                        After reading many Phoronix articles, I gather that legal review of code (in AMD) can take a really long time, and sometimes code is never even released due to concerns that potential "IP" or "patents" will be lost (or in the case of video acceleration bullshit concerns over DRM). Is this true?

                        In that case, if people external to AMD contributed more, would that speed up development since there's no legal barrier on them?

                        Also, I would like to know from the AMD employees here if they consider the information and specifications already released by AMD sufficient to make the drivers stable and feature-complete (the features I'm thinking about are very good power management, full 2D and 3D acceleration, OpenGL 4.3 support, OpenGL ES 3.0 support, OpenCL 1.2 support - all depending on hardware capability of course).

                        Comment


                        • #42
                          Originally posted by sandy8925 View Post
                          After reading many Phoronix articles, I gather that legal review of code (in AMD) can take a really long time, and sometimes code is never even released due to concerns that potential "IP" or "patents" will be lost (or in the case of video acceleration bullshit concerns over DRM). Is this true?

                          In that case, if people external to AMD contributed more, would that speed up development since there's no legal barrier on them?
                          Code itself doesn't go through review other than the devs making sure there is no additional IP being released with it. It's the big chunks of new hardware programming info that take time... not because programming info itself needs to be protected but because programming info sometimes reveals internal design info that we can't easily get agreement to release.

                          Even then, it's usually not the review that takes time, it's figuring out what to do when the answer is "no" the first (or second, or third) time. The process is kind of a parallel activity -- get internal agreement on what information we can expose (that's what takes the time) and make sure the initial code we plan to release which uses that info stays within the bounds of what we have approval to release.

                          Key point though is that other than a couple of remaining areas like power management and UVD, driver progress is primarily a function of the amount of developer time available to work on it, so additional contributions definitely speed up development.

                          Originally posted by sandy8925 View Post
                          Also, I would like to know from the AMD employees here if they consider the information and specifications already released by AMD sufficient to make the drivers stable and feature-complete (the features I'm thinking about are very good power management, full 2D and 3D acceleration, OpenGL 4.3 support, OpenGL ES 3.0 support, OpenCL 1.2 support - all depending on hardware capability of course).
                          Power management no (but we're working on it), everything else pretty much yes. I say pretty much because there are always questions and problems that come up during development but we can usually respond to those pretty quickly if we can lay hands on the information internally. As am example, I don't think we have written documentation that says "this is how you implement tesselation on xxx generation of hardware" (because we usually have to write code ourselves to figure it out anyways), so our devs either write the initial code themselves or work with the community devs who are implementing new functionality. You can watch a lot of that happening on #dri-devel and #radeon.

                          There are exceptions to everything, of course. HDMI audio information turned out to be a bit of a black hole, which we didn't expect at all, while other areas turn out to be easier than we expected. Normally driver devs don't have to care about "where the hardware came from" but when you try to release programming info to the public everything that ever happened in the last ten years of HW development becomes a possible roadblock. We can generally get through or around all the issues eventually, but it tends to take finite calendar time as well as effort and so is hard to speed up by throwing more resources at it.
                          Last edited by bridgman; 01-19-2013, 04:08 PM.

                          Comment


                          • #43
                            Originally posted by bridgman View Post
                            HDMI audio information turned out to be a bit of a black hole, which we didn't expect at all, while other areas turn out to be easier than we expected.
                            Hi John, thanks for all your work. I'm curious if HDMI audio is something that is still being worked on? I recently bought a nettop that has a Radeon 4310 card in, and I'd love the ability to passthrough TrueHD / DTS-HD content. Do you think this will ever be possible? For those interested, is there a mailing list or wiki that might have status updates? I find it to be a difficult subject to track.

                            Comment


                            • #44
                              Bridgman, thanks for your information.

                              Comment


                              • #45
                                I still don't understand why IP review seems to be the biggest overall roadblock with open source driver development in AMD's case. I have never heard of any such problems from Intel developers, and certainly I haven't seen month or even year long delays that could be attributed to legal issues.

                                It's not a good sign when the processes inside a company make it impossible to work efficiently.

                                Comment

                                Working...
                                X