Announcement

Collapse
No announcement yet.

issues with my laptop having AMD 7970M GPU

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

  • #21
    OK, looks like the same device ID (6800). You might want to add your email address to ticket 555 so you get notified on updates.

    Comment


    • #22
      Originally posted by bridgman View Post
      OK, looks like the same device ID (6800). You might want to add your email address to ticket 555 so you get notified on updates.
      Do you think this will actually be fixed? I'm somehow pessimistic right now :/

      Comment


      • #23
        At first glance it seems like one of those "driver team wasn't told about the new device ID or they would have added it already" issues; if so then fixing it seems likely. If it's something wierder, it'll depend on what the problem turns out to be.

        The big challenge with the industry right now is that most OEMs only test their new hardware with the OSes they plan to preload on it, so GPU driver teams only know about issues (and can provide feedback to the OEM) when the hardware is planned with a Linux preload option. OEM offerings of Linux preloads haven't aligned too well with what Linux users want to buy, so there's not a lot of perceived market and hence not a lot of preloading (and not a lot of testing/fixing with Linux during OEM HW development) going on right now.

        One powerful message for OEMs would be asking them to pick a couple of SKUs and at least *test* them with Linux before locking down the hardware and BIOS designs, so that GPU vendors can tweak drivers or OEMs can tweak HW/BIOS before launch.

        Comment


        • #24
          Originally posted by bridgman View Post
          At first glance it seems like one of those "driver team wasn't told about the new device ID or they would have added it already" issues; if so then fixing it seems likely.
          Ok, let's hope it's just that.

          Originally posted by bridgman View Post
          The big challenge with the industry right now is that most OEMs only test their new hardware with the OSes they plan to preload on it, so GPU driver teams only know about issues (and can provide feedback to the OEM) when the hardware is planned with a Linux preload option. OEM offerings of Linux preloads haven't aligned too well with what Linux users want to buy, so there's not a lot of perceived market and hence not a lot of preloading (and not a lot of testing/fixing with Linux during OEM HW development) going on right now.
          In my case, the vendor actually says, that they don't test their hardware on Linux, but still warned us not to chose NVidia GPUs because of Optimus. So I listened, but ... well you know how it ended ^^

          Anyway, I still hope, Windows 8 will fix that issue :] At least to some degree.

          Comment


          • #25
            Originally posted by bridgman View Post
            OK, looks like the same device ID (6800). You might want to add your email address to ticket 555 so you get notified on updates.
            all ready did that yesterday and commented even with my email and posted link to this forum . Hopefully you can forward this to amd

            Comment


            • #26
              Originally posted by bridgman View Post
              At first glance it seems like one of those "driver team wasn't told about the new device ID or they would have added it already" issues; if so then fixing it seems likely. If it's something wierder, it'll depend on what the problem turns out to be.

              The big challenge with the industry right now is that most OEMs only test their new hardware with the OSes they plan to preload on it, so GPU driver teams only know about issues (and can provide feedback to the OEM) when the hardware is planned with a Linux preload option. OEM offerings of Linux preloads haven't aligned too well with what Linux users want to buy, so there's not a lot of perceived market and hence not a lot of preloading (and not a lot of testing/fixing with Linux during OEM HW development) going on right now.

              One powerful message for OEMs would be asking them to pick a couple of SKUs and at least *test* them with Linux before locking down the hardware and BIOS designs, so that GPU vendors can tweak drivers or OEMs can tweak HW/BIOS before launch.
              bridgman , I see you work for amd , I have question. why amd cant make a unified driver for all switchble graphics wihtout relying on oem engieers. Although , your answer would be beaucse oem can cutimize the grpahics chip part like memory , etc. For example. our clevo machine have amd 7970 gpu with Hynix memory but alineware have samsung memory. Now trick here, is oem vendors can also custimize nvidia chip also for example, Nvidia 680m for clevo also come with Hynix memory and alienware uses samsung memory too, but Nvidia is able to release unified driver ???. I dont see Nvidia different from amd , when it to custimize the graphic pcb

              Comment


              • #27
                If OEMs followed the specs exactly we could. The problem is that OEMs want (need) to differentiate or they end up chunking out standard boxes based on reference designs and competing purely on price -- which would be great for Linux users but hard on OEM financials. The gradual transition from muxed to muxless hybrid designs hasn't helped either -- hopefully things will settle down in another year or so.

                From an OEM's perspective they sell an integrated HW/SW solution with preloaded OS and as long as that works "everyone is happy", right ?

                EDIT -- btw memory isn't the issue, it's more things like how GPU ports are connected to display connectors, whether outputs from both GPUs are hooked up.

                It's probably fair to describe the problem as "system configurations evolving more rapidly than the underlying standards which describe them to drivers and OSes". I'm not 100% sure of that but it's the impression I get. Some of this is covered by ACPI which is where the header info we released recently might help, but AFAIK some things just aren't covered by standards at all.
                Last edited by bridgman; 08-17-2012, 10:35 PM.

                Comment


                • #28
                  Originally posted by bridgman View Post
                  The problem is that OEMs want (need) to differentiate or they end up chunking out standard boxes based on reference designs and competing purely on price
                  I didn't notice that there are such big differences among these OEM machines besides price and design

                  Comment


                  • #29
                    Originally posted by bridgman View Post
                    If OEMs followed the specs exactly we could. The problem is that OEMs want (need) to differentiate or they end up chunking out standard boxes based on reference designs and competing purely on price -- which would be great for Linux users but hard on OEM financials. The gradual transition from muxed to muxless hybrid designs hasn't helped either -- hopefully things will settle down in another year or so.

                    From an OEM's perspective they sell an integrated HW/SW solution with preloaded OS and as long as that works "everyone is happy", right ?

                    EDIT -- btw memory isn't the issue, it's more things like how GPU ports are connected to display connectors, whether outputs from both GPUs are hooked up.

                    It's probably fair to describe the problem as "system configurations evolving more rapidly than the underlying standards which describe them to drivers and OSes". I'm not 100% sure of that but it's the impression I get. Some of this is covered by ACPI which is where the header info we released recently might help, but AFAIK some things just aren't covered by standards at all.
                    thanks for explanation . can you give us a time estimate for the problem to be fixed based on your knowledge on fixing bugs ?

                    Comment


                    • #30
                      Aren't the ID's stored in /etc/ati/control ? If that's the case, couldn't AMD simply put out an updated control file?

                      Comment

                      Working...
                      X