Intel varmisti Ice Lake -koodinimen 8. sukupolven Core-prosessoreiden seuraajalle

[Kaotik]

Intelin verkkosivuilta löytyy listaus yhtiön prosessoreiden ja muiden piirien sekä niihin liittyvien alustojen koodinimistä. Nyt yhtiö on julkistanut sivuillaan virallisesti jo pidempään huhuissa pyörineen Ice Lake -koodinimen tulevalle prosessoriarkkitehtuurille. Ice Lake tulee seuraamaan markkinoilla Cannonlakea, ensimmäistä 10 nanometrin prosessilla valmistettua Intel-prosessoria.

Ice Lakesta tiedetään toistaiseksi vain vähän, mutta mikäli Intel ei muuta jälleen suuressa myllerryksessä ollutta julkaisusykliään, kyseessä olisi uusi arkkitehtuuri siinä missä pian julkaistavat Coffee Laket ja niitä seuraavat Cannonlaket perustuvat edelleen Skylakeen.

Mielenkiintoisesti Ice Lake on nimetty seuraajaksi 8. sukupolven Core -prosessoreille, huolimatta siitä, että itse päälistauksessa sen mainitaan kuuluvan kyseiseen sukupolveen. Tällä hetkellä tiedetään, että 8. sukupolven Core -prosessorit tulevat sisältämään ainakin Kaby Lake-R- ja Coffee Lake -prosessoreita, mutta mikäli Ice Lake seuraa 8. sukupolvea, on myös Cannonlaken kuuluttava samaan sukupolveen Kaby Lake-R:n ja Coffee Laken kanssa.

Ice Lake tullaan valmistamaan Intelin 10 nm+ -valmistusprosessilla, eli päivitetyllä toisen sukupolven 10 nanometrin prosessilla.

Lähde: Intel

Huom! Foorumiviestistä saattaa puuttua kuvagalleria tai upotettu video.

Linkki alkuperäiseen uutiseen (io-tech.fi)

 

[E.T]

Taitaa olla Intel itsekin jo sekaisin että mitä kuuluu mihinkin sukupolveen...
Tai sitten Cannonlake on vain Coffee Lake uusilla kuorilla.

 

[Threadripper]

Taitaa olla Intel itsekin jo sekaisin että mitä kuuluu mihinkin sukupolveen...
Tai sitten Cannonlake on vain Coffee Lake uusilla kuorilla.

Olihan myös 7. generation 6. generation eri nimellä.

 

[Juhamies]

Vois intel muuttaa noiden nimeämistä reilusti siten että ne oikeasti erottais toisistaan ja sukupolvien nimet on puhtaasti erilaisia. Nyt on Lakeja niin stnasti että ei tuossa pysy enää perässä mikä on mitäkin sukupolvea jnejne... AMD:lla sentään pysyy jotenkin kärryillä vielä

 

[HarhaanJohtaja]

Eikö Icelaken pitäis olla jotain muuta arkkitehtuuria tai mitälie kuin Core?

Edit. Ilmeisesti Tigerlaken tai minkälie jälkeen olisi vasta tulossa.

 

[DjSunki]

Jaa että Cannonlake on vielä samaa kuin Coffee Lake? Taitaa sitten vielä pysyä hetkisen tämä 3570K käytössä. Suoraan mielummin hyppää uuden arkkitehtuurin kyytiin. Ei tässä kiire ole

 

[Hessu]

Jaa että Cannonlake on vielä samaa kuin Coffee Lake? Taitaa sitten vielä pysyä hetkisen tämä 3570K käytössä. Suoraan mielummin hyppää uuden arkkitehtuurin kyytiin. Ei tässä kiire ole

Kyllähän tuossa artikkelissa mainitaan, että ice lake on cannon lake refresh. Cannon lake on siis 10nm prossu, kuten road mapeissa on jo pitkään ollutkin. Taivasjärvi, käpy ja kahvijärvi ovat samaa arkkitehtuuria muutamilla päivityksillä.

 

[DjSunki]

Kyllähän tuossa artikkelissa mainitaan, että ice lake on cannon lake refresh. Cannon lake on siis 10nm prossu, kuten road mapeissa on jo pitkään ollutkin. Taivasjärvi, käpy ja kahvijärvi ovat samaa arkkitehtuuria muutamilla päivityksillä.

Ah mjoo meikäläinen taas puusilmänä lukenut omiaan Pysytään siis alkuperäisessä suunnitelmassa.

 

[zepi]

Oleellista tässä kaikessa on varmaan se, että mikroarkkitehtuuri pysyy pitkälti samana vielä pitkään. Laket ovat lakeja ja massiivisia eroja kiiden välillä tuskin IPC:ssä nähdään. Nähtäväksi jää, että millaisiin kellotaajuuksiin Intelin uudet 'lake versiot uusilla prosesseilla venyvät, mutta itse en ainakaan odota paljon IPC-kehitykseltä.

 

[Kerosiini]

Jaa, meinasin minäkin alunperin tykkijärveen päivitellä haswellistä, mutta taitaa olla järkevämpää odotella Ice Lake vs Ryzen 2 matsia. Saa nähdä saako pidettyä ostohousut kahleissa ja kloroformattuna.

 

[jabbadap]

Taitaa olla Intel itsekin jo sekaisin että mitä kuuluu mihinkin sukupolveen...
Tai sitten Cannonlake on vain Coffee Lake uusilla kuorilla.

Cannonlake(10nm) on kutistettu Coffeelake(14nm), ei sen kummempaa. Molemmat siis on vanhaa twiikattua Skylakea(kuten kabylakekin). Se vaan että miksi ne ei nimenneet Ice lakea joksikin muuksi. Wellit oli wellejä(haswell broadwell) ja bridget bridgejä(sandy, ivy). Laketkin olisi saaneet olla lakeja(sky, kaby, coffee, cannon).

 

[Kaotik]

Kyllähän tuossa artikkelissa mainitaan, että ice lake on cannon lake refresh. Cannon lake on siis 10nm prossu, kuten road mapeissa on jo pitkään ollutkin. Taivasjärvi, käpy ja kahvijärvi ovat samaa arkkitehtuuria muutamilla päivityksillä.

Eipäs ole, vaan nimenomaan pitäisi olla uusi arkkitehtuuri (samaan tapaan uusi kuin skylake oli aikoinaan, tai haswell jne)

 

[Proscribo]

Cannonlake(10nm) on kutistettu Coffeelake(14nm), ei sen kummempaa. Molemmat siis on vanhaa twiikattua Skylakea(kuten kabylakekin). Se vaan että miksi ne ei nimenneet Ice lakea joksikin muuksi. Wellit oli wellejä(haswell broadwell) ja bridget bridgejä(sandy, ivy). Laketkin olisi saaneet olla lakeja(sky, kaby, coffee, cannon).

Ehkä siellä pelättiin sitä fiilistä mikä noista lakeista olisi jäänyt. "Ai mitä? Neljä iteraatiota samasta arkkitehtuurista? Aika säälittävää." vrt. nyt niillä vaan sattuu olemaan lake päättyinen nimi, ihan uutta tavaraa löytyy kuitenkin.

Hassun hauska idea.

 

[Hessu]

Eipäs ole, vaan nimenomaan pitäisi olla uusi arkkitehtuuri (samaan tapaan uusi kuin skylake oli aikoinaan, tai haswell jne)

Joo, siis tarkoitus oli viitata valmistusprosessiin.

 

[harri]

Jokohan kohta viitsisi päivittää i920 johonkin uudenpaan. Jospa vaikka tulisi jotain oikeasti uutta.

 

[Rabbitman]

Toivottavasti nimi vihjaa, että vihdoinkin jälleen hitsattaisiin noi lämmönlevittäjät.

 

[Kerosiini]

Toivottavasti nimi vihjaa, että vihdoinkin jälleen hitsattaisiin noi lämmönlevittäjät.

Vastaavasti se voisi myös tarkoittaa sitä että vaatii normikäyttöön kuivajäätä

 

[vemkki]

Mielenkiintoisesti Ice Lake on nimetty seuraajaksi 8. sukupolven Core -prosessoreille, huolimatta siitä, että itse päälistauksessa sen mainitaan kuuluvan kyseiseen sukupolveen. Tällä hetkellä tiedetään, että 8. sukupolven Core -prosessorit tulevat sisältämään ainakin Kaby Lake-R- ja Coffee Lake -prosessoreita, mutta mikäli Ice Lake seuraa 8. sukupolvea, on myös Cannonlaken kuuluttava samaan sukupolveen Kaby Lake-R:n ja Coffee Laken kanssa.

Mun mielestä tuo nettisivu ei ole kovin vakuuttava, eli se vähän näyttää siltä, että sitä on päivitelty eri henkilöiden toimesta eri aikoina, eikä jokaiseen yksityiskohtaan voi luottaa.

 

[Hiikeri]

10nm 4C/8T prossu tänne ja heti, 5.5-6.0Ghz jo kiihottaa. Näyttäisi sekin taas peli bencheissä ettei mitkään 10-16 core prossut anna juuri mitään lisä arvoa.

 

[kime1980]

Sama täällä en anna hirveästi lisäarvoa lisä ytimille. Ytimiin tehokkuutta vaan lisää ja juurikin tuo 10nm 4C/8T houkuttaa itseäkin.

 

[KiriGai]

Ihan hyvä että intel tuo myös lisäytimiä mainstremiin, kun viimeiset 5v on ainakin ollut vain 4 core prossuja. Lisäytimiin saadaan toki kelloa kehityksen myötä, tämä myös vaikuttaa hieman siihen miten devit tekee prossuoptimoinnin. Se että laitetaan yksi ydin tekemään töitä ei ole mielestäni se tehokkain tapa, vaan juuri jakaa rasitus monelle ytimelle.

 

[Sepander]

Kyllähän se siltä näyttää, että ytimiä on tulossa vain lisää ja siihen panostetaan myös markkinoinnissa. Kun Pekka Peruskäyttäjä näkee mainoksessa, että tuotteessa x on ziljoona ydintä, niin sen täytyy olla parempi joka sovellukseen ja ostaa sen. Ei sitä kiinnosta IPC-suorituskyky.

 

[zepi]

Se että laitetaan yksi ydin tekemään töitä ei ole mielestäni se tehokkain tapa, vaan juuri jakaa rasitus monelle ytimelle.

On paljon algoritmejä joita on yksinkertaisesti mahdotonta rinnakkaistaa, sillä ne ovat luonteeltaan sarjamuotoisia. Ensin lasketaan asia X, sen jälkeen käytetään X:n tulosta ja lasketaan asia Y ja sen jälkeen lasketaan Y:tä käyttäen Z.

Se monelle ytimelle kuorman jakaminen ei ole mikään helposti tehtävä toimenpide, joka voidaan vaan tehdä sormia napsauttamalla kunhan lopetetaan laiskottelu.

10nm 4C/8T prossu tänne ja heti, 5.5-6.0Ghz jo kiihottaa. Näyttäisi sekin taas peli bencheissä ettei mitkään 10-16 core prossut anna juuri mitään lisä arvoa.

Intelin kalvoissa näkyy selvästi, että 10nm ja 10nm+ ovat alemmalla "transistor performance" lukemalla, kuin 14nm++ prosessi.

Korkeimmat kellot ja single-thread suorituskyky seuraavien parin vuoden aikana tullaan todennäköisesti saamaan 14nm prossuilla.

anandtechiltä suoraan linkattu kuva

 

[Threadripper]

On paljon algoritmejä joita on yksinkertaisesti mahdotonta rinnakkaistaa, sillä ne ovat luonteeltaan sarjamuotoisia. Ensin lasketaan asia X, sen jälkeen käytetään X:n tulosta ja lasketaan asia Y ja sen jälkeen lasketaan Y:tä käyttäen Z.

Se monelle ytimelle kuorman jakaminen ei ole mikään helposti tehtävä toimenpide, joka voidaan vaan tehdä sormia napsauttamalla kunhan lopetetaan laiskottelu.

Monissa tapauksissa voidaan kehittää korvaava algoritmi tai täysin uusi tapa tehdä asia, joka on mahdollista rinnakkaistaa. Jos ei kokonaan niin jossain määrin kuitenkin.

Kyllä se todella monessa tapauksessa on nimenomaan sormia napsauttamalla tehtävä asia kunhan lopetetaan laiskottelu.

Intelin kalvoissa näkyy selvästi, että 10nm ja 10nm+ ovat alemmalla "transistor performance" lukemalla, kuin 14nm++ prosessi.

Korkeimmat kellot ja single-thread suorituskyky seuraavien parin vuoden aikana tullaan todennäköisesti saamaan 14nm prossuilla.

anandtechiltä suoraan linkattu kuva

Kuva näyttää harvinaisen hyvältä Zen2:n suhteen.

 

[deac]

Monissa tapauksissa voidaan kehittää korvaava algoritmi tai täysin uusi tapa tehdä asia, joka on mahdollista rinnakkaistaa. Jos ei kokonaan niin jossain määrin kuitenkin.

Kyllä se todella monessa tapauksessa on nimenomaan sormia napsauttamalla tehtävä asia kunhan lopetetaan laiskottelu.

Kuva näyttää harvinaisen hyvältä Zen2:n suhteen.

Tuskinpa voidaan, olisi tehty jo. Hitaasti etenee eikä mitään valtavaa hyppyä kannata varmaan edes odottaa. Sen arvioiminen kuinka helppoa ja järkevää joku tuollainen on vaatii todella kovaa asiantuntemusta. Onko näihin ottanut kantaa joku tai mieluusti useampi asiantuntija kantaa? Tietotekniikkafoorumeilla on nähty vuosikausia tätä hehkutusta, että lisäytimet ovat jotenkin kova juttu just nyt. Phenom II 6 coreista lähtien nyt ainakin ja niillä mopoilla ei tee enää mitään. Applekin valmistaa puhelimiaan käytännössä kahdella ytimellä vaikka voisi tehdä mitä huvittaa suljetussa ympäristössään. Ja suorituskyky on todella kova.

Zen2 saattaa olla mielenkiintoinen julkaisu mutta valmistustekniikka on erittäin suuri kysymysmerkki. Lupauksia on nähty ennenkin, myöhästytään ja lopulta tuodaan kilpailijaa huonompi tuote markkinoille.

 

[vemkki]

Intelin kalvoissa näkyy selvästi, että 10nm ja 10nm+ ovat alemmalla "transistor performance" lukemalla, kuin 14nm++ prosessi.

Korkeimmat kellot ja single-thread suorituskyky seuraavien parin vuoden aikana tullaan todennäköisesti saamaan 14nm prossuilla.

anandtechiltä suoraan linkattu kuva

Aika mielenkiintoista! Itse asiassa tuo selittäisi, että miksi Cannonlakesta ollaan puhuttu niin vähän. Mitäs jos homma meneekin niin, että Cannonlake tulee vain läppäreille ja muualle, missä tarvitaan erityisen alhaista virrankulutusta? Selittäisi sen, että miksi julkaistaan Coffee Lake 14 nm++ prosessilla. 10nm+:n Icelake olisi sitten ensimmäinen, jolla peitotaan Coffee Lake työpöytäkäytössä.

Edit: Nojoo, kaivoin tuon Anandtechin jutun ja näköjään siinä uumoillaan jotain samansuuntaista, tosin arvelevat Cannonlakenkin tulevan vielä desktopille.

 

[Threadripper]

Tuskinpa voidaan, olisi tehty jo. Hitaasti etenee eikä mitään valtavaa hyppyä kannata varmaan edes odottaa. Sen arvioiminen kuinka helppoa ja järkevää joku tuollainen on vaatii todella kovaa asiantuntemusta. Onko näihin ottanut kantaa joku tai mieluusti useampi asiantuntija kantaa? Tietotekniikkafoorumeilla on nähty vuosikausia tätä hehkutusta, että lisäytimet ovat jotenkin kova juttu just nyt. Phenom II 6 coreista lähtien nyt ainakin ja niillä mopoilla ei tee enää mitään. Applekin valmistaa puhelimiaan käytännössä kahdella ytimellä vaikka voisi tehdä mitä huvittaa suljetussa ympäristössään. Ja suorituskyky on todella kova.

Zen2 saattaa olla mielenkiintoinen julkaisu mutta valmistustekniikka on erittäin suuri kysymysmerkki. Lupauksia on nähty ennenkin, myöhästytään ja lopulta tuodaan kilpailijaa huonompi tuote markkinoille.

Aiemminkin on käsitelty pakkausohjelmien monisäikeistystä varsinkin purkamisessa. Todella helppo toteuttaa jos halua on, ei ole pahemmin näkynyt. Peleissä taasen DirectX on ollut yksi suurimmista monisäikeistyksen rajoittajista, versio 12 tuo vihdoin ongelmaan ratkaisua.

Phenom II X6 on hyvinkin käyttökelpoinen prosessori moniajoon edelleenkin. Kyllä sillä aika paljon tekee sopivassa käytössä.

Kun GlobalFoundriesista puhutaan, valmistustekniikka on aina kysymysmerkki. Ehkä tällä kertaa jopa onnistuvat.

Aika mielenkiintoista! Itse asiassa tuo selittäisi, että miksi Cannonlakesta ollaan puhuttu niin vähän. Mitäs jos homma meneekin niin, että Cannonlake tulee vain läppäreille ja muualle, missä tarvitaan erityisen alhaista virrankulutusta? Selittäisi sen, että miksi julkaistaan Coffee Lake 14 nm++ prosessilla. 10nm+:n Icelake olisi sitten ensimmäinen, jolla peitotaan Coffee Lake työpöytäkäytössä.

Tästähän tulee mieleen AMD:n Zen kalvoista katsotut pylväiden pituudet ja sen perusteella arvioitu suorituskyky. Joka tapauksessa mikäli kalvo paikkaansa pitää ja 2019 puolivälissä tulee jotain parempaa kuin nyt, ei AMD:lla ole suurtakaan hätää.

 

[Hannibal]

10nm 4C/8T prossu tänne ja heti, 5.5-6.0Ghz jo kiihottaa. Näyttäisi sekin taas peli bencheissä ettei mitkään 10-16 core prossut anna juuri mitään lisä arvoa.

Pienempi viivaleveys, joten ei kellottune kauhean korkealle, mutta virrankulutus laskee, eli useampi ytimiset prossat ei throtlaa niin pahasti kuin nykyiset. Ja auttaa taas erityisesti läppäreissä!

 

[peksi]

Monissa tapauksissa voidaan kehittää korvaava algoritmi tai täysin uusi tapa tehdä asia, joka on mahdollista rinnakkaistaa. Jos ei kokonaan niin jossain määrin kuitenkin.

Kyllä se todella monessa tapauksessa on nimenomaan sormia napsauttamalla tehtävä asia kunhan lopetetaan laiskottelu.

Öh se että kehitetään täysin uusi rinnakkainen algoritmi ratkaisemaan aiemmin sarjallinen ongelma nimeomaan on tosi kaukana "sormia napsauttamalla tehtävästä" asiasta...

 

[mango]

Öh se että kehitetään täysin uusi rinnakkainen algoritmi ratkaisemaan aiemmin sarjallinen ongelma nimeomaan on tosi kaukana "sormia napsauttamalla tehtävästä" asiasta...

Nimenomaan, en kyllä tajua mitä tuolla alkuperäisellä kommentilla oikein haettiin. Ongelmaa voi lähestyä tietysti monelta kantilta. Pienten toisistaan riippumattomien toimintojen säikeistäminen ei välttämättä ole kovin vaativa juttu. Isojen kokonaisuuksien säikeistäminen taasen on ihmisille aikaa vievää ja virhealtista hommaa. Sormia napsauttamalla ei kyllä kumpikaan homma etene yhtään.

 

[Threadripper]

Öh se että kehitetään täysin uusi rinnakkainen algoritmi ratkaisemaan aiemmin sarjallinen ongelma nimeomaan on tosi kaukana "sormia napsauttamalla tehtävästä" asiasta...

Sanoin että kehittää uusi algoritmi TAI täysin uusi tapa tehdä asia. Joissakin tapauksissa jälkimmäinen sujuu sormia napsauttamalla.

Nimenomaan, en kyllä tajua mitä tuolla alkuperäisellä kommentilla oikein haettiin. Ongelmaa voi lähestyä tietysti monelta kantilta. Pienten toisistaan riippumattomien toimintojen säikeistäminen ei välttämättä ole kovin vaativa juttu. Isojen kokonaisuuksien säikeistäminen taasen on ihmisille aikaa vievää ja virhealtista hommaa. Sormia napsauttamalla ei kyllä kumpikaan homma etene yhtään.

Monet asiat tehdään kuten tehdään koska niin on aina tehty. Ei mitään tekemistä sillä etteikö asioita voisi tehdä paremmin sormia napsauttamalla, mutta kun X vuotta sitten tehtiin näin niin...

Nimenomaan pienten toisistaan riippumattomien toimintojen säikeistäminen on monessa tapauksessa melko ylitsepääsemätön juttu. Päätellen siitä kuinka vaikea se on saada tehtyä.

 

[peksi]

Monet asiat tehdään kuten tehdään koska niin on aina tehty. Ei mitään tekemistä sillä etteikö asioita voisi tehdä paremmin sormia napsauttamalla, mutta kun X vuotta sitten tehtiin näin niin...

Nimenomaan pienten toisistaan riippumattomien toimintojen säikeistäminen on monessa tapauksessa melko ylitsepääsemätön juttu. Päätellen siitä kuinka vaikea se on saada tehtyä.

Käytännössä triviaali rinnakkaisuus on jo pitkälti hyödynnetty eikä kukaan suorituskykykriittistä kamaa AAA-tasolla nykyään tekevä jätä helppoja hedelmiä roikkumaan. Rinnakkaisuuden tarve ei ole tullut puun takaa, johan sitä "ilmainen lounas on ohi" mantraakin on hoettu jo yli kymmenen vuotta. Pelifirmoilla on ollut pitkään erillisiä R&D yksiköitä jotka ovat rinnakkaisuuttakin pohtineet jo ajat sitten edellisen generaation kanssakin.

Käytännön asiat jotka haittaa rinnakkaisuuden hyödyntämistä peleissä on paljon monimutkaisempia eikä aina edes teknisiä. Unity esimerkiksi itsessään ei ole kovin hyvin rinnakkaistuva perussysteemiensä osalta (parannusta on tullut toki ja tulossa lisää) ja sitä käyttää monesti ihmiset joilla ei ole mitään hajua tehokkaasta koodista eikä Unityn rajapintoja ole tähdätty sellaisille. Tämän yhtälön ratkaiseminen niin että jotkin indiepumput pystyisivät tuottamaan tehokkaita pelejä kivasti on kaukana helposta, oikeastaan mahdoton.

Rinnakkaisuus itse ohjelmoidessa on "uusista" kikoista kuten jostain fiberien käytöstä huolimatta edelleen monesti hankalaa. Pienten yksittäisten operaatioiden rinnakkaistaminen sinällään ei ole myöskään kovin hyödyllistä kun niiden vaihdoksissakin on overheadia, ts. liian pieni kuorma erillisenä taskina on vain tuhlausta. Jos taas kevyttä operaatiota pitää ajaa isolle datasetille niin asiat helpottuu mutta se on taas aika kiva ja inhottavan harvinainen tilanne. Jonkin fysiikkaa jatkuvasti kutsuvan pelilogiikan rinnakkaistaminen törmäystarkistuksineen on jo melkosen vaikea ongelma.

Kaikissa peleissä tulee myös vastaan raha ja aika, toki sitä PC-pelaajaa varten voisi tehdä lisää asioita loputtomiin saakka mutta kaikki nykytilasta eteenpäin ei vaan ole niin helppoa ja halpaa. Ts. ei siellä mitkään devaajat katso että oho nyt julkaistiin uus serveriprossu jossa ytimiä riittää, napsautellaas sormia pari viikkoa niin tulee perffiä ovista ja ikkunoista. Rinnakkaisuus varmasti lisääntyy edelleen ja graffa-APIen muutoksista on apua mutta en jäisi pidättelemään hengitystä.

 

[Threadripper]

Käytännössä triviaali rinnakkaisuus on jo pitkälti hyödynnetty eikä kukaan suorituskykykriittistä kamaa AAA-tasolla nykyään tekevä jätä helppoja hedelmiä roikkumaan. Rinnakkaisuuden tarve ei ole tullut puun takaa, johan sitä "ilmainen lounas on ohi" mantraakin on hoettu jo yli kymmenen vuotta. Pelifirmoilla on ollut pitkään erillisiä R&D yksiköitä jotka ovat rinnakkaisuuttakin pohtineet jo ajat sitten edellisen generaation kanssakin.

Käytännön asiat jotka haittaa rinnakkaisuuden hyödyntämistä peleissä on paljon monimutkaisempia eikä aina edes teknisiä. Unity esimerkiksi itsessään ei ole kovin hyvin rinnakkaistuva perussysteemiensä osalta (parannusta on tullut toki ja tulossa lisää) ja sitä käyttää monesti ihmiset joilla ei ole mitään hajua tehokkaasta koodista eikä Unityn rajapintoja ole tähdätty sellaisille. Tämän yhtälön ratkaiseminen niin että jotkin indiepumput pystyisivät tuottamaan tehokkaita pelejä kivasti on kaukana helposta, oikeastaan mahdoton.

Onhan se kehitys ollut vaikeaa mm. DirectX:n takia. Mikäli nuo kuvat pitävät paikkaansa, on ennen DX12:a ollut aika tuskaa monisäikeistää koska yksi threadi hallitsee:

Indiepumppujen pelit harvoin edes tarvitsevat kovin montaa ydintä ja sen kyllä ymmärtää ettei pienellä budjetilla pysty kaikkea tekemään varsinkin jos käytössä on jonkinlainen SDK, joka toimii miten toimii.

Rinnakkaisuus itse ohjelmoidessa on "uusista" kikoista kuten jostain fiberien käytöstä huolimatta edelleen monesti hankalaa. Pienten yksittäisten operaatioiden rinnakkaistaminen sinällään ei ole myöskään kovin hyödyllistä kun niiden vaihdoksissakin on overheadia, ts. liian pieni kuorma erillisenä taskina on vain tuhlausta. Jos taas kevyttä operaatiota pitää ajaa isolle datasetille niin asiat helpottuu mutta se on taas aika kiva ja inhottavan harvinainen tilanne. Jonkin fysiikkaa jatkuvasti kutsuvan pelilogiikan rinnakkaistaminen törmäystarkistuksineen on jo melkosen vaikea ongelma.

Kaikissa peleissä tulee myös vastaan raha ja aika, toki sitä PC-pelaajaa varten voisi tehdä lisää asioita loputtomiin saakka mutta kaikki nykytilasta eteenpäin ei vaan ole niin helppoa ja halpaa. Ts. ei siellä mitkään devaajat katso että oho nyt julkaistiin uus serveriprossu jossa ytimiä riittää, napsautellaas sormia pari viikkoa niin tulee perffiä ovista ja ikkunoista. Rinnakkaisuus varmasti lisääntyy edelleen ja graffa-APIen muutoksista on apua mutta en jäisi pidättelemään hengitystä.

Eiköhän se ongelma ollut enemmän noissa kuvissa näkyvä. Eli yksi threadi rajoittaa nopeuden tietylle eikä silloin auta vaikka muu osa olisi kuinka monisäikeistettyä. Eräät enginet, kuten RoadHog (Hard Reset, Shadow Warrior) toimii loistavasti myös DirectX 9:sta huolimatta, myöhemmissä versioissa DirectX 11. Kehittäjä sanoi jossakin haastattelussa ettei DX9 versio ole monisäikeistetty. Fysiikka saattaa ollakin Melkein sanoisin ettei kovinkaan moni valittaisi monisäikeistyksen puutteesta mikäli toimisivat yhtä hyvin kuin Roadhog DirectX 9:lle.

On sellaisiakin pelejä jotka käyttävät kaikki ytimet mitä koneesta löytyy (Football Manager sarja teki sen jo 2005 paikkeilla). Myönnettäköön että helposti säikeistettävä (paljon toisistaan riippumattomia tapahtumia) mutta se on tehty eikä jääty selittämään kuinka ei jaksa ja muuta vastaavaa. Eikä monessa muussakaan hidastempoisessa pelissä olisi yhtään sen vaikeampaa tehdä kunnollista monisäikeistystä, ei vaan viitsitä. En itsekään usko mitään huippumullistavaa tapahtuvan nopeatempoisissa peleissä enenn kuin pelien tekoon tarvittavat työkalut saadaan tasolle jossa monisäikeistys tulee huomattavasti nykyistä enemmän automaattisesti.

Pääpointti: monet pelit jotka saisi helposti tukemaan monisäikeistystä eivät sitä tue. Onneksi ainakin yksi poikkeus vahvistaa ettei se ole ollut edes viime vuosikymmenellä mitenkään ylivoimainen homma.

 

[peksi]

Onhan se kehitys ollut vaikeaa mm. DirectX:n takia. Mikäli nuo kuvat pitävät paikkaansa, on ennen DX12:a ollut aika tuskaa monisäikeistää koska yksi threadi hallitsee:

Graffarajapintojen kehitys auttaa sillon kuin pullonkaulana on graffapuoli mikä ei ole suinkaan aina. Rajapintojen mukana tulee siis sekä kuorman väheneminen (ylimääräisen validaation kutistuminen per draw call kun voidaan validoida useamman kutsun jakava tila kerralla) ja jäljelle jäävä kuorma saadaan rinnakkaistettua paremmin (+ muita etuja suorasta kontrollista). Konsolirajapinnoista, ainakin Sonyn puolelta tuttua kamaa jo ennestään.

Pullonkaulat graffassakaan ei ole niin yksinkertaisia: ongelmia voi aiheuttaa itse graffakuorman laskentaintensiivisyys kun vaikka isketään 4k resoluutio käyttöön tai varsinaisen pipelinen kuorma kun lasketaan kaikki minimiin tehokkaalla GPU:lla jolloin piirtoja saadaan puskettua nopeaan tahtiin ja submittien yms. kustannukset suhteessa itse GPU:n vaatimaan laskenta-aikaan kasvaa tietenkin.

Lisäksi ennen kuin päästään edes kutsumaan mitään graffa-APIa enginen pitää etsiä jokaisesta näkymästä kaikki oikeasti näkyvä kama (mikä joillain engineillä tarkottaa käytännössä CPU-pohjasta softarasterointia kunhan ensin sopivat mahdolliset kohteet on löydetty) ja varmistaa että data on oikeassa muodossa riippuvuuksineen. Näkymiäkin on yleensä useampi kuin vain pelaajan silmä, esim. varjostus vaatii yksinkertaisen render passin per varjostava valo mikä taas lisää kuormaa.

Lisämonimutkaisuutta tuo sekin että rakenteet ei ole välttämättä mitenkään graffalle pelkästään tarkoitettuja. Esim. jotkin deformaatiot tai jokin tuulen vaikutus vaatii myös fysiikkamallin pitämistä ajan tasalla ja systeemi jossa rinnakkaistettu pelilogiikka toimii yhteistyössä rinnakkaistetun fysiikkalaskennan kanssa ja lopputuloksen rendaa rinnakkainen rendaaja joka submittaa useasta taskista rinnakkaiselle graffarajapinnalle on jo eri galaksissa kuin sormia napsauttamalla tehty perffitwiikki

Simulaatio menee usein fiksatulla tickratella jo moninpelin synkronoinnin yms takia joten sieltä tuleva kuorma ei välttämättä kasva suhteessa vaikka fps nousisi kahteen sataan mutta aika hyvin sieltäkin riittää kuormaa jossain GTA:n tai Witcherin kaltaisessa pelissä.

Eräät enginet, kuten RoadHog (Hard Reset, Shadow Warrior) toimii loistavasti myös DirectX 9:sta huolimatta, myöhemmissä versioissa DirectX 11. Kehittäjä sanoi jossakin haastattelussa ettei DX9 versio ole monisäikeistetty. Fysiikka saattaa ollakin Melkein sanoisin ettei kovinkaan moni valittaisi monisäikeistyksen puutteesta mikäli toimisivat yhtä hyvin kuin Roadhog DirectX 9:lle.

Niin, eli pullonkaula on jossain muualla sitten tai kuormaa on kokonaisuutena vähän modernille atk:lle.

On sellaisiakin pelejä jotka käyttävät kaikki ytimet mitä koneesta löytyy (Football Manager sarja teki sen jo 2005 paikkeilla). Myönnettäköön että helposti säikeistettävä (paljon toisistaan riippumattomia tapahtumia) mutta se on tehty eikä jääty selittämään kuinka ei jaksa ja muuta vastaavaa. Eikä monessa muussakaan hidastempoisessa pelissä olisi yhtään sen vaikeampaa tehdä kunnollista monisäikeistystä, ei vaan viitsitä.

Osa simuloitavista ongelmista on totta kai helpompia, en tiedä yhtään miten Football Manager käytännössä simuloi tilaa mutta en ihmettele jos se on helpompi kuin case minkä mainitsin.

Pääpointti: monet pelit jotka saisi helposti tukemaan monisäikeistystä eivät sitä tue. Onneksi ainakin yksi poikkeus vahvistaa ettei se ole ollut edes viime vuosikymmenellä mitenkään ylivoimainen homma.

En ihan löytänyt tästä viestistä sitä casea mikä olisi helppo ratkaista jo nyt rinnakkaisesti mutta kehittäjät ei vain jaksa tai viitsi

 

[Threadripper]

Graffarajapintojen kehitys auttaa sillon kuin pullonkaulana on graffapuoli mikä ei ole suinkaan aina. Rajapintojen mukana tulee siis sekä kuorman väheneminen (ylimääräisen validaation kutistuminen per draw call kun voidaan validoida useamman kutsun jakava tila kerralla) ja jäljelle jäävä kuorma saadaan rinnakkaistettua paremmin (+ muita etuja suorasta kontrollista). Konsolirajapinnoista, ainakin Sonyn puolelta tuttua kamaa jo ennestään.

Pullonkaulat graffassakaan ei ole niin yksinkertaisia: ongelmia voi aiheuttaa itse graffakuorman laskentaintensiivisyys kun vaikka isketään 4k resoluutio käyttöön tai varsinaisen pipelinen kuorma kun lasketaan kaikki minimiin tehokkaalla GPU:lla jolloin piirtoja saadaan puskettua nopeaan tahtiin ja submittien yms. kustannukset suhteessa itse GPU:n vaatimaan laskenta-aikaan kasvaa tietenkin.

Lisäksi ennen kuin päästään edes kutsumaan mitään graffa-APIa enginen pitää etsiä jokaisesta näkymästä kaikki oikeasti näkyvä kama (mikä joillain engineillä tarkottaa käytännössä CPU-pohjasta softarasterointia kunhan ensin sopivat mahdolliset kohteet on löydetty) ja varmistaa että data on oikeassa muodossa riippuvuuksineen. Näkymiäkin on yleensä useampi kuin vain pelaajan silmä, esim. varjostus vaatii yksinkertaisen render passin per varjostava valo mikä taas lisää kuormaa.

Lisämonimutkaisuutta tuo sekin että rakenteet ei ole välttämättä mitenkään graffalle pelkästään tarkoitettuja. Esim. jotkin deformaatiot tai jokin tuulen vaikutus vaatii myös fysiikkamallin pitämistä ajan tasalla ja systeemi jossa rinnakkaistettu pelilogiikka toimii yhteistyössä rinnakkaistetun fysiikkalaskennan kanssa ja lopputuloksen rendaa rinnakkainen rendaaja joka submittaa useasta taskista rinnakkaiselle graffarajapinnalle on jo eri galaksissa kuin sormia napsauttamalla tehty perffitwiikki

Simulaatio menee usein fiksatulla tickratella jo moninpelin synkronoinnin yms takia joten sieltä tuleva kuorma ei välttämättä kasva suhteessa vaikka fps nousisi kahteen sataan mutta aika hyvin sieltäkin riittää kuormaa jossain GTA:n tai Witcherin kaltaisessa pelissä.

Hauska juttu, puhuin moniydintuesta yleisellä tasolla ja seuraavaksi ollaankin nopeatempoisissa peleissä. Sattuneesta syystä unohdin mitä tähän piti kirjoittaa.

Niin, eli pullonkaula on jossain muualla sitten tai kuormaa on kokonaisuutena vähän modernille atk:lle.

Sanoisin ennemmin enginen olevan loistavasti tehty.

Osa simuloitavista ongelmista on totta kai helpompia, en tiedä yhtään miten Football Manager käytännössä simuloi tilaa mutta en ihmettele jos se on helpompi kuin case minkä mainitsin.

Eiköhän tuohon väittelyketjussa palata.

En ihan löytänyt tästä viestistä sitä casea mikä olisi helppo ratkaista jo nyt rinnakkaisesti mutta kehittäjät ei vain jaksa tai viitsi

Hidastempoiset pelit joissa toisistaan riippumattomia tapahtumia, Civilization-sarja esim. Sitten on myös pelien lataustauot, jotkut pelit pakkaavat kunnolla ja purkavat latausvaiheessa. Poikkeus tästäkin löytyy, osa Call of Dutyista purkaa kaikilla säikeillä mitä löytyy.

 

[peksi]

Hauska juttu, puhuin moniydintuesta yleisellä tasolla ja seuraavaksi ollaankin nopeatempoisissa peleissä. Sattuneesta syystä unohdin mitä tähän piti kirjoittaa.

Eihän tuo ota mitään kantaa nopeatempoisiin peleihin? Samanlaiset ongelmat tulee 3d graffaa käyttävissä peleissä vastaan muutenkin.

Sanoisin ennemmin enginen olevan loistavasti tehty.

Hidastempoiset pelit joissa toisistaan riippumattomia tapahtumia, Civilization-sarja esim. Sitten on myös pelien lataustauot, jotkut pelit pakkaavat kunnolla ja purkavat latausvaiheessa. Poikkeus tästäkin löytyy, osa Call of Dutyista purkaa kaikilla säikeillä mitä löytyy.

Ei "hidastempoisuus" itsessään kerro mitään siitä onko helppo rinnakkaistaa jos simulaatiossa on esim. vain rekursiivinen ratkaisu jne.

 

[Threadripper]

Eihän tuo ota mitään kantaa nopeatempoisiin peleihin? Samanlaiset ongelmat tulee 3d graffaa käyttävissä peleissä vastaan muutenkin.

Strategiapelissä voi olla 3D grafiikkaa ja haastetta ovat täysin erilaiset kuin nopeatempoisissa peleissä.

Jos pitää rankata putkijuoksuihin sopivat enginet sillä perusteella paljonko vaatii tehoja suhteessa siihen miten paljon ruudulla tapahtuu ja kuinka hyvältä näyttää, rankkaisin Roadhogin "ykkösversion" ylivoimaisesti parhaaksi. Todella vaikea saada tahmaamaan vaikka ruudulla tapahtuu ja single thread nopeus luokkaa AMD FX. Roadhog käytännössä osoittaa ettei homma ole tehoista kiinni vaan siitä miten niitä käytetään. Kakkosversion pitäisi olla vielä parempi, en ole ehtinyt testailemaan vielä.

Ei "hidastempoisuus" itsessään kerro mitään siitä onko helppo rinnakkaistaa jos simulaatiossa on esim. vain rekursiivinen ratkaisu jne.

Ei pelkästään mutta yleensä hidastempoisissa peleissä on paljon toisistaan riippumattomia tapahtumia, jotka on erittäin helppo rinnakkaistaa. Ei tarvita muuta kuin laskea ne yhden säikeen sijasta useammalla säikeellä.

 

[peksi]

Ei pelkästään mutta yleensä hidastempoisissa peleissä on paljon toisistaan riippumattomia tapahtumia, jotka on erittäin helppo rinnakkaistaa. Ei tarvita muuta kuin laskea ne yhden säikeen sijasta useammalla säikeellä.

No niinpä. Ei tarvitse kuin laskea yhden säikeen sijaan useammalla

 

[Threadripper]

No niinpä. Ei tarvitse kuin laskea yhden säikeen sijaan useammalla

Tämä olikin keskustelun pääpointti, koska monella säikeellä laskeminen on monessa tapauksessa yllättävän vaikeaa (tai sitten ei vaan viitsitä)