AMD Responds to Lack of Ryzen Mobile Driver Updates, Claims OEMs are the Issue

[Dan6erbond]

This is pretty weak. I mean, there are probably various power management tweaks implemented by OEMs, sure. But why should they be linked to drivers at all, or at the very least, why should they be affected by updated generic drivers? Other than that, the rest of the driver should be entirely unaffected no matter what. This shouldn't be more of a challenge than flagging a section of the driver as "Vendor specific" and giving settings there priority over other settings they might conflict with, and leaving that part blank in the generic driver.

Frankly, I don't get why APU iGPUs don't use the regular GPU driver package in the first place. What is the problem of mixing drivers in an integrated package like an APU, vs. doing the same with discrete components? The system sees them as discrete components anyhow, so is this really a problem? You have one power management driver for power management, one GPU driver for making the GPU work, and so on. This ought to be easy. Modularity = flexibility; bundling everything into a single package is just plain dumb.

I fully agree and as you can see in my comments, I think that even if OEMs did changes, a simple config file would do the tricks as well and would be easy as dirt to implement.

 

[FordGT90Concept]

I'm pretty sure AMD had (not entirely unexpected) other priorities and are just trying to save face here.

AMD did their job with improving Ryzen and Vega support in drivers. AMD can't do HP's job to update driver packages and push them out to Envy X360 owners.

Edit: Also, not once did I visit Acer's website when looking for newer drivers for my laptop's Nvidia GPU.

Nvidia hasn't made an integrated GPU in PC space in a decade. That's a discreet GPU and that's not the problem here. It's specifically mobile (always custom board) APUs.

no driver on amd website works, you are stuck with the laptop website from the 1990s, i hate this

Same issue at hand. It's the OEMs duty to package drivers and...they don't care. Microsoft added insult to injury with Windows 10 trying to force the install of newer, incompatible drivers.

 

[sixor]

Yeah... And when was this GPU last sold in any machine? I you can't expect a company to support a product that's been out of production for almost 30 years. If youre not going to be doing any serious gaming with that netbook so why should AMD care to release any drivers? That's 'legacy' legacy hardware


no, not even when it was released it had AMD support

you went to amd website and downloaded the drivers and they did not worked, your hardware is not compatible bla bla bla.

well, funny, this gpu is amd and i am on the amd website downloading the drivers for it, not nvidia, not intel, they release it and never support it, you had to go to ACER, lenovo, etc website to download ultra outdated drivers

And with so many sku's since then. Maybe they are different. Which is why NGO and Omega stopped

 

[Vya Domus]

I think that even if OEMs did changes, a simple config file would do the tricks as well and would be easy as dirt to implement.

It's clear that it isn't that simple.

 

[FordGT90Concept]

The vast majority of vendor-distributed drivers are straight-up unmodified, and the vast majority of most modified drivers is again straight from the OEM, with only very minor modifications implemented.

Yes, when you include GPUs and similar generic PCI Express-based hardware. When looking specifically at APUs, that's not the case. People have tried AMD's generic driver on these machines (and E-#50 previously) and the generic drivers have lots of problems. OEM-tailored drivers are absolutely required because the hardware changes they made are extensive.

Leaving a blank space for [Insert vendor modification here] in the driver really shouldn't cause meaningful bloat...

The INF would have to contain language for every custom OEM version out there. It would also have to include binaries specific to those OEMs. Yes, a lot of bloat, that's useless to 99.99% of people that download it.

Sure, there are variations in how hardware is implemented, but modifying a driver for this should be dead simple - how hard can it be commenting out a section of the driver code, or just deleting it?

It most likely is simple but it's something the OEMs have to do and they don't bother to because they've moved on to newer models.

Also, where's the harm in a driver exposing a SATA or USB controller that doesn't have any ports, or PCIe lanes that don't ever leave the substrate?

BSODs, mostly (likely because of IRQ assignments). I'm not entirely sure how the Linux Kernel handles it but it at least seems to get a lot more TLC than OEMs give SKUs.

OEMs will never properly support "older" products, it's in their interest to waste your time with problems to force you to buy a new device. Which is why AMD just needs to upload those generic drivers we can download and using for the future, at least 3 years of support should be included on a platform like this, if not more. My last laptop with a Radeon R5 is still getting updates and is more stable than my current P.O.S.

They did and they don't work. The last paragraph in AMD's reply says they're going to try to make them work but there's no guarantee they can. AMD would need access to HP's engineering records which they don't have.

 

[Valantar]

Yes, when you include GPUs and similar generic PCI Express-based hardware. When looking specifically at APUs, that's not the case. People have tried AMD's generic driver on these machines (and E-#50 previously) and the generic drivers have lots of problems. OEM-tailored drivers are absolutely required because the hardware changes they made are extensive.

Current AMD APUs are SoCs, and should thus only require power and I/O to work. What functionality-breaking modifications can OEMs do here? Sure, there are plenty of ways to implement I/O, including all kinds of chips between the APU and the ports, but connecting to any and all of these is within the standard capabilities of the SoC, and should thus be supported in standard drivers, or have discrete drivers of their own. As for the APUs themselves, they consist of a single Ryzen CCX, alongside a GPU connected over an internal PCIe link. The system naturally sees each device as a discrete device, regardless if it's on the same silicon or not. I'm fully aware that AMD's generic drivers don't work well in laptops, but it should be entirely possible to make it so. It shouldn't be a problem whatsoever for the iGPU to use the bog-standard GPU driver, if only AMD made the effort to tune it as they do for every single other GPU they make. The only difference between desktop Vega and APU Vega is the lack of VRAM, which really shouldn't require continuous and overly complicated tuning for every single driver release.

The INF would have to contain language for every custom OEM version out there. It would also have to include binaries specific to those OEMs. Yes, a lot of bloat, that's useless to 99.99% of people that download it.

It might be that it works this way, but that sounds incredibly convoluted and backwards. A much simpler solution would be what I said - leave a space for vendor-specific tweaks in the generic driver that is entirely blank outside of a placeholder, make sure the installer doesn't overwrite anything in this space, and that's all you'd need beyond the already existing "is this device compatible" check when the installer is run. The only thing required for this to work properly would be for AMD to structure the driver consistently so that OEM tweaks don't suddenly break after an update. The amount of bloat in the generic driver would be minimal, as any additional data would be tacked on in a modular fashion by OEMs - and their tweaks would carry over to subsequent installs of generic game ready drivers without the OEM needing to check everything again and again.

It most likely is simple but it's something the OEMs have to do and they don't bother to because they've moved on to newer models.

Which is exactly why it makes no sense whatsoever for OEMs to provide drivers in the first place.

BSODs, mostly (likely because of IRQ assignments). I'm not entirely sure how the Linux Kernel handles it but it at least seems to get a lot more TLC than OEMs give SKUs.

Again: it might be that this would happen, but if so that would be due to bad system design, and not actually a driver issue. If a pre-made PC can't handle its own IRQ assignments properly, it's designed badly. Also, shouldn't any unused controllers be disabled in the BIOS/UEFI, and thus immune to being "reactivated" by generic drivers?

 

[medi01]

Notebook drivers for GPU has been something that notebook manufacturers provided since the day I've learned the word "notebook".

Of course they already had your money, so why would they invest time and resources into improving something that yields no return

Because else you might never ever buy their product.

 

[bug]

Notebook drivers for GPU has been something that notebook manufacturers provided since the day I've learned the word "notebook".

And that's relevant how?
While manufacturers do like to offer these themselves, drivers are traditionally available straight from the GPU/IGP maker. Like this: https://downloadcenter.intel.com/product/80939/Graphics-Drivers
And yes, there's even a new beta driver for Vega in there.

 

[laszlo]

in my opinion OEM's should make only a mandatory "driver" package which shall contain their instruction on how the hardware is used for each specific mb/product

end user should update from amd site and after that install the above oem's package instruction

 

[bug]

in my opinion OEM's should make only a mandatory "driver" package which shall contain their instruction on how the hardware is used for each specific mb/product

end user should update from amd site and after that install the above oem's package instruction

Or to put it another way: the silicone is the same for everybody. It is physically impossible for it to require a custom driver. Manufacturers may fiddle with setting within the universal driver, nothing beyond that.

 

[FordGT90Concept]

Current AMD APUs are SoCs, and should thus only require power and I/O to work.

AMD doesn't call them SoC because they are not. CPU cores + memory controller + GPU cores + PCI Express lanes. SoC include everything from SATA to ethernet.

And that's relevant how?
While manufacturers do like to offer these themselves, drivers are traditionally available straight from the GPU/IGP maker. Like this: https://downloadcenter.intel.com/product/80939/Graphics-Drivers
And yes, there's even a new beta driver for Vega in there.

The Vega is effectively discreet in design (MCM'd with HBM2) which is why it is on AMD's driver timeline.

Look how old the drivers are for everything not Skylake and newer. Haswell/Devil's Canyon are still all over the place yet, you're stuck with a version 15 driver when Skylake and newer has moved to 25. Additionally, I can't name how many times I tried to install drivers for Intel devices only to have the driver tell me "LOLNOPE." Since Windows 10 debuted, I just let it install whatever it wants and never bother changing it.

 

[ACE76]

This article seems like it's written by someone who knows nothing about computers...desktop CPUs are not the same as laptop CPUs. Yes, the mobile CPU is the same for the OEMs but do you honestly think a company trying to release an Ultrabook that has limited cooling capacity will run it the same as another who releases a 14-15 inch laptop that is thicker and has more space for cooling and battery? No...voltages are altered along with clock speeds...not only that but the GPU has to be taken into account too. If AMD releases drivers that work "universal" you could have overheating issues, battery problems, etc.

 

[Dan6erbond]

And that's relevant how?
While manufacturers do like to offer these themselves, drivers are traditionally available straight from the GPU/IGP maker. Like this: https://downloadcenter.intel.com/product/80939/Graphics-Drivers
And yes, there's even a new beta driver for Vega in there.

What kind of a beta driver for Vega are you talking about?

This article seems like it's written by someone who knows nothing about computers...desktop CPUs are not the same as laptop CPUs. Yes, the mobile CPU is the same for the OEMs but do you honestly think a company trying to release an Ultrabook that has limited cooling capacity will run it the same as another who releases a 14-15 inch laptop that is thicker and has more space for cooling and battery? No...voltages are altered along with clock speeds...not only that but the GPU has to be taken into account too. If AMD releases drivers that work "universal" you could have overheating issues, battery problems, etc.

Yet it's been possible in the past with for example the A-Series APUs for AMD to deliver drivers through their website and if users were dealing with instabilities, the OEM drivers didn't suck as hard as they do now. I think you're the one that doesn't understand the mobile space as much as you should to talk on a forum like this.

 

[bug]

This article seems like it's written by someone who knows nothing about computers...desktop CPUs are not the same as laptop CPUs. Yes, the mobile CPU is the same for the OEMs but do you honestly think a company trying to release an Ultrabook that has limited cooling capacity will run it the same as another who releases a 14-15 inch laptop that is thicker and has more space for cooling and battery? No...voltages are altered along with clock speeds...not only that but the GPU has to be taken into account too. If AMD releases drivers that work "universal" you could have overheating issues, battery problems, etc.

Voltages, cooling and battery have nothing to do with how the driver is written. GPU architecture does and that's the same across the board.

 

[R0H1T]

Not to toot my own horn, but I'm sure that my post was the one AMD was responding to when they made this statement, because they also commented it in my post about this issue.

It really feels like they aren't listening because I myself have said many times that the chips in every Ryzen Mobile system - including the PRO chips - are exactly the same and the OEMs don't do anything to the drivers or chip besides limiting the TDP in some cases to keep the system from overheating (which isn't even the case for TDP limited devices). These limits are usually controlled by the BIOS anyways and that's why installing "unsupported" drivers yields in so much success without the device "exploding" or becoming bricked.

The drivers that Acer, Dell, Asus and Co. release on their website are clearly just copy-pastes from what AMD sends them which shows that either AMD is the problem here by not coding drivers, or what I believe is the more realistic case, OEMs have deals with AMD (and maybe other brands) that stop AMD from posting those "reference" drivers to their website and for their own reasons they aren't uploading the drivers they're probably getting from AMD. The OEMs probably aren't updating the drivers on their websites because as you said, it's in their interest if your device doesn't work and you go out, running to buy a new one.

The thing is that in the end, most of us are more pissed off about the driver situation because the devices are so unstable. From random freezing to BSODs, everything can happen which in my case often resulted in data loss - during a class/exam - and is my main reason for trying to get HP to let me switch out my device for a new one. I wouldn't mind some performance issues if at least my device were stable - but that isn't the case and it's the reason so many people aren't recommending AMD laptops and are even going as far as to creating posts to stop people from making the mistake they made.

Please AMD, if you're reading, we love you as a company, Ryzen and Vega are great products, but situation with Ryzen Mobile currently is uncomprehensible and the company's response isn't any better. We'll only start buying your Mobile products again - and recommending them - when you fix this and formally apologize to the community for making them wait this long and triggering an internet-wide shitstorm that really shouldn't be necessary. Come on, you make intel and nVidia look pro-consumer, yuck.


That's the only plausible reasoning there currently is to this situation: generic drivers are being "blocked" by OEMs through a close that was possibly created in cooperation with intel/nVidia to give AMD the bad name they're getting.


The thing is that even if OEMs did a lot of changing with the drivers, things like config files exist so if the OEMs were worried about generic AMD drivers being installed, they would have to implement a config file like that with AMD in the software that possibly users could even configure and everyone would be happy.


I feel you dude, if I'm not mistaken I have the most expensive Ryzen Mobile device on the market - the top-end HP EliteBook 755 G5 - and it hurts, so much that I'm currently working with HP to get the EliteBook 840/850 G5.


I can imagine this being the case as intel has pulled this kind of bs before, nVidia has never done anything as illegal as this though...

Well the steps I took to update the Intel driver was to delete the driver files & uninstall it via device manager. Then as the device manager detected (generic) vga device, I simply updated them to the latest Intel version. Apparently this doesn't always work, I've tried a few times where it failed, but it does when you manually update the drivers, before the system (win10 in my case) auto updates the IGP driver.

Have you tried the manual route before this?

 

[Dan6erbond]

Well the steps I took to update the Intel driver was to delete the driver files & uninstall it via device manager. Then as the device manager detected (generic) vga device, I simply updated them to the latest Intel version. Apparently this doesn't always work, I've tried a few times where it failed, but it does when you manually update the drivers, before the system (win10 in my case) auto updates the IGP driver.

Oh, you're talking about KabyLake-G!

 

[R0H1T]

Oh, you're talking about KabyLake-G!

No KBL-R, but I don't see why AMD drivers couldn't be updated the same way. I've tried something similar when I had a previous gen AMD laptop.

 

[FreedomEclipse]

Well, Nvidia managed to write a unified driver. Works on every card, every OS. I wish AMD spoiled us like that (and yes, I know that Nvidia isn't exactly playing nice with Linux in order to use one driver everywhere, but as long as it works, I'm good). From a cost point of view, I'm pretty sure AMD wishes they could spoil us like that, too, but the entry cost is probably just too high.

Did they? i thought they stopped adding legacy cards to the driver package ages ago

 

[Dan6erbond]

No KBL-R, but I don't see why AMD drivers couldn't be updated the same way. I've tried something similar when I had a previous gen AMD laptop.

Yeah, you're right about that being possible for AMD Ryzen Mobile APUs, but it can't be done if we don't get drivers from AMD, which is why mine and other posts exist.

 

[R0H1T]

Have you unpacked the drivers & checked the *inf files? I say this because it's been quite a while since mobile Ryzen launched & surely there could/should have been a stable driver update in that time.

 

[Dan6erbond]

Have you unpacked the drivers & checked the *inf files?

Yup, nothing for the Vega 10 that isn't terribly unstable. 18.10.2 had something, but it caused system crashing and freezing. As one of those who started this wave of complaints, I obviously did my research and testing as one of my posts is full of test .

 

[bug]

Did they? i thought they stopped adding legacy cards to the driver package ages ago

What does legacy have to do with the discussion at hand?
(And yes, supported for old architectures is relegated to a legacy branch. It's still one driver, it just doesn't make sense to send the bits for old cards to everyone. But even that gets updated from time to time.)

 

[medi01]

And that's relevant how?

I had exactly this problem, of newer driver being available from AMD, but not from the notebook manufacturer.
And no, it wasn't really working as expected, if I tried AMD's.

 

[xkm1948]

But, but my underdog can do no wrong!

But evil shintel and ngreedia!


Oh wait, i can still update Nvidia mGPU drivers from 2009 just fine(gt230m)

Shitty support gets you shitty reputation. RyZen was good. Meanwhile RTG has been nothing but a train wreck.

 

[Darmok N Jalad]

Seems like it needs more explanation than that. Does the OEM maybe need to also push firmware/BIOS updates for the newer drivers to work well? With Ryzen mobile being relatively new, it’s possible OEMs built their devices on an early spec. The “hot bag” issues MS had with SP4 and SB2 come to mind—they tried to implement a 1.0 power management feature from Intel that didn’t work right, while every other OEM basically ignored that 1.0 feature based on past experience. Could OEMs be doing something similar with Ryzen mobile where the initial configuration and driver set was very conservative for the sake of stability, and that AMD can’t push out newer drivers that bring better performance until firmware gets properly tweaked?