Announcement

Collapse
No announcement yet.

issues with my laptop having AMD 7970M GPU

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

  • #16
    Originally posted by alexThunder View Post
    In terminal:

    lspci

    To be more precise:

    lspci | grep VGA

    It may print something wrong (i.e. radeon 6k series. In that case, do an update-pciids in the terminal an run lspci | grep VGA again).

    Anyway, thanks for opening this thread. I have the same issue as you (as I have posted in the bug report).
    I will do it just give me 2 hours since I messed up ubuntu and its freezing when I log-in. I will reinstall it lol. I have to go buy usb flash memory

    Comment


    • #17
      Notebook GPUs are often incompatible with AMD's drivers. Nobody forces them to use the same device ids or even build the hardware correctly.

      Comment


      • #18
        Originally posted by keegdsb View Post
        Notebook GPUs are often incompatible with AMD's drivers. Nobody forces them to use the same device ids or even build the hardware correctly.
        on amd 7900m series page and driver page . It says that linux system are supported . I even download cataylst 12.8 by choosing 7xxxM series driver for linux and linux driver was present , so its fully supported . But its kinda sad for AMD not having to be functional for amd 7970M. There are also big problem too with amd 7970m enduro issue. Google it and see what is if you want to know more information

        Comment


        • #19
          Originally posted by keegdsb View Post
          Notebook GPUs are often incompatible with AMD's drivers. Nobody forces them to use the same device ids or even build the hardware correctly.
          http://ubuntuforums.org/showthread.php?t=1930450/

          When I bought my notebook I just hoped it would work. At that time I didn't know that much about hybrid graphics :/

          Comment


          • #20
            Originally posted by alexThunder View Post
            In terminal:

            lspci

            To be more precise:

            lspci | grep VGA

            It may print something wrong (i.e. radeon 6k series. In that case, do an update-pciids in the terminal an run lspci | grep VGA again).

            Anyway, thanks for opening this thread. I have the same issue as you (as I have posted in the bug report).
            ispci bring this :
            00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 09)
            00:01.0 PCI bridge: Intel Corporation Ivy Bridge PCI Express Root Port (rev 09)
            00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics Controller (rev 09)
            00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04)
            00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller #1 (rev 04)
            00:1a.0 USB controller: Intel Corporation Panther Point USB Enhanced Host Controller #2 (rev 04)
            00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio Controller (rev 04)
            00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1 (rev c4)
            00:1c.1 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 2 (rev c4)
            00:1c.2 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 3 (rev c4)
            00:1c.3 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 4 (rev c4)
            00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced Host Controller #1 (rev 04)
            00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04)
            00:1f.2 SATA controller: Intel Corporation Panther Point 6 port SATA Controller [AHCI mode] (rev 04)
            00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04)
            01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Device 6800
            03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01)
            03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 0a)
            04:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)
            05:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller (rev 30)


            lspci | grep VGA bring this
            00:02.0 VGA compatible controller: Intel Corporation Ivy Bridge Graphics Controller (rev 09)
            01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Device 6800

            Comment


            • #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