Originally posted by skeevy420
View Post
-
Depends on how you look at it and what your target goal is. For example, take gaming at 1080p to 2K. At most we need an 8c16t and a sub-$250 GPU for pretty good results and most can get away with a 4c8t processor for that task. Everything in that range has been getting more and more efficient every year. 2K and under gaming and office systems -- those get less hungry every year and can be made into smaller and smaller form factors. All that will especially be true once the AMD 4000 and 5000 series CPUs and APUs are released on the CPU side.Originally posted by alex79 View Post
On workstations and high end gear: every generation has increased core count at the cost of keeping power usage the same as the previous generation. Someone gaming over 2K, yeah, they need stupid-large GPUs that consume lots of power to use equivalent settings. Nvidia has reached their limit on efficiency so now they're releasing really-stupid-large GPUs that need their own power plants to operate to push lots of flash at 4K.
I don't expect Big Navi/Navi 2/WTF Ever to be any different. I predict that the 1080p/2K GPUs will be more efficient while the 4K+ GPUs, while technically more efficient, will still be stupid-large power suckers.Leave a comment:
-
Electricity isn't getting cheaper, wages aren't going up but PC's are getting more power hungry every year, need more physical space and need constant upgrades if you change 1 component. This sucks.Leave a comment:
-
Thanks for your post!Originally posted by bridgman View Post
Yes, the proprietary driver supports 20.04 - with version 20.30 it was said Radeon Software for Linux for Ubuntu 20.04.1 and RSFL for 18.04.4 - short before 18.4.5 was released with 20.04-Focal-HWE stack. So after that update - Radeon Software for Linux will no longer work - or maybe with luck?
So saying something about kernel versions supported (or other important components) may be a good thing - but those are aimed at LTS/SLE/RHEL distributions and there may even problems with STS versions.
Now the question is if one would ride mainline kernel - saying always starting with x.y.3, would it be reasonable or even possible to use a proprietary driver? I don't think so - but I may be wrong.
I will buy a new AMD system `soon' {directly after buying a system starting planning phase ... just for redundancy} - but it may be more than 2 years from now to see a difference - so Navi 3 - maybe an APU with that 5 nm die shrink - may be a good fit (if such APU are there: DP 2.0, 4k and 8k optimized
).
But even if I would want to get Navi 2 soon, I would use Groovy (20.10) but would buy Navi 2 when 1st distro with initial support gets available
to boot with (which may be 21.04 - which I would install one month before release) and would ride mainline kernel and Mesa to get support in shape.
Focal (20.04) was a really bad desktop system with components even older than before concerning former LTS releases. 19.10 had kernel 5.3 - 20.04 5.4 (and many big backports - reasonable for servers but never a good thing for the desktop) - application stack not really better in that respect (not to speak of the interesting packaging problems: deleting no longer used packages resulted in advertising to drop core packages ... nice ... which was fixed a few weeks after release - maybe I am installing too much
).
The first Focal version usable for me will be 20.04.2 - with a lot of PPAs - and maybe as KDE Neon to have a current and stable KDE stack and using it as reference - but working on current STS.
I thing that the proprietary driver is good for workstations (with certifictions being the big difference) which tend to have older components than the desktop and using tested and proved distributions (e.g. used for CAD/CAE - I worked here as Unix specialist for 5 years - and all people were happy when AMD won and not Nvidia ... clear sign of being a Unix guy). But those well tested distros are from my point of view outdated - even from the point of a researcher ...
And this is not to blame AMD - it is great that they support the community with code and information which enables the free stack to be better than the proprietary driver. Would be easy to stop that when no longer playing fair (examples exist for that behavior) - so this is something which shows that Linux users buy AMD components for a very good reason.
We used in the 2nd half of 1990ies Debian Unstable without problems (testing updates on one machine and only updating all when it was working - with about 2 disruptive updates per year - a colleague was really good at stopping those to get installed on all systems) in an astrophysical research institute.
I don't think the pace slowed down concerning SW - it is only the HW which is really slowly changing (8k screens ... with first versions shown before 4k got cheap in 2015 - now more than 5 years later not even announcements ... that's impressive; CPUs are not remarkable on the desktop about speed - but USB and SSDs are - but CPUs show nice development - but no wow effect here: i.e.factor 2+, not just 10%+ which is nice but no game changer).
Roadmaps - well, in former times CPU was king - the most decisive component - thus the roadmaps of CPUs was what people want to see - and star performance diagrams of Intel - Alpha - ... CPUs concerning the 1990ies. Graphics card got important when (I don't know why; maybe you can explain it) roadmaps were NOT introduced. That is true. Who cared about accelerators when 3dfx were number 1? Private computers had typically Nvidia - was fun till the proprietary driver bites.
As stated above in astrophysics working on 2k x 2k CCD frames we used Matrox cards. It worked.
And now - when resolution is important - framerates (mostly gamers, videos are no problem even with 4k on current HW - this is not Polaris - and I would hesitate to open it for Vega ...) - and color depth (high color, true color, ...). So DP version is decisive.
So it would be nice to know "AMD will use DP 2.0 from ... onward for the entire line of GPUs and APUs" - this would be a wow effect of information, wouldn't it.
And thus I am frustrated or even angry when reading "DP - yes" even on pages of one of the most import graphics vendors - AMD.
You remarked that my term "the masses" is not what people use - but maybe you can explain who think "DP - yes" is information ...
And I would not dare to use any term here but say that speaking with students I explain that HDMI is for TV and not for professional usage as bearing a lot of shortcoming ... and DP is the professional one - starting to explain the importance of the versions and what results from a given transfer rate.
So my point stays valid (at least for me) - why were real roadmaps stopped (like a general agreement) on CPUs and why were roadmaps not introduced when the graphics card was no longer a dump device like an interface card for serial port but of similar weight like the CPU?
And where can one find information about DP port versions directly on release date?
And is there a place were AMD reveals which functionality is implemented in the open stack right now and which components are missing - and maybe even giving a deadline (e.g. computing stack for Navi should be ready when 1st computing card is released ... so that may be a hint of an internal roadmap - and I am sure AMD has one)?
To give an example - I want to connect an 8k screen with my Navi 10 as soon as it gets available.
On Phoronix (https://www.phoronix.com/scan.php?pa...r-In-Mesa-20.2) it was said about Mesa 20.2 "With Navi 1, the display DCC support was flipped on for only Navi 12 and Navi 14". So why is Navi 10 missing (the flagship product) and what are the implications. If 8k screens were there right now - would Navi 10 with Linux 5.7.17 and Mesa 20.1.5 be able to reach 8k@60Hz with one cable?
[Hoping for a clear: "Yes!" here - while for DP - yes ... well ... I think you got it]
Similar concerning the configuration or even tweaking tool. Is AMD supporting ADRICONF (I have not used it yet - but this is the official Mesa tool if I am not wrong here - i.e. would it provide similar functionality to the former AMD Catalyst Control Center - and if not, could AMD help in that respect)?
In the 1990ies everyone new what the HW was capable of ... and today information about that is hard to get - and as SW is evolving to get all functionality in place (lasting more than a year after release of that HW), there is a lot to wish for.
Thus stressing the need of roadmaps to plan, thus asking to have a place to show the current supported HW features (concerning DP/DSC/8k it would not be Mesa but the kernel side - amdgpu - or even both ...?) to keep tracking of what is already done and also full information in release date to know the deployment possibilities of that HW. Maybe also relevant for Linux Foundation?
Therefore hoping for more AMD developers improving the functionality of the free stack faster than it is today.
So I am happy with current Navi 10 with an 31.5" screen with 4k - but I wish for knowing before buying a card that it works - and maybe this is up to try and error - as the screens are simulated - but not tested as they had not been available when the card was disgned. So maybe asking to much ... but maybe you can even shed light on that question - at least in a more general way.
Thanks for your engagement!Leave a comment:
-
We package two versions of the graphics stack - one using Mesa for OpenGL and one using the proprietary OpenGL WS driver. Right now the newest consumer and LTS versions of Ubuntu are the same (20.04) so as long as you don't update to 20.10 the moment it comes out you should be OK for Navi21 launch.
The packaged driver userspace can also be installed on top of the distro's built in kernel or on top of a newer kernel packaged by the distro maintainers, although we need to fix up the install instructions to make that more clear.
My understanding is that 20.10 will ship with the 5.8 kernel, for what it's worth.
I know CPUs have historically had a fair amount of advance visibility into the roadmap but I don't ever remember seeing that in the GPU market. Did I miss something ?Leave a comment:
Leave a comment: