AMDK11

Ja również planuję aktualizację, ale tym razem do Zen6. Ciekawe, czy problem z 32 MB UEFI zostanie rozwiązany tak samo, jak brak pamięci BIOS na AM4(16MB). Widziałem już płyty główne z 64 MB UEFI i deklarowanym wsparciem Zen6. Mnie bootuje szybko, mimo że, zmieniłem obcje bootowania z tej najszybszej na pełniejszą.

Ostatnim komputerem stacjonarnym z procesorem Intel, jaki miałem, był i7 5820K. Nie mam odniesienia do 14 generacji Intela. Zazwyczaj pierwszy, wstępny(automatyczny) proces kalibracji pamięci RAM na Ryzen 9000 jest dość długi (czasami trzeba restartować komputer). Myślę że to kwestia stopnia kompatybilności RAM DDR5 z płytą główną(brak oficjalnego wsparcia modułów na liście BIOS UEFI). Ale po jego zakończeniu i samodzielnym ustawieniu reszty w BIOS-ie (mój ASUS z automatu utawia RAM na bezpieczne 4800MT, podczas gdy kontroler Zen5 ma nominalnie 5600MT), jest stabilnie jak skała, a system Windows 11 Pro ładuje się błyskawicznie z dysku NVMe.

Zastanawiałem się nad problemem dropów FPS na Zen5 (nie korzystałem z poprzednich generacji Zen, więc nie mam na ich temat zdania). Mam sugestię na nowy wątek: "Brak dropów FPS na Ryzen 9000! Co powinienem zrobić, które ustawienia zmienić, ewentualnie co zdup**yć, żeby spowodować dropy FPS? Pilnie proszę o pomoc!"

@j4z Podobno masz dropy na 9800X3D. To prawda?

@MarcoSimone Aż sprawdzę z ciekawości BF6. Jedynie gdzie nie mam takiej płynności(GPU) to na demo Gothic Remake. Przy wyłączonym m.in RT dalej był nisk FPS. Zluzowałem suwaki przy pewnych ustawieniach i jest około 70-80 FPS, ale dropów nieuświadczyłem.

Podkręcałeś?

Jak tylko będę miał okazję, kupię tą grę i sprawdzę Edycja: w celu uzupełnienia mojego konfigu, płyta główna i RTX 5070 pochodzą od ASUS-a. Zasilacz to Corsair ATX3.1 1000W, a oba złącza zasilania procesora są podłączone. Ostatnio grałem w Crysis Remaster 1 (ukończyłem), a teraz w Crysis Remaster 2. Szybkie ładowanie poziomów i 100% stabilności + wysoki FPS podczas gry na mapie, niezależnie od chaosu panującego na ekranie.

Na jakich ustawieniach procesora? Po OC, UV czy na defultowych? Ja mam 9600X na dwfult(80W) czyli nastawy fabryczne. Zero OC. Przy obniżonych napięciach(UV) względem fabrycznych w pewnych sytuacjach/scenariuszach też może być za małe napięcie(wcale bym się nie zdziwił).

Ach, te dropy, których nie doświadczam na moim R5 9600X(80W) + 32 GB (2 x 16 GB) RAM 5600MT + RTX 5070 + 2 TB NVMe PCI-Ex 4.0 (prędkość 6000-7000 MB/s, chłodzonym radiatorem z rurkami cieplnymi i wentylatorem) z jakiegoś dziwnego powodu Nie wiem. Może te dropy są od podkręcania lub UV? Mam ustawienia fabryczne i żadnych spadków, gram i testuję różne gry. Zawsze wysoki FPS w rozdzielczości 2560x1440 i, o dziwo, żadnych spadków. Jedyny raz, kiedy ich doświadczyłem, to w Train Driver 2, gdzie częśći mapy ładują się okresowo, a jednocześnie wcześniej przejechane są usuwane. Ale to tam normalne. Na przykład w MaSzynie 26 stycznia nie ma spadków na maksymalnych ustawieniach. To samo w ETS2. Mam dość dużą bibliotekę gier na Steamie.

NVL 8+16 Die TSMC N2 ~110+mm2 NVL 8+16 bLLC Die TSMC N2 ~150+mm2 Zen2 CCD: 2*4 Core 2*16 MB L3 TSMC N7 ~77 mm2 Zen3 CCD: 8 Core 32MB L3 TSMC N7 ~83 mm2 Zen4 CCD : 8 Core 32MB L3 TSMC N5 ~72 mm2 Zen5 CCD : 8 Core 32MB L3 TSMC N4 ~71 mm2 Zen6 CCD : 12 Core 48MB L3 TSMC N2 ~76 mm2(50% więcej dla rdzeni + około 30-40% miejsca poszło na rozbudowę logiki rdzeni(IPC)).

Zaprzestałem podkręcania po zakończeniu przygody z LGA2011v3 i procesorem i7 5820K. Z czasem tracił stabilność, mimo że osiągał maksymalną temperaturę 75-78°C pod obciążeniem benchmarkowym na Noctua NH-D15s z trzema wentylatorami. Wtedy jeszcze dało się ugrać 500-800+ MHz. Teraz dążenie do 5% jest moim zdaniem bezcelowe, ponieważ obniża żywotność systemu, a jednocześnie powoduje nieproporcjonalnie wysoki pobór mocy i wysokie temperatury w strukturze krzemu. Wystarczy że zostanie uruchomiony AVX512, a niestabilność, zawieszanie się lub restarty są możliwe. Teraz skupiam się na absolutnej stabilności i żywotności. R5 9600X i tak jest kilka razy szybszy niż 5820K, a moja(dawna) psychologiczna bariera 4 GHz została już dawno przekroczona 😉

Też w to wątpię. Wysoki wynik SC(SMT) został już wyjaśniony. Powyższy wynik to błąd testu CB podczas przełączania wątków/rdzeni na RaptorLake-S. Edit: Zen2 CCD: 2*4 Core 2*16 MB L3 TSMC N7 ~77 mm2 Zen3 CCD: 8 Core 32MB L3 TSMC N7 ~83 mm2 Zen4 CCD : 8 Core 32MB L3 TSMC N5 ~72 mm2 Zen5 CCD : 8 Core 32MB L3 TSMC N4 ~71 mm2 Zen6 CCD : 12 Core 48MB L3 TSMC N2 ~76 mm2

Podobno może być to wynik QS/ES Zen6. https://forums-anandtech-com.translate.goog/threads/cinebench-2026.2633409/page-5?_x_tr_sl=en&_x_tr_tl=pl&_x_tr_hl=pl&_x_tr_pto=sc Zen5(R5 9600X) + DDR5 2x16GB 5600MT ~5.4GHz ST 525p SC(SMT) 719p Oczywiście wyższe modele Zen5 np R9 9950X mają wyższe taktowanie ST/SC ~5.7GHz(+5.5%). ?Zen6 QS/ES? SC(SMT) 1072p(+49%!!!) Na forum AnandTech dla ST obliczają ~800p(+52%), jeśli zachować proporcje ST do SC(SMT) Zen5. Edit: Jeśli to nie NovaLake z SMT(HT) i jeśli to nie Zen5 na ciekłym azocie, a faktycznie QS/ES Zen6 to wynik jest niesamowity. Mike Clark(Szczególnie ostatnie zdanie):

Ma to do tego, że AMD nazywa współbieżną wielowątkowość skrótem używanym w branży od momentu powstania koncepcji SMT. To właśnie Intel wymyślił swoją marketingową nazwę na swoją implementację SMT. I to, że Intel wcale nie był pierwszy.

AMD po prostu nie nadało swojej implementacji SMT własnej nazwy marketingowej. Więc czy to Intel HHT, czy AMD SMT, oba są implementacjami SMT (Simultaneous Multithreading). Pamiętam, że w czasach Athlona 64 panowało zamieszanie, ponieważ Intel miał Hyper Threading, a AMD Hyper Transport (linie komunikacyjne między rdzeniami i z chipsetem) i niektórzy uważali, że obie technologie to to samo.

Chyba że będą to wątki a nie ilość rdzeni XD

@Kyle HT to Intelowska, marketingowa nazwa SMT.

Zobaczysz że HT wróci. LionCove to nowa baza i całkowicie inne podejście dla Intela więc nie ryzykował wdrażania HT za pierwszym podejściem. Lip Bu Tan powiedział jasno że odejście od HT(SMT) było błędem i zamierza przywrócić.

@janek25 Ponieważ GoldenCove/RaptorCove ma współdzielony (zunifikowany) harmonogram i porty wykonawcze dla ALU i FP (3xALU/FP + 2ALU). Zen4 ma osobny harmonogram i porty wykonawcze dla ALU i osobny dla FP. Intel zawsze (do czasu RedwoodCove) stosował implementację zunifikowanego harmonogramu ALU/FP, a Zen zawsze stosował dedykowane harmonogramy. LionCove jest pierwszą mikroarchitekturą w historii Intela, która wprowadza dedykowane harmonogramy dla ALU i osobny dla FP. Uważam, że jest to istotne zarówno w obciążeniach mieszanych, jak i SMT. I główny powód dla którego nie ma HT w LionCove a wróci prędzej czy później Tym bardziej że jednostki FP na tych samych portach wykonawczych co jednostki ALU pozwalają na użycie tylko FP lub tylko ALU w każdym cyklu. Więc nic zaskakującego w tym że wyłączenie SMT(HT) na RaptorCove daje więcej niż wyłączenie SMT na Zen. Zen5 ma jeszcze więcej zasobów(względem Zen4) z których pożytek robi SMT. EDIT: Średnia wzrostu IPC dla SMT(Zysk z włączonego SMT względem wyłączonego SMT): Zen4 +13% Zen5 +18%

Jeśli już, to 9600X (Zen5), bo 7500f to Zen4 W grach bez x3D nie różnią się zbytnio, ponieważ wąskim gardłem jest konstrukcja chipletów (R 9000 i U 200). Po prostu piszę to, czego dowiedziałem się z analizy obu mikroarchitektur (Zen5 i LionCove)

@Kartofel Owszem. Uprościłem i trochę ogólnikowo napisałem ale mniej więcej sens zachowany, nie zagłębiając się zbytnio w szczegóły.

Up@ Nie do końca. Widać, jak Zen5, dzięki SMT, wyciska z szerokości rdzenia tyle, ile się da. LionCove, z powodu braku SMT, nie wyciska z rdzenia tyle, ile mógłby. Zen5 ma 2 klastry dekoderów (2x 4-Wide (łącznie 8-Wide, głównie dla SMT)), a w ST, poza rzadkimi przypadkami, może działać tylko na jednym klastrze dekoderów (4-Wide - tyle ile ma Zen4(4-Wide)). Jest to świadomy wybór AMD(Złożoność logiki(llość tranzystorów) a także energooszczędność), ponieważ głównym źródłem instrukcji nowoczesnej architektury x86 (zwłaszcza Zen) jest pamięć podręczna mikroinstrukcji(op cache 12-Wide dla ST), a dekoder pełni rolę uzupełniającą i wspomagającą. Zen5, jak podkreśla AMD, stanowi nowy fundament dla przyszłych rozwiązań (Zen6, Zen7 itd.). Zen6 w dużej mierze (spekuluje się) wykorzystuje dekodery 2x4-Wide dla ST i op cache 16-Wide. Zen5 to 6ALU + 4AGU(Zen4 4ALU + 3AGU) więc SMT ma większe pole do popisu. EDIT: Aby w pełni zoptymalizować poszerzony i od nowa zaprojektowany Zen5, AMD poszło na kompromis i podzieliło projekt na dwa etapy: Zen5(duża rozbudowa z częściową optymalizacją) i Zen6(częściowa rozbudowa z dużą optymalizacją). Na przykład, niektóre instrukcje (w tym wektorowe FP) przeszły z jednocyklowego na dwucyklowe opóźnienie w porównaniu z Zen4. AMD przypisuje to dużej złożoności, którą musiano zredukować w nowym rdzeniu Zen5. Zen6 ma to naprawić. W Zen5 skupiono się jednak przede wszystkim na agresywnej optymalizacji pamięci podręcznych L1, L2 i L3 z bardzo niskimi opóźnieniami i ogromną przepustowością, a być może przede wszystkim na ciągłym dostarczaniu strumienia instrukcji, co oznacza nowy, stosunkowo potężny predyktor (m.in BPU + BTB) który przewiduje dwie na przód, bardzo długie i skomplikowane wzorce rozgałęzień. LionCove przewiduje tylko 1, dość krótkie i mniej złożone wzorce rozgałęzień co jest częściowo powodem kiepskiej przepustowości L3 i musem implementacji dużego L2 oraz awaryjnego L1.5-D. Wygląda na to, że priorytetem Intela w LionCove była rozbudowa rdzenia (pojedynczy dekoder 8-Wide) i buforów. Predyktorem i pamięcią podręczną zajmiemy się innym razem. LionCove zmaga się z większą liczbą pustych cykli podczas oczekiwania na instrukcje (spowodowanych m.in. BPU + pamięcią podręczną), dlatego zastosowano w nim 192 KB awaryjnej pamięci podręcznej L1.5-D.

Właśnie testowałem nowego Cinebench 2026: R5 9600X (ST ~5.4 GHz) RAM 5600MT 2x16GB(32GB) Single Thread: 525p Single Core (SMT): 719p (+37%)! AMD podkreśla że SMT w Zen4 i Zen5 zajmuje 5% logiki(tranzystorów) rdzenia U9 285K (ST ~5.7 GHz) Single Thread: 602p (Zen5 SMT +19%!)(LionCove ST +14.6% względem Zen5 ST(SMT OFF)) W CB 26 rdzeń Zen5 ma o ponad 20% wyższy IPC niż LionCove

Spekulacja jakie ulepszenia może wprowadzić Zen6 z forum Anandtech: https://forums-anandtech-com.translate.goog/threads/zen-6-speculation-thread.2619444/page-322?_x_tr_sl=en&_x_tr_tl=pl&_x_tr_hl=pl&_x_tr_pto=sc Wygląda na to że Zen6 powraca do rozproszonego harmonogramu Integer(podobnego do Zen4) zamiast zunifikowanego(dla 6 ALU) w Zen5.