Cyberpunk 2077 ei hyödynnä SMT-teknologiaa Ryzen-prosessoreilla

[Kaotik]

Cyberpunk 2077 -pelaajat ovat huomanneet, että peli ei hyödynnä SMT-teknologiaa Ryzen-prosessoreilla.
Syyllinen tähän löytyy CD Projekt Redin käyttämästä vanhasta GPUOpenin alaisesta koodinpätkästä, joka on julkaistu alun perin Bulldozer-optimointina.
Vanhentunut koodinpätkä asettaa sovelluksen hyödyntämään prosessorin loogisia ytimiä Bulldozer-prosessoreilla ja fyysisiä ytimiä muilla AMD:n prosessoreilla, joihin lukeutuu luonnollisesti myös Ryzen.
Tunnistus on mahdollista muuttaa heksaeditorin avulla, mutta todennäköisesti CDPR tulee julkaisemaan sille myös virallisen korjauksen.

Lähteet: https://www.reddit.com/r/pcgaming/c..._an_intel_c_compiler_which/gfknein/?context=3 Cyberpunk 2077 Does Not Leverage SMT on AMD Ryzen, Lower Core-Count Variants take a Bigger Hit, Proof Included

 

[love_doctor]

Tässä ihmeellistä on, miten yksinkertaisesta ongelmasta ja korjauksesta on kyse. Jos peliä olisi testattu AMD:n laitteilla kunnolla CPU-profilointityökalun kanssa, ongelma olisi selvinnyt helposti kehitysaikanakin. Nyt asian paikallistivat ja korjasivat pelin engineä tuntemattomat ennätyksellisen lyhyessä ajassa.

 

[Halpuuttaja]

Computerbase testasi tuota 5000 -sarjan Ryzeneillä ja vain 5600X:llä tulos oli parempi SMT-hackin kanssa.

Cyberpunk 2077 im Benchmark-Test: Prozessor-Benchmarks, AMD SAM, CPU-Hack für Ryzen und Patches

Cyberpunk 2077 im Test: Prozessor-Benchmarks, AMD SAM, CPU-Hack für Ryzen und Patches

www.computerbase.de

edit: ja kommentoivat että 5600X:llä tuon SMT-hackin kanssa esiintyi stutterointia.

 

[Cirrus]

Computerbase testasi tuota 5000 -sarjan Ryzeneillä ja vain 5600X:llä tulos oli parempi SMT-hackin kanssa.

Toms hardware teki samaa ja järein amd otti selkeästi takkiin. En jaksanut etsiä häkin tarkkaa toimintaa, mutta se kuulosti joltain täydellisen typeryystason affinitypakotukselta. Eipä sellaista tietenkään tule oikeasti.

 

[hsalonen]

Computerbase testasi tuota 5000 -sarjan Ryzeneillä ja vain 5600X:llä tulos oli parempi SMT-hackin kanssa.

Cyberpunk 2077 im Benchmark-Test: Prozessor-Benchmarks, AMD SAM, CPU-Hack für Ryzen und Patches

Cyberpunk 2077 im Test: Prozessor-Benchmarks, AMD SAM, CPU-Hack für Ryzen und Patches

www.computerbase.de

edit: ja kommentoivat että 5600X:llä tuon SMT-hackin kanssa esiintyi stutterointia.

Niin.. ja tästä voi jokainen itse lukea, että hack/SMT hidastaa kaikkia muita prosessoreita, paitsi 5600X:ta. 5600X:n kanssa se aiheuttaa stutterointia.

--

Haluaisin nähdä muitakin lukuja, mutta tämän valossa ihan turha "korjata" ja ei siitä "korjauksesta" saa mitään hyötyä. Erityisesti kiinnostaisi Intel i5-9600K vs i5-10600K..

 

[Kaotik]

Haluaisin nähdä muitakin lukuja, mutta tämän valossa ihan turha "korjata" ja ei siitä "korjauksesta" saa mitään hyötyä. Erityisesti kiinnostaisi Intel i5-9600K vs i5-10600K..

Tällä ei ole mitään vaikutusta tai tekemistä Intelin prosessoreiden kanssa, koskee vain AMD:ta.

 

[hsalonen]

Tällä ei ole mitään vaikutusta tai tekemistä Intelin prosessoreiden kanssa, koskee vain AMD:ta.

Juu, niinhän uutisessa luki. Tuossa vaan saa helposti kuvan, nopeuttaako SMT peliä. Jos siitä on vaan haittaa, niin feasibility study on tehty ja "korjausta" on turha lähteä tekemään, riippumatta siitä, mitä ihmiset internetissä mölisee.

 

[Heseman]

Vähän aihetta sivuten, Tukka-Stevehän oli juuri tehnyt CPU-testausta tällä pelillä ja havaitsi, että Ryzen 3 3300X (4/8) ja Intel i5-8600K (6/6) kärsivät häiritsevästä stutterista, vaikka FPS-luvut näyttikin hyviltä. Näistä tarkempaa dataa 9:30 paikkeilla. Pelkät FPS:t ei siis kerro kaikkea.

 

[joonabbi]

Redditissä oli myös tälläinen postaus
Ei ole omaa kokemusta, mutta kannattaa tsekata.

 

[KVahlman]

Juu, niinhän uutisessa luki. Tuossa vaan saa helposti kuvan, nopeuttaako SMT peliä. Jos siitä on vaan haittaa, niin feasibility study on tehty ja "korjausta" on turha lähteä tekemään, riippumatta siitä, mitä ihmiset internetissä mölisee.

No toisaalta tuossa taulukossahan on vain 5000 sarjan CPU:t, joilla singlecorea on vaikka muille jakaa. Epäilisin että noilla isommilla prossuilla tasaisemmin levitetty kuorma pudottaa boosteja about eron verran, kun taas 5600X hyötyy koska 6 threadia on "liian vähän" ja se käsittääkseni pitää boostitkin helpommin täydessä rasituksessa. Mielenkiintoista olisi nähdä sama testi mutta siten että kellot on tapissa koko ajan.

Samaten 3000 sarjalla tilanne voisi olla vähän eri kun siellä singlecorea ei ole samaan malliin jolloin kuorman levittäminen saattaa ollakin hyödyllistä. Toivottavasti joku tekisi kattavamman testin, vaikka sinänsä ongelma nyt ei ole järjettömän mielenkiintoinen niin suorituskykyvaikutukset SMT on/off eri ydinmäärillä, eri yhden ytimen suorituskyvyllä ja erilaisilla boostikäytöksillä on aika mielenkiintoista dataa.

 

[Cirrus]

No toisaalta tuossa taulukossahan on vain 5000 sarjan CPU:t, joilla singlecorea on vaikka muille jakaa. Epäilisin että noilla isommilla prossuilla tasaisemmin levitetty kuorma pudottaa boosteja about eron verran, kun taas 5600X hyötyy koska 6 threadia on "liian vähän" ja se käsittääkseni pitää boostitkin helpommin täydessä rasituksessa. Mielenkiintoista olisi nähdä sama testi mutta siten että kellot on tapissa koko ajan.

Samaten 3000 sarjalla tilanne voisi olla vähän eri kun siellä singlecorea ei ole samaan malliin jolloin kuorman levittäminen saattaa ollakin hyödyllistä. Toivottavasti joku tekisi kattavamman testin, vaikka sinänsä ongelma nyt ei ole järjettömän mielenkiintoinen niin suorituskykyvaikutukset SMT on/off eri ydinmäärillä, eri yhden ytimen suorituskyvyllä ja erilaisilla boostikäytöksillä on aika mielenkiintoista dataa.

Tuo peli käynnistää threadeja aika kovan määrän muutenkin. Sen juuri sen real core countin verran. Jos tuo hakkerointifixi aiheuttaa sen että niitä lähtee päälle 32 5950x:llä niin mahtaa alkaa tulla vastaan jo enginen threadeille skaalautumisen määräkin.

 

[jokumuu]

Minulla ei ole kumpaakaan, AMD:tä tai Cyberpunkkia, mutta näin sivusta huutelen ihan mielenkiinnosta.

Kannattaa mitata ennen ja jälkeen tulokset ja seurata cpu context switchien määrää (kuinka paljon suorittavat softasäikeet loikkivat rautasäikeeltä toiselle). Context switchin kustannus on pienen latenssin softissa ihan älytön, koska käytännössä CPU välimuistit pitää aina synkata context switchissä uudestaan (ccNUMA, ja eikös Ryzen/ZEN ollut joku corepaketointiviritelmä). Tämä saattaa aiheuttaa myös vakauteen/eheyteen ongelmia, jos asiaan ei ole kiinnitetty huomiota tuotekehitysvaiheessa.
Voi olla, että kehittäjät ovat tehneet rajoitusratkaisun ihan tarkoitusella.

Context switchejä voi mitata windowsin performance monitor työkalulla:
Monitoring Context Switches | Microsoft Docs

 

[tuoppi´]

Luulis ton olevan nopeampi, jos kerran uudempi versio GPUOpenista käyttää SMT:tä.

 

[möösi]

Käsitinkö nyt oikein että mun Ryzen 3500x on abouttirallaa sama kuin Ryzen 3600 Cyberpunkissa, koska SMT poissa?

 

[HikinenM]

Computerbase testasi tuota 5000 -sarjan Ryzeneillä ja vain 5600X:llä tulos oli parempi SMT-hackin kanssa.

Cyberpunk 2077 im Benchmark-Test: Prozessor-Benchmarks, AMD SAM, CPU-Hack für Ryzen und Patches

Cyberpunk 2077 im Test: Prozessor-Benchmarks, AMD SAM, CPU-Hack für Ryzen und Patches

www.computerbase.de

edit: ja kommentoivat että 5600X:llä tuon SMT-hackin kanssa esiintyi stutterointia.

Jännästi nuo tulokset vaihtelevat sivustoista toiseen, vaikka kaikissa on ollut sama tulos että 5900x/5950x eivät hyödy tuosta, mutta 5600x/3600/3700x/2600x/2700x ym. taas hyötyvät. Mutta tuo olisi uutta että tulisi stutterointia 5600x:llä, en ole itse ainakaan huomannut. Toistaiseksi sinun linkkaamasi on ainoa testisivusto joka ei suosittele tuota fixiä millään Ryzen prosessorilla.

Cyberpunk 2077 AMD Ryzen SMT Performance Fix Now Easier With This Simple Mod

A new mod makes easy work of fixing the AMD SMT performance bug in Cyberpunk 2077, as well as some other minor issues.

hothardware.com

"In a system powered by an 8-core AMD Ryzen 7 3700X, our own Ben Funk saw a roughly 11 percent gain in framerates after making the change, with better SMT handling at play. Have a look (and note this data is from the HEX edit, not the mod)...
Minimum framerates also saw a jump. The bottom line is, if you own a Ryzen processor, we recommend either making the HEX edit or giving the mod a go, to make sure you are getting the most performance possible out of your system. Incidentally, Intel systems are not affected by this apparent bug."

Cyberpunk 2077 na CPU Ryzen: pomůže záplata pro využití SMT? - Testy s využitím SMT patche

Cyberpunk 2077 přišel se svou náloží problémů a chyb, přičemž mezi ně patří také údajná neschopnost využít SMT na procesorech AMD Ryzen. Jde tak o logická jádra, na něž se v dnešním malém testu zaměříme.

www.svethardware.cz

3600x + GeForce RTX 3080 Eagle OC 10G

 

[SiB77]

Häksi toimii jos on laittanut biossista allcore kellot.

 

[hkultala]

Minulla ei ole kumpaakaan, AMD:tä tai Cyberpunkkia, mutta näin sivusta huutelen ihan mielenkiinnosta.

Kannattaa mitata ennen ja jälkeen tulokset ja seurata cpu context switchien määrää (kuinka paljon suorittavat softasäikeet loikkivat rautasäikeeltä toiselle). Context switchin kustannus on pienen latenssin softissa ihan älytön, koska käytännössä CPU välimuistit pitää aina synkata context switchissä uudestaan (ccNUMA, ja eikös Ryzen/ZEN ollut joku corepaketointiviritelmä).

Ei tarvi synkata mitään L2-välimuisteja uusiksi context switchissä

CPU-käskykantojen speksi suunnitellaan aina siten että välimuistin olemassaolo on käytännössä läpinäkyvää, välimuistillisen prosessorin pitää tuottaa aivan samat tulokset kuin välimuistiton prosessori laskisi.

Se välimuistien tila pidetään jatkuvasti sellaisena, että siellä ei voi olla eri ytimien/säikeiden mielestä eri järjestyksessä tapahtuvia kirjoituksia samaan osoitteeseen. Tätä tarkoittaa välimuistin koherenssius. Tämä tehdään jotta ylläoleva periaate siitä että välimuisti ei vaikuta laskennan tulokseen toteutuisi.

Ja tällä ei ole mitään tekemistä context switchin/virtuaalimuistin kanssa, tämä mekanismi toimii täysin fyysisillä muistiosoitteilla.

Välimuistit on kaikissa yleisissä CPUissa tagattu fyysisillä osoitebiteillä (vaikka yksi henkilö täällä yrittää Zenin L1D:n osalta väittää muuta kun lukee rivien välistä asioita, joita siellä ei sanota). (virtuaalinen tägays löytyy nykyaikana suurinpiirtein ainoastaan IBMn mainframeprossuista, mutta niitä ei voi sanoa yleiseksi prossuksi)

Ainoa asia miten context switch suoraan vaikuttaa välimuistien flushaamiseen on, että data jonka yksi prosessi on ladannut tai tallettanut AMDn Zenin L1D-kakkuun on käyttökelvotonta toiselle prosessille (koska way-predictionin microtagit riippuu virtuaaliosoitteesta, ja ne vaihtuu context switchissä, ja ilman vlaidia mikrotagia välimuistista tulee huti vaikka data siellä fyysisesti olisi), vaikka sillä olisi oikeudet sen käyttämiseen. Tämä voi johtaa siihen, että pieni määrä likaista dataa tarvii sieltä flushata sen L2-kakkuun, mutta tämä ei vaikuta millään tavalla siihen, miten se lähtee sieltä kohti muita ytimiä.

Tämä saattaa aiheuttaa myös vakauteen/eheyteen ongelmia, jos asiaan ei ole kiinnitetty huomiota tuotekehitysvaiheessa.

Systeemit suunnitellaan siten, että ne toimii oikein ihan riippumatta siitä, kuinka monta conxtext switchiä siellä tapahtuu, tai paljonko dataa joudutaan siirtämään välimuistien välillä.

Softa on yksinkertaisesti rikki jso se voi hajota context switcehin tai liialliseen välimuistin koherenssiliikenteeseen (joilla ei siis ole mitään tekemistä keskenään).

Jos se hajoaa jollain isolla määrällä, ei ole mitään takeita ettei se voisi hajota myös pienemmällä määrällä. Suurempi määrää ainoastaan nostaa todennäköisyyttä että tähdet asettuu asentoon, jossa bugi ilmenee.

Voi olla, että kehittäjät ovat tehneet rajoitusratkaisun ihan tarkoitusella.

Ei. Tai siis ei mistään tällaisesta syystä.

Syy on se, että
1) haluttiin että säikeitä on optimaalinen määrä sekä phenomilla, bulldozerilla että intelin SMTtä tukevilla prossuilla, eikä yhtään varauduttu siihen, että AMDltä voi joskus tulla prossu joka toimii tämän osalta samalla tavalla kuin intelin prossut
2) kirjoitettiin tämä valintakoodi typerästi (lähinnä koska kukaan ei uskaltanut kirjoittaa sitä kokonaan uusiksi, lisättiin vaan uusia erikoistapauksia eri prossuille). Sen olisi saanut helposti kirjoiteitettua siten, että se olisi ollut optimaalinen kaikilla (valita katsoa vaan suoraan loogisten ytimien määrää, ignoraten fyysisten määrä), ja tämä optimaalinen koodi olisi ollut jopa lyhempi kuin nykyinen epäoptimaalinen koodi.

 

[Halpuuttaja]

Jännästi nuo tulokset vaihtelevat sivustoista toiseen

Juu on kyllä merkittävä parannus tuossa Hothardwaren testissä. Varmaan kannattaa kokeilla miten omalla koneella toimii.

Pelihän on ihan raakileena julkaistu, ehkäpä tämäkin vielä työn alla CDPR:llä...

 

[HikinenM]

Juu on kyllä merkittävä parannus tuossa Hothardwaren testissä. Varmaan kannattaa kokeilla miten omalla koneella toimii.

Pelihän on ihan raakileena julkaistu, ehkäpä tämäkin vielä työn alla CDPR:llä...

Jep, varauksella nämä omat korjailut ja aina kannattaa tarkistaa miten vaikuttaa omaan kokoonpanoon. Toivotaan että CDPR korjaa tuon suoraan peliin parhaalla katsomallaan tavalla jotta kaikki prosessorit toimivat mahdollisimman tehokkaasti.

 

[Kaotik]

Luulis ton olevan nopeampi, jos kerran uudempi versio GPUOpenista käyttää SMT:tä.

Sen verran korjausta ettei ole mitään "uudempaa versiota GPUOpenista", GPUOpen on AMD:n ylläpitämä sivusto kaikenkarvaisille avoimen lähdekoodin optimoinneille, sampleille, teknologioille jne. Tässä on kyse sen kautta julkaistusta optimoinnista, joka oli joskus muinoin oleellinen, nykyään tekee hallaa eikä kukaan ole tajunnut korjata sitä samplea huomioimaan uudempiakin prossuja.

 

[jokumuu]

Ei tarvi synkata mitään L2-välimuisteja uusiksi context switchissä

CPU-käskykantojen speksi suunnitellaan aina siten että välimuistin olemassaolo on käytännössä läpinäkyvää, välimuistillisen prosessorin pitää tuottaa aivan samat tulokset kuin välimuistiton prosessori laskisi.

Se välimuistien tila pidetään jatkuvasti sellaisena, että siellä ei voi olla eri ytimien/säikeiden mielestä eri järjestyksessä tapahtuvia kirjoituksia samaan osoitteeseen. Tätä tarkoittaa välimuistin koherenssius. Tämä tehdään jotta ylläoleva periaate siitä että välimuisti ei vaikuta laskennan tulokseen toteutuisi.

Anteeksi, oioin ja yksinkertaistin hieman liikaa. Kertomasi on hyvä selitys yleisperiaatteelle.


Mutta... cache coherency protokollat takaavat samat data, eivät samaa järjestystä ooo-arkkitehtuureilla.

Yksinkertaistettuna, meillä on Nodet1 ja 2. alkutilanne on sama.
N1 N2
1:A 1:A
2:A 2:A
3:A 3:A
4:A 4:A

Säie1 asuu N1:llä, säie2 N2:lla.
S1 päivittää yhden A:n B:ksi, S2 tekee omalla tahollaan saman C:ksi. Koska ooo, nodet toimivat itsenäisinä yksikköinä.
N1 N2
1:B 1:C
2:A 2:A
3:A 3:A
4:A 4:A

CC<->

N1 N2
1:B 1:C
2:C 2:B
3:A 3:A
4:A 4:A

Datat ovat edelleen samat, mutta järjestys eri.
S2 siirretään N1:ltä N2:lle (ja S2 poistuu tai ei touhua enää tuossa osassa cachea).
Koska välimuisteja ei nyt synkattu, S1 saa dataa hakiessaan eri tuloksen kuin pitäisi.

Ongelman voi välttää:
1. bindaamalla S1:n N1:lle, ongelmaksi tulee se, jos säikeitä tulee paljon ja niitä bindaillaan, niin schedulointi tulee hankalaksi tai vähintäänkin epäoptimaaliseksi.
2. Laittamalla memory barrierin. Memory barrier takaa järjestyksen, mutta aiheuttaa pullonkaulaksi cache coherencyn. Lisäksi välimuistin käyttö ei välttämättä ole optimaalista jos näin tekeviä säikeitä on paljon.
3. Tekemällä context switchissä sync()in, jolloin välimuistit ovat taas samat.
4. Epäoptimoimalla, jolloin tilanneta ei välttämättä tapahdu. (tai siis jättämättä ihan jyrkimmät optimoinnit pois)
5. Vähentämällä rinnakkaisuutta, jolloin on vähemmän säikeitä kisaamassa.

Mikä sitten on optimaalista riippuu softasta. Voisi kuvitella, että fysiikkalaskenta on mikrosekuntiluokan softaa, jossa tällaista tapahtuu. Latenssit kun tuppaavat kertautumaan koodissa.

Ja vielä edit: En tiedä toimii AMD näin, mutta Intelin NUMAt toimivat

 

[hkultala]

Anteeksi, oioin ja yksinkertaistin hieman liikaa. Kertomasi on hyvä selitys yleisperiaatteelle.

Mutta... cache coherency protokollat takaavat samat data, eivät samaa järjestystä ooo-arkkitehtuureilla.

Ei.

Se, että kaikki näkevät saman kirjotuksen, tarkoittaa, että ne näkevät sen saman kirjoitetun arvon.

Mutta siitä, koska se sen näkee, ei taata muuta kuin niiden järjestys.

Mutta koska niiden pitää nähdä kaikki kirjoitukset samaan osoitteeseen samassa järjestyksessä, toinen ei saa kirjoittaa siihen ennen kuin se on varmistanut, että toinen ei ole välissä kirjoittanut siihen.

Käytännössä aina, kun välimuistiin kirjoitetaan, se välimusitilinja pitää ottaa itselle sellaiseen moodiin, että muut eivät saa kirjoittaa siihen yhtä aikaa (ja saada muilta siirrettyä niiden viimeinen kirjoitus joka tapahtui ennent ätä haltuunottoa).

Yksinkertaistettuna, meillä on Nodet1 ja 2. alkutilanne on sama.
N1 N2
1:A 1:A
2:A 2:A
3:A 3:A
4:A 4:A

Säie1 asuu N1:llä, säie2 N2:lla.
S1 päivittää yhden A:n B:ksi, S2 tekee omalla tahollaan saman. Koska ooo, nodet toimivat itsenäisinä yksikköinä.
N1 N2
1:B 1:A
2:A 2:A
3:A 3:A
4:A 4:B

Datat ovat edelleen samat, mutta järjestys eri.
S2 siirretään N1:ltä N2:lle (ja S2 poistuu tai ei touhua enää tuossa osassa cachea).
Koska välimuisteja ei nyt synkattu, S1 saa dataa hakiessaan eri tuloksen kuin pitäisi.

Ei. molemmat eivät saa kirjoittaa samaan muuttujaan "ristiin". tämä on asia jonka välimuistin koherenssius kieltää.

Ei välimuistinkoherenttius vertaa mitään datasisältöjä vaan sitä, mihin osoitteisin (välimuistiulohkoihin) kirjoitetaan. Ja pakottaa vaan kirjoitukset samaan osoitteesen johonkin kaikille samaan järjestykseen.

Se, että alettaisiin vertamaan että "satuttiinko kirjoittamaan sama luku" olisi aivan älyttömän raskasta ja hyöty olisi olematon, koska yleensä eri säikeet EI kirjoita sinne samaa dataa.

Ongelman voi välttää:
1. bindaamalla S1:n N1:lle, ongelmaksi tulee se, jos säikeitä tulee paljon ja niitä bindaillaan, niin schedulointi tulee hankalaksi tai vähintäänkin epäoptimaaliseksi.
2. Laittamalla memory barrierin. Memory barrier takaa järjestyksen, mutta aiheuttaa pullonkaulaksi cache coherencyn. Lisäksi välimuistin käyttö ei välttämättä ole optimaalista jos näin tekeviä säikeitä on paljon.
3. Tekemällä context switchissä sync()in, jolloin välimuistit ovat taas samat.

sync() flushaa levyvälimuistin (joka on puhdasta softaa käyttiksessä), sillä ei ole mitään tekemistä CPUilla olevan muistille toimivan rautavälimuistin kanssa.

4. Epäoptimoimalla, jolloin tilanneta ei välttämättä tapahdu. (tai siis jättämättä ihan jyrkimmät optimoinnit pois)
5. Vähentämällä rinnakkaisuutta, jolloin on vähemmän säikeitä kisaamassa.

Mikä sitten on optimaalista riippuu softasta. Voisi kuvitella, että fysiikkalaskenta on mikrosekuntiluokan softaa, jossa tällaista tapahtuu. Latenssit kun tuppaavat kertautumaan koodissa.

Ja vielä edit: En tiedä toimii AMD näin, mutta Intelin NUMAt toimivat

Sotket nyt aivan täysin CPUn välimuistin koherenttiuden, säikeiden välisen synkronoinnin ja levyvälimuistin toiminnan keskenään, ja sen, mikä on softan, mikä raudan vastuulla.

Normaalin user-mode-softan ei koskaan tarvi tehdä mitään datavälimuisti-flushauksia jotta muut ytimen näkee sen niin kauan kun dataa käsittellään vain CPUlla.

Sen sijaan, jos tehdään itseäänmodifioivaa koodia, niin käskyvälimuistia voidaan joutua flushaamaan jotta sinne ladataan uusi modifioitu koodi, mutta tämä pätee jo saman ytimen sisälläkin, tällä ei ole mitään tekemistä monen eri säikeen kanssa.


Ja NUMAlla ei ole myöskään tämän kanssa mitään tekemistä. NUMA tarkoittaa sitä, että meillä on hajautettu muistiväylä jossa osa muistipiireistä on kytketty eri piirillä olevaan muistiohjaimeen kuin osa, jolloin osa muistista on joillekin ytimille NOPEAMPAA kuin joku muu osa siitä.

 

[miksu8]

Eikös se ole vanhaa tietoa että Windozessa AMD:n SMT ei vain toimi peleissä ja pitäisi kytkeä pois. Joitakin poikkeuksia tietty on. Ehkä Cyberpunkin tekijät ovat tienneet kummalla tavalla peli pyörii sujuvammin.

 

[Kaotik]

Eikös se ole vanhaa tietoa että Windozessa AMD:n SMT ei vain toimi peleissä ja pitäisi kytkeä pois. Joitakin poikkeuksia tietty on. Ehkä Cyberpunkin tekijät ovat tienneet kummalla tavalla peli pyörii sujuvammin.

Vanhaa urbaanilegendaa tarkoitat?

Investigating Performance of Multi-Threading on Zen 3 and AMD Ryzen 5000

www.anandtech.com

AMD Ryzen 9 3900X, SMT on vs SMT off, vs Intel 9900K

By community request, we present our findings on how the AMD Ryzen 9 3900X performs with SMT disabled. This approach has potential, especially for gaming, because it ensures more physical hardware units are available for each thread, and could also benefit the processor's power management.

www.techpowerup.com

Toki joissain peleissä tulee takkiin, toisissa tulee plussaa, erot päällä/pois häviävän pieniä keskimäärin, ihan kuten Intelilläkin (oli haastavampaa löytää edes semituoretta, tällainen löytyi Does Intel Hyper Threading Hurt Gaming Performance? I9-9900K Analysis )

 

[miksu8]

Vanhaa urbaanilegendaa tarkoitat?

Investigating Performance of Multi-Threading on Zen 3 and AMD Ryzen 5000

www.anandtech.com

AMD Ryzen 9 3900X, SMT on vs SMT off, vs Intel 9900K

By community request, we present our findings on how the AMD Ryzen 9 3900X performs with SMT disabled. This approach has potential, especially for gaming, because it ensures more physical hardware units are available for each thread, and could also benefit the processor's power management.

www.techpowerup.com

Toki joissain peleissä tulee takkiin, toisissa tulee plussaa, erot päällä/pois häviävän pieniä keskimäärin, ihan kuten Intelilläkin (oli haastavampaa löytää edes semituoretta, tällainen löytyi Does Intel Hyper Threading Hurt Gaming Performance? I9-9900K Analysis )

5950X ei lienee vielä kovin yleinen prossu. Mä katselin Ryzen 5 3600:lla tehtyjä mittauksia. Eli soppaa ilmeisesti hämmentää vielä Zen-sukupolvien erot. Vai onko AMD parantanut vanhempien prossujen tilannetta softapäivityksillä?

 

[Laquel]

Vähän aihetta sivuten, Tukka-Stevehän oli juuri tehnyt CPU-testausta tällä pelillä ja havaitsi, että Ryzen 3 3300X (4/8) ja Intel i5-8600K (6/6) kärsivät häiritsevästä stutterista, vaikka FPS-luvut näyttikin hyviltä. Näistä tarkempaa dataa 9:30 paikkeilla. Pelkät FPS:t ei siis kerro kaikkea.

Jännä homma kyllä tuo 8600k kun en ole mitään erityistä stutteriä huomannut omalla kellotetulla :O Tosin mulla onki 1440p ja RTX päällä niin voi olla että prossu ei rajoita niin paljon kuin tuossa testitilanteessa

 

[Kaotik]

5950X ei lienee vielä kovin yleinen prossu. Mä katselin Ryzen 5 3600:lla tehtyjä mittauksia. Eli soppaa ilmeisesti hämmentää vielä Zen-sukupolvien erot. Vai onko AMD parantanut vanhempien prossujen tilannetta softapäivityksillä?

Tuossa jälkimmäisessä linkissä on Zen 2 (vaikka järeämpi kuin 3600) ja ihan samaa kaavaa noudattaa kuin Zen 3. Laitatko linkkiä näihin mittauksiin mitä itse katselit?

 

[hkultala]

Eikös se ole vanhaa tietoa että Windozessa AMD:n SMT ei vain toimi peleissä ja pitäisi kytkeä pois. Joitakin poikkeuksia tietty on. Ehkä Cyberpunkin tekijät ovat tienneet kummalla tavalla peli pyörii sujuvammin.

Ei. Vaan se on mutua ja väärinymmärrystä.

SMT toimii oikein hyvin, mutta kaikki pelit ei hyödy siitä, jos ne joko 1) ei tarvi suurta määrää säikeitä, ja 2) joillain peleillä tietyissä tilanteissa SMT hidastaa, kun niissä on yksi raskas säie sekä monta kevyttä säiettä joiden hommat voisi aivan hyvin suorittaa pienemmällä määrällä säikeitä peräkkäin, ja näiden ajaminen yhtä aikaa SMTllä hidastaa myös sitä yhtä raskasta säiettä.

Ja tämä olisi ihan samalla tavalla ongelma Intelin SMTtä tukevalla prossulla, tämä ei ole mikään Ryzenin ongelma, vaan vaan huonosti optimoidun softan (epätasainen kuormanjako) ongelma.


Tämä Cyberpunkin ongelma/bugi on täällä moneen kertaan analysoitu ja selitetty sellaisten ihmisten toimesta, jotka on oikeasti perehtyneet asiaan ja lukeneet kyseisen ongelmallisen koodipätkän, miksi pitää alkaa selittämään jotain omaa mutua joka ei oikeasti liity asiaan mitenkään? Koska on liian laiska edes yrittämään ymmärtää, mistä tässä on oikeasti kyse?

 

[nesseijah]

Vaikka minulla on 3900x niin utilisaatiot nousi 30%- > 50%, aikasemmin ei käyttänyt ollenkaan loogisia coreja. Ja vaikka FPS ei juurikaan noussut (GPU bound oli jo aikasemmin) niin stutterointi katosi käytännössä ja tekee pelistä paljon pelattavamman.

 

[miksu8]

Tuossa jälkimmäisessä linkissä on Zen 2 (vaikka järeämpi kuin 3600) ja ihan samaa kaavaa noudattaa kuin Zen 3. Laitatko linkkiä näihin mittauksiin mitä itse katselit?

Molemmat sattuivat olemaan juutuubissa saman tyypin tekemänä:

Edit: Täälläkin ollut keskustelua: Ryzen SMT aka Hyper Threading

 

[_j03_]

Tässä ihmeellistä on, miten yksinkertaisesta ongelmasta ja korjauksesta on kyse. Jos peliä olisi testattu AMD:n laitteilla kunnolla CPU-profilointityökalun kanssa, ongelma olisi selvinnyt helposti kehitysaikanakin. Nyt asian paikallistivat ja korjasivat pelin engineä tuntemattomat ennätyksellisen lyhyessä ajassa.

Eiköhän siellä ole ollut paskat housussa vähän muidenkin asioiden suhteen joten jotain profilointeja tuskin edes tehty. Sen luokan bugipläjäys ettei vastaavaa ole vähään aikaan nähty.

 

[Marti77]

Eiköhän siellä ole ollut paskat housussa vähän muidenkin asioiden suhteen joten jotain profilointeja tuskin edes tehty. Sen luokan bugipläjäys ettei vastaavaa ole vähään aikaan nähty.

On sitä pahempaa nähty esim Red dead redemption 2 mitä ei saanut edes käynnistetty kun julkisti PC version.

 

[_j03_]

On sitä pahempaa nähty esim Red dead redemption 2 mitä ei saanut edes käynnistetty kun julkisti PC version.

Tuo taidettiin korjata aika pikapika vauhdilla. Kokonaisuutena tämän pelin bugit ja puutteet kyllä pahempia. RDR2 ei sentään ole korvattu puolta pelin sisällöstä geneerisellä placeholderilla koska ei ollut aikaa tehdä loppuun asti. Hyvä esimerkki pelin olematon turhake AI.

 

[love_doctor]

Syy on se, että
1) haluttiin että säikeitä on optimaalinen määrä sekä phenomilla, bulldozerilla että intelin SMTtä tukevilla prossuilla, eikä yhtään varauduttu siihen, että AMDltä voi joskus tulla prossu joka toimii tämän osalta tamalla tavalla kuin intelin prossut
2) kirjoitettiin tämä valintakoodi typerästi (lähinnä koska kukaan ei uskaltanut kirjoittaa sitä kokonaan uusiksi, lisättiin vaan uusia erikoistapauksia eri prossuille). Sen olisi saanut helposti kirjoiteitettua siten, että se olisi ollut optimaalinen kaikilla (valita katsoa vaan suoraan loogisten ytimien määrää, ignoraten fyysisten määrä), ja tämä optimaalinen koodi olisi ollut jopa lyhempi kuin nykyinen epäoptimaalinen koodi.

Tai vielä optimaalisempi voisi olla, että lasketaan oletuksena kaikille loogisten ytimien tai muun yleipätevän metriikan mukaan ja vasta tämän jälkeen jos on mittausten kautta varmistettu tietyn cpu-mallin toiminta eri parametreilla eri kokoonpanoissa, manuaalinen parametrien ylikirjoitus olisi vain tälle mallille erityisenä hienosäätönä.

 

[zxcv]

Syy on se, että
1) haluttiin että säikeitä on optimaalinen määrä sekä phenomilla, bulldozerilla että intelin SMTtä tukevilla prossuilla, eikä yhtään varauduttu siihen, että AMDltä voi joskus tulla prossu joka toimii tämän osalta tamalla tavalla kuin intelin prossut
2) kirjoitettiin tämä valintakoodi typerästi (lähinnä koska kukaan ei uskaltanut kirjoittaa sitä kokonaan uusiksi, lisättiin vaan uusia erikoistapauksia eri prossuille). Sen olisi saanut helposti kirjoiteitettua siten, että se olisi ollut optimaalinen kaikilla (valita katsoa vaan suoraan loogisten ytimien määrää, ignoraten fyysisten määrä), ja tämä optimaalinen koodi olisi ollut jopa lyhempi kuin nykyinen epäoptimaalinen koodi.

Cyberpunk 2077 used an Intel C++ compiler which hinders optimizations if run on non-Intel CPUs. Here's how to disable the check and gain 10-20% performance.

Here's an ELI15 version of this: Below is the original ~~core~~ thread count check DWORD cores, logical; getProcessorCount(cores,...

old.reddit.com

Ilmeisesti se koodi on joka tapauksessa buginen. Mun x86 assembly osaaminen ei riittänyt varmistaa kumpi noista koodinpätkistä on käytössä.

 

[hsalonen]

Ja vielä edit: En tiedä toimii AMD näin, mutta Intelin NUMAt toimivat

Tähän nyt vaan tiedoksi, että NUMA tarkoittaa prosessorin erilaista mahdollisuutta tehdä muistihakuja. Intelin vehkeissä ei ole ainakaan kuluttajaluokassa mitään tällaista non-uniformia, kun ytimet ovat samalla piirisirulla.

AMD:lla taas on vaikka chiplettejä, ja niillä on eri cachet ja ne voivat hakea muistista eri tavalla, riippuen siitä, onko se ydin missä CCX:ssä, millä piisirulla tai missä vaan kaukana siitä vertailuytimestä.

NUMA ei ole mitään tekemistä context switchien kanssa ja jotenkin tuntuu, että tässä on toisella tunnuksella käyty jo tämä keskustelu ja vieläkään ei ole täysin ymmärretty, mitä siinä tapahtuu.

NUMA = Non Uniform Memory Access ja Intelin Mesh topologiassa ei ole mitään non uniformia. Nyt aloitetaan sillä, että otat termit haltuun.

 

[Kaotik]

Cyberpunk 2077 used an Intel C++ compiler which hinders optimizations if run on non-Intel CPUs. Here's how to disable the check and gain 10-20% performance.

Here's an ELI15 version of this: Below is the original ~~core~~ thread count check DWORD cores, logical; getProcessorCount(cores,...

old.reddit.com

Ilmeisesti se koodi on joka tapauksessa buginen. Mun x86 assembly osaaminen ei riittänyt varmistaa kumpi noista koodinpätkistä on käytössä.

Toisin kuin tuo linkki väittää, tämä ei ole mikään Intelin kääntäjän tempaus, vaan tuo on ihan suoraan AMD:n GPUOpenista (mutta vanhentunut). Lisäksi tuossa höpötetään jotain Intelin prossuista, tuo koodinpätkä vaikuttaa ja koskee vain AMD:n prossuja.

 

[love_doctor]

Systeemit suunnitellaan siten, että ne toimii oikein ihan riippumatta siitä, kuinka monta conxtext switchiä siellä tapahtuu, tai paljonko dataa joudutaan siirtämään välimuistien välillä.

Softa on yksinkertaisesti rikki jso se voi hajota context switcehin tai liialliseen välimuistin koherenssiliikenteeseen (joilla ei siis ole mitään tekemistä keskenään).

Jos se hajoaa jollain isolla määrällä, ei ole mitään takeita ettei se voisi hajota myös pienemmällä määrällä. Suurempi määrää ainoastaan nostaa todennäköisyyttä että tähdet asettuu asentoon, jossa bugi ilmenee.

Tähän väliin olisi hyvä mainita, että korkean tason ohjelmointikieli luultavasti saattaa tarjota turvallisemman konsistenssimallin kuin laitteisto, jolla voi nykyään olla aika löysä malli. Näiden mallien yhteensovitus voi olla kokonaan delegoitu runtimelle, kääntäjälle ja viimeistään enginelle. Korkealla tasolla on vain lukkoja, mutekseja tai synchronized-lohkoja yms. Oma pelikoodi on rikki, jos se ei noudata ohjelmointikielen ja -ympäristön konsistenssimallia. Tällaistakin perinnekoodia on, missä toivotaan, ettei ajeta liian eksoottisella raudalla, jotta ongelmat eivät realisoituisi. Esim. kun tuplaydinprosessoreita (tai tuplasoketteja) alkoi ilmaantua kuluttajille, jotkin vanhat säiekoodit olivat yhtäkkiä ihan rikki (olivat luottaneet esim. siihen että yksi CPU vuorottelee säikeitä peräkkäin).

Lisäksi voisi ehkä sanoa, että monta säiettä ei implikoi, että kontekstinvaihtoja edes tarvitaan, kun säikeet voi sitoa tietylle ytimelle ja pelilogiikan kannalta ei ole edes välttämättä olennainen/toivottu piirre, että tehdään kontekstinvaihtoja jonkun muun taustaprosessin kanssa. Tai jos niitä tapahtuu, datan käsittely hoituu ihan käyttiksen kautta ja pelikoodi ei paljonkaan sille sitten voi. Toinen vielä, että immutable-datan kanssa on nykyään vähemmän tarve ylipäänsä hakea yhdestä paikasta tila. Peleissä ei ehkä voi hyödyntää joka paikassa, mutta kuitenkin.

 

[Teemu79]

Vaikka minulla on 3900x niin utilisaatiot nousi 30%- > 50%, aikasemmin ei käyttänyt ollenkaan loogisia coreja. Ja vaikka FPS ei juurikaan noussut (GPU bound oli jo aikasemmin) niin stutterointi katosi käytännössä ja tekee pelistä paljon pelattavamman.

Sama todennettu 3800x:llä, cpu% keskiarvo nousi 30:stä 40:een. Aiemmin yksi ydin oli kuormitettu n. 80%:sti, kaksi seuraavaa noin 50% ja loput viisi 15-25% (hyvin karkeasti). Puukotuksen jälkeen neljä säiettä pyörii noin 50-60% tuntumassa jo loput 12 säiettä melko tasaisesti pienemmällä kuormalla. Vega 56 rajoittaa menoa jo muutenkin niin paljon etten huomannut juuri mitään eroa suorituskyvyssä. Dynaaminen skaalaus tiputtaa ehkä hieman harvemmin alemmalle tasolle kuin ennen.

 

[BlackWolf]

Minulle tuli sellainen asia mieleen, että voisikohan uusilla konsoleilla olla sama juttu jäänyt päälle. En tunne niiden sielunelämää niin hyvin, mutta jos vedetty copypastella niiden firmojen omiin työkaluihin, niin teoriassa voisiko siellä olla toi sama tsekkaus jäänyt listoille. Olisi aika hauska.

 

[jokumuu]

Ei. molemmat eivät saa kirjoittaa samaan muuttujaan "ristiin". tämä on asia jonka välimuistin koherenssius kieltää.

Kiitos valaisusta.
Valaisetko vielä hieman tilannetta, jossa välimuistin edessä olevassa striimauspuskurissa (joka ei tietenkään ole osa cachea) sattuisi olemaan vielä cacheline joka itse cachessa on invalid ja kyseistä riviä haluava säie juuri siirretään toisaalta tälle cpulle. Voisiko tässä kuitenkin ihan vähän tapahtua siten, että säie hakeekin rivin puskurista (joka ei tietenkään ole osa cachea) eikä siitä ihan oikeasta cachesta - tai säie hakee mahdollisesti jopa ihan väärän rivin? Ja voisiko tässä myös käydä siten, että kääntäjä ei ole huomioinut tällaista tilannetta?

sync() flushaa levyvälimuistin (joka on puhdasta softaa käyttiksessä), sillä ei ole mitään tekemistä CPUilla olevan muistille toimivan rautavälimuistin kanssa.

Anteeksi sotkin arkkitehtuurit, sync() tekee välimuistisynkkauksen powerpc:ssä, ei x86:ssa. Suoraa vastinetta ei taida olla.[/quote][/QUOTE]

 

[zxcv]

Toisin kuin tuo linkki väittää, tämä ei ole mikään Intelin kääntäjän tempaus, vaan tuo on ihan suoraan AMD:n GPUOpenista (mutta vanhentunut). Lisäksi tuossa höpötetään jotain Intelin prossuista, tuo koodinpätkä vaikuttaa ja koskee vain AMD:n prossuja.

Joko et ymmärtänyt lukemaasi tai et lukenut linkkiä.

Tässä alla mitä kirjoitin Cyberpunkin threadissä.

Cyberpunk 2077 used an Intel C++ compiler which hinders optimizations if run on non-Intel CPUs. Here's how to disable the check and gain 10-20% performance.

Here's an ELI15 version of this: Below is the original ~~core~~ thread count check DWORD cores, logical; getProcessorCount(cores,...

old.reddit.com

Tuossa lienee paras tekninen selitys aiheesta, ei ole mitään tekemistä AVX:n kanssa. Se 75 -> 74 muutos vaihtaa tuon hypyn "jump if not equal" -> "jump if equal" muotoon, ja taas EB vaihtaa tuon hypyn aina tapahtumaan.

EB muutoksen etuna on se että tuo muutos tulee voimaan kaikilla prossuilla, ja jos joku säätää tyhmää ja tekee tuon muutoksen "väärällä" prossulla niin silloin siihen ei mene päälle se oletusasetus joka ei käytä kaikkia(?) coreja, näin siis kävisi jos käyttää 74 arvoa tuossa tilanteessa.

AMD:n vehkeillä ei ole mitään eroa nopeuden kannalta käyttääkö sitä 74 vai EB.

Spoileri tägissä kuinka tuo näkyy IDA:ssa patchattynä ja ilman pätchiä.

Spoileri

 

[vmovapd]

Anteeksi sotkin arkkitehtuurit, sync() tekee välimuistisynkkauksen powerpc:ssä, ei x86:ssa. Suoraa vastinetta ei taida olla.

Ei ole edelleenkään välimuistin synkkauskäsky, vaan PowerPC:n sync näkyy olevan käsky-barrier. X86:n vastineena voi käyttää cpuid-käskyä.

 

[Mawe]

Context switchejä voi mitata windowsin performance monitor työkalulla:
Monitoring Context Switches | Microsoft Docs

Kiitos kun muistutit tuosta työkalusta.

 

[JiiPee]

1) haluttiin että säikeitä on optimaalinen määrä sekä phenomilla, bulldozerilla että intelin SMTtä tukevilla prossuilla, eikä yhtään varauduttu siihen, että AMDltä voi joskus tulla prossu joka toimii tämän osalta tamalla tavalla kuin intelin prossut
2) kirjoitettiin tämä valintakoodi typerästi (lähinnä koska kukaan ei uskaltanut kirjoittaa sitä kokonaan uusiksi, lisättiin vaan uusia erikoistapauksia eri prossuille). Sen olisi saanut helposti kirjoiteitettua siten, että se olisi ollut optimaalinen kaikilla (valita katsoa vaan suoraan loogisten ytimien määrää, ignoraten fyysisten määrä), ja tämä optimaalinen koodi olisi ollut jopa lyhempi kuin nykyinen epäoptimaalinen koodi.

Paitsi että tota koodia ei joidenkin mukaan ole edes tarkoitettu käytettävksi copy/pastena vaan palvelee lähinnä esimerkki koodina.

 

[Sampsa]

1.05 hotfix korjaa asian, vaikuttaa ainoastaan 4- ja 6-ytimisiin Ryzen-prosessoreihin

 

[FlyingAntero]

Tarkoittaako tuo samalla myös, että Cyperpunk ei juurikaan osaa hyödyntää useampaa kuin 8-12 säiettä? Suorituskykyero useamman ytimen prosessoreille tulisi sitten vain korkeammista kelloista?

 

[Sampsa]

Tarkoittaako tuo samalla myös, että Cyperpunk ei juurikaan osaa hyödyntää useampaa kuin 8-12 säiettä? Suorituskykyero useamman ytimen prosessoreille tulisi sitten vain korkeammista kelloista?

8-12 ydintä tarkoittaa 16-24 säiettä, mutta joo SMT on jätetty niillä tarkoituksella pois koska aidot ytimet parempia

 

[FlyingAntero]

8-12 ydintä tarkoittaa 16-24 säiettä, mutta joo SMT on jätetty niillä tarkoituksella pois koska aidot ytimet parempia

Sitä tuossa just pohdin, kun 8-ytimiselle SMT:tä ei kuitenkaan enabloitu. 6-ytimisellä on kuitenkin parempi ajaa 12 säiettä.

 

[Cirrus]

Sitä tuossa just pohdin, kun 8-ytimiselle SMT:tä ei kuitenkaan enabloitu. 6-ytimisellä on kuitenkin parempi ajaa 12 säiettä.

Ihmettelin samaa jo cyberpunk ketjussa heti. Mutta oletko varma että ne käynnistää 12 säiettä?

Mutta joo. Se on päivän selvää että jos 5600x on nopein 12:sta säikeellä, níin myös 5800x oilisi nopein samalla määrällä ja päivitys on kustu taas.