AMD Introduces Ryzen 8000G Series & Even New Ryzen 5000 Series CPUs

[Anux]

RADV is a community project, multiple times it has been mentioned that at least officially, AMD works on amdvlk, not radv

You are depending to much on what's being said than what's being done. That easily makes you the prime victim of marketing and propaganda. Fact is AMD is constantly helping on the non AMD provided drivers, just one example: https://www.phoronix.com/news/AMD-RA...eonSI-Extra-MD

How is one company that says: "we are only giving basic support but their product works" worse than a company that outright sells products that don't work and don't care to provide a solution?

I mean who cares you are free to buy or not whatever you want, but if you're blasting you're double standards in the internet you have to live with people criticizing you for it or thinking that that you are a blinded fanboy.

[Quackdoc]

You are depending to much on what's being said than what's being done. That easily makes you the prime victim of marketing and propaganda. Fact is AMD is constantly helping on the non AMD provided drivers, just one example: https://www.phoronix.com/news/AMD-RA...eonSI-Extra-MD

How is one company that says: "we are only giving basic support but their product works" worse than a company that outright sells products that don't work and don't care to provide a solution?

I mean who cares you are free to buy or not whatever you want, but if you're blasting you're double standards in the internet you have to live with people criticizing you for it or thinking that that you are a blinded fanboy.

im not sure why you linked this, as I explicitly said im talking about officially supported, I mentioned officially for a reason, because officially supported matters. especially to windows users. it would be nice if you read what you replied to

[skeevy420]

I am aware that there are technical reasons behind why they are limited to vega.

RADV is a community project, multiple times it has been mentioned that at least officially, AMD works on amdvlk, not radv, and while I am thankful for radv existing, My thoughts are based on the merit of something being officially supported or not. Like I said, I really would have rather had them just not really just not really a new APU, but the least they could have done was have been open about it. The vega devices in general are actually not that bad when speaking specifically about raw perf of them, you can easily enjoy a 900p gaming session in a lot of modern games like cyberpunk, cod, etc. and 1080p games for ones that are lighter weight, you can even play on higher settings.

I under stand the technicals behind these devices, I think they will be quite well performing apus all in all, and if they were supported, I actually currently run a ryzen 2600 inside of a crosshair ROG VIII here wifi, that I would love to put one of these into. However I can not support selling EOL'd devices as brand new with deceptive marketing like this. I understand perfectly well that this is a non-issue for me on linux, I cannot emphasize this is not an issue with the technical aspect of things for me personally. I will not buy them, because other people will get boned from this, and I cannot support this behavior. When you buy a new product, you, IMO rightfully expect a degree of support that these devices will not get. this is the issue I have with this.

Here's the thing, they're not technically EOL'd. AMD just isn't keeping feature parity between GPU generations so Vega and Polaris will still receive security and maintenance fixes, they just won't get AFMF and whatnot. There's basically a line in the sand between Vega and RDNA2 with RDNA1 being the bastard child line due to mesh shaders. Both Intel and NVIDIA have drawn lines in the sand, too, in regards to new and old graphics support.

Vulkan is same. IMHO, they've basically depreciated AMDVLK, Pro and regular, without actually saying it. Their AMDGPU-Pro driver even uses RADV for Vulkan. Well, they did say it for Polaris and Vega...but people have to go out of their way to use AMDVLK, old or new, Pro or open, whereas they just get RADV out of the box regardless of where they go or what hardware or software they use. AMD knows that and knows that nearly every Vulkan bug report they'll deal with will be for RADV.

It's not like AMD doesn't support RADV, either. On the first two pages of requests using the RADV tag there are at least three actual AMD devs submitting merge requests to RADV right now. Probably more, but I only recognized three by name as AMD employees and not Valve, RHEL, Igalia, or independent. On the first two pages the only one I'm not sure about is rhysperry111. I didn't realize how well I knew Mesa developer names until today.

I think that line in the sand with Zen 2/Vega is why they got the V2000A certified. Known hardware with known software and drivers. LTS hardware. Vega is nearly 8 years old now. How much more work do the drivers need?

[heliosh]

Which one could be more energy efficient for signal processing (FFT), i7-14700T (8+12C, 35W TDP) or Ryzen 7 8700G (8C, 65W TDP)

[Quackdoc]

Here's the thing, they're not technically EOL'd. AMD just isn't keeping feature parity between GPU generations so Vega and Polaris will still receive security and maintenance fixes, they just won't get AFMF and whatnot. There's basically a line in the sand between Vega and RDNA2 with RDNA1 being the bastard child line due to mesh shaders. Both Intel and NVIDIA have drawn lines in the sand, too, in regards to new and old graphics support.

the explicitly said only critical updates for bug fixes and functionality updates. This is a massive issue since games often require preformance tweaks from the driver side.

Vulkan is same. IMHO, they've basically depreciated AMDVLK, Pro and regular, without actually saying it. Their AMDGPU-Pro driver even uses RADV for Vulkan. Well, they did say it for Polaris and Vega...but people have to go out of their way to use AMDVLK, old or new, Pro or open, whereas they just get RADV out of the box regardless of where they go or what hardware or software they use. AMD knows that and knows that nearly every Vulkan bug report they'll deal with will be for RADV.

Im not sure where the idea of this came in, AMDVLK is still quite actively developed, RADV is likely defaulted to since it's the distro default for 90% of things and breaking that is unwanted behavior. but regardless windows users are stuck with the windows flavor amdvlk.

It's not like AMD doesn't support RADV, either. On the first two pages of requests using the RADV tag there are at least three actual AMD devs submitting merge requests to RADV right now. Probably more, but I only recognized three by name as AMD employees and not Valve, RHEL, Igalia, or independent. On the first two pages the only one I'm not sure about is rhysperry111. I didn't realize how well I knew Mesa developer names until today.

I realize this, this is explicitly why I said officially supported, and windows users can't use mesa drivers anyways since it's a moot point.

I think that line in the sand with Zen 2/Vega is why they got the V2000A certified. Known hardware with known software and drivers. LTS hardware. Vega is nearly 8 years old now. How much more work do the drivers need?

New games still come out and need per game fixes. so I would say it's not insignificant. This will also become an issue as more features come out in the future. for instance vulkan 1.3 core is designed to target GLES 3.1 so there is still a lot of potential vulkan can potentially tap into. New extensions will come, and some will be compatible with vega, and vega wont get it. New games will come out that need driver fixes, and vega wont get some.

[rhysperry111]

On the first two pages the only one I'm not sure about is rhysperry111. I didn't realize how well I knew Mesa developer names until today.

Just FYI: I'm not the mesa legend Rhys Perry.... I just happen to also be called Rhys Perry and love open source :P

[qarium]

> Good thing we have open source drivers for Linux eh?
True, what I'm wondering is why AMD is still maintaining their two separate Vulkan drivers instead of giving the official blessing to RADV and moving development resources there. It's already the de facto standard, for gaming at least. Compute people are probably using AMDGPU-PRO anyway. Why maintain a third, inferior driver? It's not free, and since they're dropping support for *current* GPUs from the main branch it clearly costs them quite a bit.

absolutly right... but some people are not happy with the RADV only route

one of them is Quackdox see here: https://www.phoronix.com/forums/foru...e3#post1434105

I need vulkan support. My usecase is to run MPV via TTY, It may be possible to migrate to a wayland compositor, but unless a really minimal one like weston, smithay based like cosmic, or wlroots based like sway support HDR, it will be a no go for me

if only some RADV dev could cover his usercase then any resistance against RADV only stradegy could vanish

[qarium]

im quite honestly baffled that AMD would stoop this low. Vega devices are on lifesupport, they no longer get per game fixes which are often times critcial to a semi decent experience, no longer benefit from general perf optimizations... and they have the absolute balls on them to advertise them for gaming... yeah Im no longer buying AMD products, and am going to reccomend my friends avoid them, I don't like what Nvidia is doing, hopefully intel can unfuck the gpu market

intel is a complete clusterfuck:

The benchmarks of Meteor Lake (Arc) graphics performance are relevant and interesting. However, this only matters if the program runs correctly. I think MSI is about to faceplant in public when they release a Steam Deck competitor and half the games the customer tries to play either run like garbage or outright crash. Intel's driver efforts towards gaming still seem to be getting individual popular games to run. Customers don't only play popular or new games. Unless the driver is in a better state than has been reported, selling a Meteor Lake handheld is likely to generate bad press for MSI and Intel both.
MSI is at least clear of the 'why didn't you cats install Steam OS on that thing?' question. Heh.

[qarium]

Sure, but they're still releasing the PRO and open variants separately, that is not free. Documentation is also not free to write. It costs them a non zero amount of money to release the open variant while they could keep it closed. They should be commended for the effort IMO, but if they wanted to make the very best driver for Linux they'd contribute to RADV instead, so IDK what to think of it.
They likely could use mesa / radv on windows if they wanted to, but then they'd be giving up some control, and would need to open some of their Windows driver code to comply with the GPL, and that'll never happen...

the code is MIT and not GPL ???...

[Anux]

Which one could be more energy efficient for signal processing (FFT), i7-14700T (8+12C, 35W TDP) or Ryzen 7 8700G (8C, 65W TDP)

That probably depends on the implementation/program you are using. Since FFT is a prime candidate for AVX 512 I bet the newest CPU with AVX 512 is the efficiency winner. But your program needs to support it. Search for benchmarks, else AMD CPUs are much more efficient than Intel in most workloads so it's a save bet I guess.