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.
Announcement
Collapse
No announcement yet.
issues with my laptop having AMD 7970M GPU
Collapse
X
-
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.Test signature
Comment
-
Originally posted by bridgman View PostAt 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.
Originally posted by bridgman View PostThe 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.
Anyway, I still hope, Windows 8 will fix that issue :] At least to some degree.
Comment
-
Originally posted by bridgman View PostOK, 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
-
Originally posted by bridgman View PostAt 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
-
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; 17 August 2012, 10:35 PM.Test signature
Comment
-
Originally posted by bridgman View PostThe 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
Comment
-
Originally posted by bridgman View PostIf 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.
Comment
Comment