AMD's Raven Ridge Botchy Linux Support Appears Worse With Some Motherboards/BIOS

[starshipeleven]

That might be so, but still, I doubt I can force the APU over the 25W cTDP by just drivers ... at least not long term ... however the benchmarks indicate that it is not just a short-term increase .... Also the same has no effect on the 2700u ... that one seems to regress ... but that might be something else as those are different laptops ...

but 30% performance is a LOT in a mobile chip ...

Check temperatures instead of speculating. If the TDP increases you will see an obvious temperature increase.

CPU/GPU-Z and speccy can provide a thermal reading of the internal sensors so you can see for yourself.

And note that the issue here isn't just CPU/GPU but also VRM. These things are the power circuitry of the laptop and are never cooled (even passively) nor placed in decent spots, so even if technically the CPU/GPU could hold the higher heat the VRMs will be loaded more and will eventually overheat and burn the board, or just stress it until something nearby breaks.

this did not work for me I guess because of the display panel, but I am really not sure

Wildly unlikely, all modern laptops use screens connecteed over eDP (embedded displayport) and they are pretty much the same.

It's more likely that your laptop has additional restrictions or bugs in the BIOS that prevent that change.

[haplo602]

Check temperatures instead of speculating. If the TDP increases you will see an obvious temperature increase.

CPU/GPU-Z and speccy can provide a thermal reading of the internal sensors so you can see for yourself.

And note that the issue here isn't just CPU/GPU but also VRM. These things are the power circuitry of the laptop and are never cooled (even passively) nor placed in decent spots, so even if technically the CPU/GPU could hold the higher heat the VRMs will be loaded more and will eventually overheat and burn the board, or just stress it until something nearby breaks.

Wildly unlikely, all modern laptops use screens connecteed over eDP (embedded displayport) and they are pretty much the same.

It's more likely that your laptop has additional restrictions or bugs in the BIOS that prevent that change.

The guy that was able to install them has the SAME laptop ... identical model ... so nope ... windows tells me that the driver package does not support my version of windows, which is quite funny ... There's a reddit thread on this somewhere ...

[starshipeleven]

The guy that was able to install them has the SAME laptop ... identical model ... so nope ... windows tells me that the driver package does not support my version of windows, which is quite funny ... There's a reddit thread on this somewhere ...

I would have said UEFI bugs, but if it's Windows that blocks installation then it's weird. Did you try installing manually? You won't get the utility software, but the driver itself should get loaded.
follow this http://www.howto-connect.com/manuall...er-windows-10/ and tell it to look in the folder you extracted the AMD driver in (should be C:\AMD or C:\Radeon or something like that)

[pal666]

Sorry, but Linux doesn't have 85% of the smartphone business, period.

sorry, but it does have 85% of smartphone market share, period
in what alternative reality do you live? under jobs' reality distortion field?
https://www.statista.com/statistics/...ating-systems/
and there are other linux smartphone oses besides android
http://communities-dominate.blogs.co...-as-alway.html
he doesn't do separate tables by os now, but windows is 0.1% or so, so you just substract 14% of apple from 100% and you get linux share
or with available full stats for 2017 http://communities-dominate.blogs.co...-pointst-.html

And for Apple watchers, at one point Apple did 20% of all smartphones sold. The last three years? 16%, 15% and now 14%. I think we see the trend, eh?

And obviously, it means that currently iOS only sells 14% of all new smartphones, constantly dropping in share, as Android is at 86% of new sales.

[pal666]

GNU/Linux is, like, whole system created specifically for hacking and development.

but presumably not for development of windows drivers

[Hi-Angel]

but presumably not for development of windows drivers

Well, given we're talking about cross-platform drivers, Windows is only needed for testing/debugging the Windows-specific parts.

[haplo602]

I would have said UEFI bugs, but if it's Windows that blocks installation then it's weird. Did you try installing manually? You won't get the utility software, but the driver itself should get loaded.
follow this http://www.howto-connect.com/manuall...er-windows-10/ and tell it to look in the folder you extracted the AMD driver in (should be C:\AMD or C:\Radeon or something like that)

Yes I tried ... I've done about anything you can think of short of coding my own driver .... but I think the topic is a bit derailed with a Windows problem :-)

Still waiting for AMD to release a Ryzen mobile driver ... the desktop APU driver appeared days after release, the mobile is still MIA ... I wonder WHY ... exclusivity deals ?

[pal666]

Well, given we're talking about cross-platform drivers, Windows is only needed for testing/debugging the Windows-specific parts.

we a talking about windows driver which was designed to be easily ported to linux. windows-specific parts are 99% of budget

[bridgman]

Still waiting for AMD to release a Ryzen mobile driver ... the desktop APU driver appeared days after release, the mobile is still MIA ... I wonder WHY ... exclusivity deals ?

The OEMs generally don't want us to release a mobile driver - their preference is for us to work with them on any drivers that run on their hardware. It gets murky though when they also don't want to test a Linux driver and don't want us releasing drivers that they haven't tested.

Add-in boards are a different story - we develop a reference design and OEMs generally stick to it with the exception of things like power/clocks/cooling/connectors and VBIOS tables cover most of that - we don't normally need board-specific code outside of the VBIOS.

[haplo602]

The OEMs generally don't want us to release a mobile driver - their preference is for us to work with them on any drivers that run on their hardware. It gets murky though when they also don't want to test a Linux driver and don't want us releasing drivers that they haven't tested.

Add-in boards are a different story - we develop a reference design and OEMs generally stick to it with the exception of things like power/clocks/cooling/connectors and VBIOS tables cover most of that - we don't normally need board-specific code outside of the VBIOS.

This is an APU ... it does (or should) not matter that it is a laptop part, there is no difference in that regard to a desktop APU ... so the missing drivers are somewhat bugging me ...