Intel Raptor Lake / Meteor Lake - 14 generacja

[tomcug 4598]

Twoje teoretyzowanie mało mnie interesuje (tak, ja wiem, że PresentMon to wszystko podaje), programowo nie zmierzysz rzeczywistego momentu wyświetlania kolejnych klatek na ekranie. Pisałem wcześniej, że szczególnie w testach CPU wychodziły po prostu głupoty, jeśli chodzi o rzeczywistością płynność vs 1% low. Nie chcesz tego przyjąć do wiadomości, nie musisz

6 minut temu, SebastianFM napisał:

Porównywałem uzyskany przeze mnie wynik i jest taki jak w CapFrameX, FrameView i MSI Afterburner.

Trudno, żeby nie był

Edytowane 25 Czerwca przez tomcug

[SebastianFM 2244]

 

10 minut temu, tomcug napisał:

Twoje teoretyzowanie mało mnie interesuje

W mojej ostatniej odpowiedzi nie ma żadnego teoretyzowania, nie wymyślaj, to już się nudne robi. 🙂

10 minut temu, tomcug napisał:

programowo nie zmierzysz rzeczywistego momentu wyświetlania kolejnych klatek na ekranie.

Oczywiście, że się da. Ty udajesz najmądrzejszego a nie masz o tym pojęcia. FrameView dostaje te dane ze sterownika NVIDIA. 😁 Nawet korzystając z API dostępnego w Windows można uzyskać dokładną informację o czasie wyświetlenia danej klatki. To też według ciebie tylko teoria? 😉

Edytowane 25 Czerwca przez SebastianFM

[tomcug 4598]

1 godzinę temu, SebastianFM napisał:

Oczywiście, że się da. Ty udajesz najmądrzejszego a nie masz o tym pojęcia. FrameView dostaje te dane ze sterownika NVIDIA. 😁 Nawet korzystając z API dostępnego w Windows można uzyskać dokładną informację o czasie wyświetlenia danej klatki. To też według ciebie tylko teoria? 😉

Przecież to jest też programowy pomiar, tak samo, jak wszystko, co PresentMon "wyciąga" z ETW, czyli ma tyle samo wspólnego, z tym, co rzeczywiście widać na ekranie. Powtarzam, ja różne metryki typu x% low, itd., przerabiałem na ogromnej liczbie różnych konfiguracji, i one zwyczajnie nie miały przełożenia na to, co rzeczywiście widać na ekranie. Pierwszy przykład z brzegu to Battlefield, gdzie im mniej rdzeni miał procesor, tym bardziej "poszarpany" był wykres frametime i tym gorsze wychodziło 1% low względem średniego FPS. Tyle, że nawet na czterordzeniowym procu ustawionym tak, żeby w minimalnym FPS było 60, z 1% wyraźnie poniżej 60 FPS, wizualnie było masełko nieodróżnialne od np. ośmiu rdzeni przy tym samym FPS, z 1% low znacznie bliższym minimalnego FPS. Podobnych przykładów (także w drugą stronę) miałem na pęczki, zanim nie zrezygnowałem z percentyli i innych metryk bezpośrednio bazujących na pomiarach frametime. Ty możesz wierzyć w programowy pomiar, mnie to nie przeszkadza, ale swoje zdanie mam i go nie zmienię. A to, że taki czy inny portal/kanał YT korzysta z x% low, niczego nie dowodzi, bo większość z nich nawet, jak ma na wykresie ewidentny bambol, gdzie gorsza konfiguracja wypada lepiej, choć nie może, to i tak tego nawet nie zauważy, więc...

Edytowane 25 Czerwca przez tomcug

[Minciu 5760]

9 godzin temu, tomcug napisał:

Jak nie wiesz o nieprecyzyjnym pomiarze frametime metodą programową, to nie mamy o czym w ogóle zaczynać dyskusji

Tak z ciekawości, jeżeli mierzymy tak samo nieprecyzyjnie 1% w jakiejś danej grupie sprzęcików i powtarzalnie 1% leży na pysku w garstce produktów, to czy błąd związany z programowym pomiarem, jest na pewno o kant tyłka rozbić?  

[tomcug 4598]

47 minut temu, Minciu napisał:

jeżeli mierzymy tak samo nieprecyzyjnie 1% w jakiejś danej grupie sprzęcików

Problem w tym, że nie Bo czasem nawet drobna różnica w platformie wysadza pomiar frametime w kosmos, także one nie są tak samo nieprecyzyjne dla różnych konfiguracji. I tutaj jeden z najświeższych przykładów, pomiary w Dying Light 2, notabene za pomocą FrameView (choć ta informacja nie ma istotnego znaczenia). Test w 100% na limicie karty, więc niby to GPU "dyktuje" frametime. Jedna platforma z 13900K, druga z 14900K. Efekt? Sporo wyższe x% low na 13. generacji Wizualnie oczywiście absolutnie żadnych problemów z płynnością na obu platformach i zero różnicy optycznie. Takie same zależności dla innych par 13. i 14. generacji, np. 13500 leje równo 14600K w percentylach w tym scenariuszu testowym.

XD

Edytowane 25 Czerwca przez tomcug

[sideband 9221]

Sama zmiana buildu windy ma wpływ co wypluwa presentmon i sama wersja presentmon-a.

Presentmon strzela podobne bambole co Fraps tylko potrafi ogarnąć pomiary na niskopoziomych API.

[Phoenix. 12258]

A ja zapytam czy realnie jest ktos w stanie golym okiem zauwazyc 0,1% LOW no nie Takze ten pomiar ma zerowa wartosc ale juz LOW fps nie trudno zuwazyc.

[SebastianFM 2244]

2 godziny temu, tomcug napisał:

Przecież to jest też programowy pomiar, tak samo, jak wszystko, co PresentMon "wyciąga" z ETW, czyli ma tyle samo wspólnego, z tym, co rzeczywiście widać na ekranie.

Ma 100% wspólnego z tym, co widać na ekranie, po to właśnie powstało to raportowanie zdarzeń. Jak ty sprawdzasz ilość wyświetlonych FPS? Przecież też programowo. 🙂

Dodam jeszcze, że w przypadku GPU istnieje mechanizm, który pozwala w prosty na uzyskanie informacji o zakończeniu wykonywania każdego etapu przez GPU, również wyświetlania danego bufora. W D3D12 do tego służy Fence. Jest to używane do synchronizacji, żeby np. gra mogła rozpocząć przygotowywanie kolejnej klatki. Te zdarzenia są raportowane z bardzo dużą dokładnością, bez opóźnień, żeby nie zmniejszać wydajności.

@Phoenix., jeżeli w grze będziesz miał przycięcia np. co 10 sekund trwające 0,1 sekundy to przecież je zauważysz a właśnie w takiej sytuacji 0,1% Low FPS będzie wynosiło 10.

Edytowane 25 Czerwca przez SebastianFM

[Phoenix. 12258]

No ale nigdy nie mialem i trudno dzis o to Cala ta gadka to takie pierdololo kto ma dluzszego na sile i kto wybierze konkretne program/gre zeby potwierdzic swoja starosc

Bo to juz naprawde takie czepianie sie na sile i mega to nudne to jest

Edytowane 25 Czerwca przez Phoenix.

[sideband 9221]

Zacznijmy od tego, że jest mega ciężko uzyskać dobrą powtarzalność na 0.1% zakładając, że pomiar jest prawidłowy.

Trzeba mieć przygotowane krótką miejscówką z idealnym przejściem lub statyczne miejsce Jakakolwiek zmienia podczas przejścia może przekłamać wyniki bardziej istotna jest średnia wydajność z frametime, która przekłada się co rzeczywiście widzisz na monitorze   Nawet bez dużych skoków zmiany ciągle szybkie zmiany frametime przekładają się gorsze odczucie płynności.

Każdy jest w różnym stopniu czuły na zmiany frametime i to trzeba brać pod uwagę pomijać suchy wynik.

[SebastianFM 2244]

1 minutę temu, sideband napisał:

Zacznijmy od tego, że jest mega ciężko uzyskać dobrą powtarzalność na 0.1% zakładając, że pomiar jest prawidłowy.

To akurat logiczne, skoro nawet przy pomiarze trwającym 60 sekund przy średnim FPS wynoszącym 100 wynik zostanie obliczony tylko z sześciu najdłużej trwających klatek.

Mi udało się uzyskać dużą powtarzalność 1% Low FPS w SotTR jak sprawdzałem wyłączone HT vs włączone HT. Po prostu uruchamiałem wbudowany benchmark i zawsze w tym samym momencie rozpoczynałem rejestrowanie czasów klatek.

[sideband 9221]

17 godzin temu, PiPoLiNiO napisał:

@sideband Ty masz dziwną tendencje do nie odpowiadania na pytanie, tylko tworzenie całej pobocznej historii. W temacie o ram pytam o poradę z napięciami, Ty odpisujesz bardzo inteligentnie że mam sobie kupić inny ram i inną płytę. Tu pytam co Ci konkretnie nie działało, Ty się rozpisujesz na X zdań, ale dalej nie wiadomo o co Ci chodzi.

Pytam ponownie, w czym DOKŁADNIE i KONKRETNIE rdzenie E przeszkadzają Ci w Black Mesa? Masz 200-300 fps zamiast 600 czy co? 

Bo ja nigdy nie wyłączyłem rdzeni E i nigdy nie miałem problemu z Black Messa, a klatki lecą w inną galaktyke.

Taka galaktyka, że nie dawno grę wrzucono na DXVK by poprawić wydajność od strony CPU🤣

Takie właśnie masz pojęcie jakie są spadki wydajności w tej grze.

[PiPoLiNiO 1291]

Dla mnie to Ty jesteś kolejny człowiek teoria. Pokazujesz to w kolejnym już temacie. Rzucasz jakimiś ogólnikami, odpowiadasz na około. 3 doba mija, ja dalej nie wiem jakie miałeś problemy. 

Ja Ci pisze ze mam stałe 280-200 fps, a Ty na to, że grę gdzieś wrzucono do poprawy więc ja się nie znam. 

Ja pisze, że 14 gen się sypie jak łupież i wszyscy o tym piszą, to Ty, że jestem złym operatorem. 

Ja pytam o poradę dotyczącą napięć bo twierdzisz, że się nie znam, Ty na to żebym kupił inną płytę i ram. 

Oszukałeś przeznaczenie, powinieneś być politykiem

[Assassin 1179]

A tak robiąc mały krok do tyłu w tej dyskusji: twierdzicie, że te problemy z rdzeniami E, poza obserwacjami organoleptycznymi, da się wychwycić zwykłym programowym pomiarem min fps? Bo to by był jakiś konkret.

[Wu70 4127]

7 godzin temu, sideband napisał:

Zacznijmy od tego, że jest mega ciężko uzyskać dobrą powtarzalność na 0.1% zakładając, że pomiar jest prawidłowy.

Trzeba mieć przygotowane krótką miejscówką z idealnym przejściem lub statyczne miejsce Jakakolwiek zmienia podczas przejścia może przekłamać wyniki

Powtarzalność na 1% i 0.1% nie jest trudna, wystarczy mieć dużo danych a nie uprawiać wróżbiarstwo z trzech klatek. 

Jak testowałem P i E to miałem powtarzalne wyniki w ...meczach online Warzone  Podobna taktyka na mecz ale mimo wszystko przebiegi nie były 1:1 takie same.

[tomcug 4598]

8 godzin temu, SebastianFM napisał:

Ma 100% wspólnego z tym, co widać na ekranie, po to właśnie powstało to raportowanie zdarzeń. Jak ty sprawdzasz ilość wyświetlonych FPS? Przecież też programowo. 🙂

Skoro tak, to czemu są przypadki takie, jak opisałem wyżej? Naprawdę uważasz, że zmiana 13900K na 14900K i gruby spadek x% low w teście na 100% limicie GPU to nie jest błąd? Takich i podobnych cudów widziałem na pęczki. A co do średniego FPS, masz informację, ile klatek wyrenderowano i masz czas pomiaru, więc nie problem wyliczyć w 100% poprawny średni FPS, a to, że frametime dla poszczególnych klatek nie jest liczony w 100% poprawnie (a programowo nie jest, nawet jak tego nie przyjmujesz do wiadomości), nie ma dla tej metryki żadnego znaczenia. Natomiast dla wszystkich x% lows ma.

8 godzin temu, sideband napisał:

Zacznijmy od tego, że jest mega ciężko uzyskać dobrą powtarzalność na 0.1% zakładając, że pomiar jest prawidłowy.

Trzeba mieć przygotowane krótką miejscówką z idealnym przejściem lub statyczne miejsce

W zależności od gry nawet to nie jest gwarancją sukcesu Np. COD MW3 w większości misji, jak lecisz na limicie CPU, to FPS lata jak szalony w statycznym miejscu, mimo że w grze nic się nie dzieje (np. wszyscy przeciwnicy wybici)

Edytowane 26 Czerwca przez tomcug

[Kyle_PL 3707]

W Days Gone miałem ciekawy przypadek, kiedy przy uwolnionym fps (spadki znajdowały się jednak powyżej 60fps), czyli brak synchronizacji, brak ogranicznika fps, wąskim gardłem było GPU, to miejscami była znaczna "niepłynność" (np. na jednym z pierwszych przerywników filmowych, kiedy bohaterowie wjeżdżali w pierwszy tunel). Po obniżeniu fps do 60 (w efekcie dało to stały fps i zsynchronizowany z odświeżaniem) wszystko było płynniutkie. Ogromna różnica w widocznej płynności, nie wynikała tylko z tego, że ten wyższy fps był niezsynchronizowany z odświeżaniem. Zwykle nie mam aż takiej przepaści, jak w tej grze.

[kadajo 20243]

Duże różnice w FPS zawsze będą się tak objawiać, dlatego lepiej jest używać CAP'a.

[SebastianFM 2244]

@tomcug, wystarczy jeden zrzut ekranu z Nsight Systems, żeby obalić tą całą twoją teorię o tym, że te programowe pomiary są nieprawidłowe, ponieważ wszystkie raportowane zdarzenia są idealnie skorelowane z użyciem CPU i GPU. Wiem już nawet z czego wynika twoje błędne założenie o tym, że te pomiary są nic nie warte. Z twoich odpowiedzi wynika, że ty nie masz pojęcia o tym, pomiędzy jakimi zdarzeniami są określane odstępy czasu i dlatego uznajesz to za błąd. Jak ci o tym napisałem to zamiast się zagłębić w temat zacząłeś wymyślać, że to niby ja teoretyzuje.

[Thimedes 1457]

Taki wykresik słupkowy sporządziłem z tym jak Intel ewoluował wydajność na cykl zegara w ich procesorach:

[Assassin 1179]

Fajny, ale nie całkiem się zgadzam. Nehalem był jednak mocniejszy, no chyba że patrzymy na sam rdzeń (czyli pomijamy HT i IMC). Ogólnie tez chyba aż tak dużo nie tracił do SNB, chyba że w FP z AVX. Wydaje mi się, że Skylake i Comet Lake tez wniosły nieco więcej.

[Pawelek6 525]

Przede wszystkim Ivy Bridge to ta sama architektura co Sandy Bridge (tutaj pokrewieństwo nazw). Tak samo architektura Skylake, to odpowiednio generacje procesorów: Skylake, Kaby Lake, Coffee Lake oraz Comet Lake. Co za tym idzie, różnice w zasadzie nie istnieją, głównie wychodzą ze względu na podniesienie MHz i konfigurację rdzeni, wątków, pamięci podręcznej. Brakuje architektury Cypress Cove, a więc generacji Rocket Lake. No i dalej Raptor Lake, to również jest zwykłe odświeżenie generacji Alder Lake, czyli Golden Cove/Gracemont (choć tutaj Intel namieszał i nazwał sobie od nowa architekturę, choć nową nie jest, ot marketing). Generację procesorów Arrow Lake (nie pamiętam nazwy nowej architektury) przemilczę, bo procesorów nie ma na rynku, a podajesz jakieś wartości.

A więc wykres chyba tak z nudów zrobiony

I polecam rozpiskę generacji mikroarchitektur i generacji procesorów Intela, bo można się w tym pogubić: KLIK.

Edytowane 28 Czerwca przez Pawelek6

[Assassin 1179]

11 minut temu, Pawelek6 napisał:

Przede wszystkim Ivy Bridge to ta sama architektura co Sandy Bridge (tutaj pokrewieństwo nazw). Tak samo architektura Skylake, to odpowiednio generacje procesorów: Skylake, Kaby Lake, Coffee Lake oraz Comet Lake.

Fakt. Pomyliłem Comet Lake z Rocket Lake - to ten powinien być ~10-15% (nie pp) szybszy od Skylake.

[AMDK11 143]

2 godziny temu, Assassin napisał:

Fajny, ale nie całkiem się zgadzam. Nehalem był jednak mocniejszy, no chyba że patrzymy na sam rdzeń (czyli pomijamy HT i IMC). Ogólnie tez chyba aż tak dużo nie tracił do SNB, chyba że w FP z AVX. Wydaje mi się, że Skylake i Comet Lake tez wniosły nieco więcej.

HT jest częścią mikroarchitektury Nehalem,  który względem Conroe został przebudowany ale niektóre bufory zostały na sztywno podzielone pomiędzy wątki SMT i przez to pojedynczy wątek ma mniej niż Conroe ale mimo to średni zysk ST to okolice ~10%. Z SMT(HT) znacznie więcej.

 

IvyBridge to niby z grubsza ta sama mikroarchitektura co SandyBridge ale zamiast podzielonych na sztywno buforów między wątaki HT i tylko połowę dla ST ma dynamiczny przydział między wątki SMT i całość dla ST. Do tego w IvyBridge poraz pierwszy wprowadzono ZERO IDIOM i nowe instrukcje m.in generator liczb pseudolosowych.

Edytowane 28 Czerwca przez AMDK11

[Thimedes 1457]

W dniu 28.06.2024 o 23:44, AMDK11 napisał:

HT jest częścią mikroarchitektury Nehalem,  który względem Conroe został przebudowany ale niektóre bufory zostały na sztywno podzielone pomiędzy wątki SMT i przez to pojedynczy wątek ma mniej niż Conroe ale mimo to średni zysk ST to okolice ~10%. Z SMT(HT) znacznie więcej.

Wiem, że druga generacja Core2 wniosła +10% PPC. Nehalem to jeszcze 15-20% ponadto + two-way multi-threading, który wnosi jakieś kolejne 15-20%. W Zen 5 multi-threading to już chyba +50% do ogólnej wydajności wielowątkowej.