Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 45

Thread: issues with my laptop having AMD 7970M GPU

  1. #21
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,578

    Default

    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.

  2. #22
    Join Date
    Sep 2011
    Posts
    191

    Default

    Quote 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 :/

  3. #23
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,578

    Default

    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.

  4. #24
    Join Date
    Sep 2011
    Posts
    191

    Default

    Quote 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.

    Quote 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.

  5. #25
    Join Date
    Aug 2012
    Posts
    17

    Default

    Quote 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

  6. #26
    Join Date
    Aug 2012
    Posts
    17

    Default

    Quote 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

  7. #27
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,578

    Default

    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 at 11:35 PM.

  8. #28
    Join Date
    Sep 2011
    Posts
    191

    Default

    Quote 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

  9. #29
    Join Date
    Aug 2012
    Posts
    17

    Default

    Quote 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 ?

  10. #30
    Join Date
    Sep 2011
    Posts
    191

    Default

    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?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •