Does. Not. Compute.

This, with the lower battery life compared to competing Intel solutions, is the main reason I recommend against buying Ryzen laptops to my friends/family.
And that bullshit excuse is fishy, offering the generic drivers on site at least seems like a simple solution and my guess the OEMs are somehow stopping them. I mean they (AMD) do have some dumb choices but this is absurd.

I've got the Acer Nitro 5 with the Ryzen 2700U so I know how it feels. This mobile driver issue is pretty bad.

hmmm not sure if Intel is paying OEMs to stop development of AMD OEM drivers :rolleyes:

I'm guessing Omega drivers are no longer with us?

I think what is going on here is that the launch drivers were immature. OEMs generally don't provide any drivers outside of launch. The most they'll do is things like Intel Management Engine and BIOS upgrades to update microcode for security reasons. In other words, what OEMs did in regards to Ryzen were par for the course. AMD needs to pressure them to push out updates for Ryzen APUs because they need it and it sounds like that is what they're doing.

They need to increase number of people who works on mobile drivers and testers and that's it, then they can update drivers depending in number of issues people having and not having fixed release date for drivers that's just plain stupid.

FordGT90ConceptI think what is going on here is that the launch drivers were immature. OEMs generally don't provide any drivers outside of launch. The most they'll do is things like Intel Management Engine and BIOS upgrades to update microcode for security reasons. In other words, what OEMs did in regards to Ryzen were par for the course. AMD needs to pressure them to push out updates for Ryzen APUs because they need it and it sounds like that is what they're doing.

That is not true. OEMs won't release drivers with the same frequency AMD or Nvidia do, but they do provide updates.

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.

Have they fixed the Linux drivers at least?

FordGT90ConceptI think what is going on here is that the launch drivers were immature. OEMs generally don't provide any drivers outside of launch. The most they'll do is things like Intel Management Engine and BIOS upgrades to update microcode for security reasons. In other words, what OEMs did in regards to Ryzen were par for the course. AMD needs to pressure them to push out updates for Ryzen APUs because they need it and it sounds like that is what they're doing.

I have an Intel 8th gen ULV chip, which last got a (IGP) driver update well over a year back. If Intel can't force OEM updates, what chance does AMD have?

bugThat is not true. OEMs won't release drivers with the same frequency AMD or Nvidia do, but they do provide updates.

Didn't say they don't but generally they only do if it is security related where there's a modicum of liability involved. Another case where I've seen BIOS updates pushed is if they're selling the same platform with new processors (e.g. Ivy Bridge support added to Sandy Bridge motherboards because they're selling the machine packaged with Ivy Bridge instead of Sandy Bridge).

ValantarBut why should they be linked to drivers at all, or at the very least, why should they be affected by updated generic drivers?

ValantarFrankly, 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?

Because for decades, OEMs packaged their own drivers for their own machines. They strongly advise you to not get drivers directly from the manufacturer. Before Intel HD Audio became standard, it was common for AC'97 drivers direct from manufacturer to crackle and have other sound defects where sound drivers from the OEMs just worked despite being much older. A lot of the reason for this is that there is no standard for how PCBs are made. Physical features of chipsets, for example, may be unlinked entirely so drivers need to inform the operating system not to use those devices. Unless Intel and AMD adapt a policy of no modifications for OEMs, OEMs will have to continue to provide specialized drivers to customers. We can get by with blanket drivers for graphics cards, for example, because AIBs don't heavily modify integration like OEMs do for motherboards.

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

That would make the driver package huge and bloated. That translates to time and money (more costly to package and distribute).

R0H1TI have an Intel 8th gen ULV chip, which last got a (IGP) driver update well over a year back. If Intel can't force OEM updates, what chance does AMD have?

Exactly. The difference is the IGP driver was mature at launch and Ryzen/Vega wasn't. AMD can't make OEMs push an update but AMD is trying to get on their case that they need to do so because performance and stability fixes warrant it.

AMD should´ve learned with Bulldozer that relying on others is a big mistake.

Support the stuff you build, nobody else will care about your stuff.
Others sell it once, but on the long term your Firmwares and Drivers and Software evolves, that could aid you via OEM if you do the support by yourself.
AMD needs to better its reputation at the endconsumer on every field.

"Don´t be the Alternative, be the better Choice."
SIMPLE

R0H1TI have an Intel 8th gen ULV chip, which last got a (IGP) driver update well over a year back. If Intel can't force OEM updates, what chance does AMD have?

OEMS doesn't upgrade drivers unless some company which buys 20-40K pc's need it because of an issue.
When the company I work in need it they do it.

For consumer models there is never a customer with thousands of computers thus no reason to fix it.
We buy some consumer models for Lab purposes and if we have an issue we're pretty much screwed when it comes to support.

OEMS are definitely a big issue.

FordGT90ConceptDidn't say they don't but generally they only do if it is security related where there's a modicum of liability involved. Another case where I've seen BIOS updates pushed is if they're selling the same platform with new processors (e.g. Ivy Bridge support added to Sandy Bridge motherboards because they're selling the machine packaged with Ivy Bridge instead of Sandy Bridge).

There's also the point of you needing those updates. For instance, I have noticed that after a year or so after my video card hits the market, it rarely gets fixes anymore. Sure, Nvidia still puts out drivers every month, but the fixes are usually specific for a type of card or more exotic configurations. So about a year is when I stop paying attention unless I actually notice issues. What I'm trying to say is laptop manufacturers know exactly which card you are using and will only push drivers that actually do something for you.
Still, these drivers seem to be both in a poor state and abandoned ever since launch day. That is not only something that should be addressed, but something that shouldn't have been allowed to happen in the first place.
I'm pretty sure AMD had (not entirely unexpected) other priorities and are just trying to save face here. They can pretend aliens didn't let them distribute drivers for all I care, but they need to give users better drivers.

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

bugI'm guessing Omega drivers are no longer with us?

They faded into obscurity years and years ago. Alongside another driver tweaker group that was around at the same time.

Omega still exists but its more or less just a placeholder website that is either dead or the owner uses it as a news hub and just posts/links pc hardware related news

try searching for amd e250 gpu, something like that, c250

i cant remember the name, it was an old chipset for netbooks with amd gpu,i know it is old and crappy but still

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

FreedomEclipseThey faded into obscurity years and years ago. Alongside another driver tweaker group that was around at the same time.

Omega still exists but its more or less just a placeholder website that is either dead or the owner uses it as a news hub and just posts/links pc hardware related news

Omega were a pretty clear sign laptop and desktop drivers aren't really different.

And you probably mean NGO ;)

sixortry searching for amd e250 gpu, something like that, c250

i cant remember the name, it was an old chipset for netbooks with amd gpu,i know it is old and crappy but still

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

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

bugOmega were a pretty clear sign laptop and desktop drivers aren't really different.

And you probably mean NGO ;)

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

FordGT90ConceptBecause for decades, OEMs packaged their own drivers for their own machines. They strongly advise you to not get drivers directly from the manufacturer. Before Intel HD Audio became standard, it was common for AC'97 drivers direct from manufacturer to crackle and have other sound defects where sound drivers from the OEMs just worked despite being much older. A lot of the reason for this is that there is no standard for how PCBs are made. Physical features of chipsets, for example, may be unlinked entirely so drivers need to inform the operating system not to use those devices. Unless Intel and AMD adapt a policy of no modifications for OEMs, OEMs will have to continue to provide specialized drivers to customers. We can get by with blanket drivers for graphics cards, for example, because AIBs don't heavily modify integration like OEMs do for motherboards.


That would make the driver package huge and bloated. That translates to time and money (more costly to package and distribute).

Let's address the latter point first: no, it wouldn't. 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. Leaving a blank space for [Insert vendor modification here] in the driver really shouldn't cause meaningful bloat unless they for some reason decide to replicate a large amount of the original driver's functionality - which would be a terribly dumb thing to do, unless the OEM driver is bad enough to be discarded wholesale (which is an entirely different discussion from this). Also, isn't it rather obvious that the current method of doing this is far too time- and resource intensive, given that we're not seeing updates at all?

As for your former paragraph, we should really be well past this in 2018. 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? 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? Sure, it might pull a teeny-tiny amount of additional power, but likely not enough to ever matter. The only relevant issue here would be things people interact with - HID, audio and displays. If the driver switches your display output to a nonexistent Displayport output, that would be bad, but given how GPUs automatically detect connected displays, that really shouldn't be an issue. A more relevant problem would be adding a GPU-integrated audio device that the PC doesn't make use of, but given how easy it is to switch audio devices in W10 (and that any HDMI-equipped PC needs to have this option), again, this isn't a problem. PCs are inherently modular. Treating drivers as monolithic blocks is diametrically opposed to this, and really should be avoided as much as possible. Heck, the AMD GPU driver package lets you select/deselect a bunch of features. How hard would it be to implement a check against a database of devices for unsupported features?

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.

IceScreamerThis, with the lower battery life compared to competing Intel solutions, is the main reason I recommend against buying Ryzen laptops to my friends/family.
And that bullshit excuse is fishy, offering the generic drivers on site at least seems like a simple solution and my guess the OEMs are somehow stopping them. I mean they (AMD) do have some dumb choices but this is absurd.

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.

ValantarLet's address the latter point first: no, it wouldn't. 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. Leaving a blank space for [Insert vendor modification here] in the driver really shouldn't cause meaningful bloat unless they for some reason decide to replicate a large amount of the original driver's functionality - which would be a terribly dumb thing to do, unless the OEM driver is bad enough to be discarded wholesale (which is an entirely different discussion from this). Also, isn't it rather obvious that the current method of doing this is far too time- and resource intensive, given that we're not seeing updates at all?

As for your former paragraph, we should really be well past this in 2018. 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? 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? Sure, it might pull a teeny-tiny amount of additional power, but likely not enough to ever matter. The only relevant issue here would be things people interact with - HID, audio and displays. If the driver switches your display output to a nonexistent Displayport output, that would be bad, but given how GPUs automatically detect connected displays, that really shouldn't be an issue. A more relevant problem would be adding a GPU-integrated audio device that the PC doesn't make use of, but given how easy it is to switch audio devices in W10 (and that any HDMI-equipped PC needs to have this option), again, this isn't a problem. PCs are inherently modular. Treating drivers as monolithic blocks is diametrically opposed to this, and really should be avoided as much as possible. Heck, the AMD GPU driver package lets you select/deselect a bunch of features. How hard would it be to implement a check against a database of devices for unsupported features?

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.

CheeseballI've got the Acer Nitro 5 with the Ryzen 2700U so I know how it feels. This mobile driver issue is pretty bad.

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.

SetsunaFZerohmmm not sure if Intel is paying OEMs to stop development of AMD OEM drivers :rolleyes:

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

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

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.

FordGT90ConceptI think what is going on here is that the launch drivers were immature. OEMs generally don't provide any drivers outside of launch. The most they'll do is things like Intel Management Engine and BIOS upgrades to update microcode for security reasons. In other words, what OEMs did in regards to Ryzen were par for the course. AMD needs to pressure them to push out updates for Ryzen APUs because they need it and it sounds like that is what they're doing.

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.

It could be like my case

I have a Laptop with a APU in it and non of the drivers on AMDs sight will install at all. I had to rely on what’s available through the OEM or use windows update for drivers which is very annoying.

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