AMD esitteli mahdollista ratkaisua usean pikkupiirin MCM-piirien ongelmiin

  • Keskustelun aloittaja Keskustelun aloittaja Kaotik
  • Aloitettu Aloitettu

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
22 377
amd-chiplet-mcm-20180628.jpg



Ainakin AMD, Intel ja NVIDIA ovat kukin omilla tahoillaan tutkineet parhaita tapoja yhdistellä useita piirejä samalle alustalle. Useamman piirin yhdistäminen yhdelle alustalle mahdollistaa selvästi nopeamman kommunikaation piirien välillä, kuin täysin erilliset piirit.

IEEE:n Spectrum-sivustolla on julkaistu uusi artikkeli, jossa AMD kertoo omista tutkimuksistaan, löytämistään ongelmista ja niiden mahdollisista ratkaisuista pikkupiireistä (chiplet) koostuvissa MCM-piireissä.

AMD:n mukaan yksi ongelmista sen tutkimassa lähestymistavassa olisivat mahdolliset ruuhkatilanteet, kun lukuisat piirit erillään suunniteltavat piirit lähettävät interposereihin rakennettuihin verkkoihin omaa dataansa. Ongelma voitaisiin ratkaista suunnittelemalla ja optimoimalla kaikki pikkupiirit yhdessä, mutta tämä rajoittaisi niiden kehitysmahdollisuuksia ja hidastaisi uusien tuotteiden luontia.

Yhdeksi potentiaaliseksi vaihtoehdoksi yhtiö on kehittänyt ratkaisun, jossa interposeriin rakennettu verkon säännöt rajoittaisivat datan liikkumissuuntia ja mahdollisia sisään- ja ulostuloreittejä. Ratkaisun kerrotaan käytännössä poistavan mahdolliset ruuhkautumiset, sillä kukin pikkupiireistä näkisi muut verkkoon kytketyt piirit vain yhtenä pisteenä verkossa. Tällöin uutta pikkupiiriä kehitettäessä insinöörien ei tarvitsisi miettiä, miten se kytkeytyy esimerkiksi muhin grafiikka-, prosessori ja muistipiireihin samassa interposeriin rakennetussa verkossa. Ratkaisu toisaalta omalta osaltaan monimutkaistaa interposeriin rakennettavan verkon rakennetta.

Lähde: IEEE Spectrum

Huom! Foorumiviestistä saattaa puuttua kuvagalleria tai upotettu video.

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

Palautelomake: Raportoi kirjoitusvirheestä
 
Viimeksi muokattu:
Hmm kuvassa on yksi CPU siru neljä GPU sirua ja 8 muistiväylää ... Hmm jos AMD tekisi jonku tuon tyylisen piirin niin se voisi ola suora kilpailija Nvidian isoille Voltilta IA piireille.
 
Jotenkin tulis mieleen, että olisi järkevämpää rakentaa tollanen astetta järeämmistä APU-prossuista ja siihen kourallinen HBM-stackia, mutta en ole insinööri.
 
Tuommoinen voisi olla aika mielenkiintoinen, joku 4kpl RX580 tyylisiä GPUita ja siihen tuollainen 8 ydin ryzeni saman interposerin päälle, tuohan voisi olla kooltaankin jo sen verran iso, että sitä pystyy jollain kunnon jäähyllä pitämään viileänä. :P
 
Tuollaseen kuutioon kun laskee 400 wattia niin mokoma laitos sulaa sisältäpäin :)
 
Tuommoinen voisi olla aika mielenkiintoinen, joku 4kpl RX580 tyylisiä GPUita ja siihen tuollainen 8 ydin ryzeni saman interposerin päälle, tuohan voisi olla kooltaankin jo sen verran iso, että sitä pystyy jollain kunnon jäähyllä pitämään viileänä. :P
Toimii vain niin, että tuolla voisi yhdistää 4 Ryzeniä ja yhden graffapiirin. Käyttikset ei tue usean graffapiirin yhdistelmiä, joten ongelmat on sanat kuin sli ja crossfire tapauksissa. Tuki pitää ohjelmoida joka ohjelmalle erikseen, eli ei maksa vaivaa...
 
Toimii vain niin, että tuolla voisi yhdistää 4 Ryzeniä ja yhden graffapiirin. Käyttikset ei tue usean graffapiirin yhdistelmiä, joten ongelmat on sanat kuin sli ja crossfire tapauksissa. Tuki pitää ohjelmoida joka ohjelmalle erikseen, eli ei maksa vaivaa...
Ei pidä paikkaansa alkuunsakaan. Ei käyttöjärjestelmän tarvitse "tukea" montaa grafiikkapiiriä. Ajurit voivat piilottaa monen grafiikkapiirin toteutuksen ja käyttöjärjestelmä ei tästä välitä. Ohjelmat jatkavat samojen rajapintojen käyttämistä ja nekään eivät välitä asiasta. Monen grafiikkapiirin toteutus voidaan piilottaa myös rautatasolle. Nämä ei ole edes asioita, mistä voi väitellä, joten ehkä kannattaa jättää tuollaiset mutuilut pois jatkossa...
 
Viimeksi muokattu:
Ei pidä paikkaansa alkuunsakaan. Ei käyttöjärjestelmän tarvitse "tukea" montaa grafiikkapiiriä. Ajurit voivat piilottaa monen grafiikkapiirin toteutuksen ja käyttöjärjestelmä ei tästä välitä. Ohjelmat jatkavat samojen rajapintojen käyttämistä ja nekään eivät välitä asiasta. Monen grafiikkapiirin toteutus voidaan piilottaa myös rautatasolle. Nämä ei ole edes asioita, mistä voi väitellä, joten ehkä kannattaa jättää tuollaiset mutuilut pois jatkossa...

Tuollaisen väylähässäkänhän voi nykyään rakentaa jopa niin, että nuo grafiikkapiirit ja prosessorit näkyvät vain yhtenä fyysisenä kokonaisuutena softalle ja paketin sisäinen rauta ja "softa" jakaa työtaakan miten tarve vaatii, tuollaisia ratkaisuja ei vain vielä ole juurikaan, koska tuollainen koontipiiri tms. lisää latensseja todella paljon, mutta jos vaikka AMD jossain vaiheessa saa toimimaan jonkinlaisen keskusälyn pienellä latenssilla sen latenssin aiheuttamaa viivettä voidaan kompensoida laittamalla lisää ytimiä GPUhun ja CPUhun.

Kysehän on lähinnä siitä, että milloin tekniikka on niin kypsää, että heittämällä 4x pientä GPUta ja vaikka 4x moniydin CPUta saadaan teho-hinta-latenssisuhde sellaiseksi, että tuollainen on kannattavampi tehdä kuin isojen erillisten piirien suunnittelu. Jossain tulevaisuudessa kun tuollainen paketti toimii ja sisältää tosiaan myös HBM muistit, niin pääsemme oikeasti siihen, että tietokone mahtuu erittäin pieneen tilaan kun ainoat tarvittavat asiat tuollaisen APUn lisäksi on liitäntäportit, tallennustila ja virtalähde. toki jäähdytys tulee aiheuttamaan haasteita, mutta kun koko paketin saa balansoitua moisesta tulee hukkalämpöä varmaankin joku alle 300W, jonka saa kyllä nesteellä poistettua ihan kiitettävän helposti, kunhan nuo kaikki levitetään riittävän isolle alalle ja käytetään oikeita materiaaleja vähentämään termistä vastusta.
 
Toimii vain niin, että tuolla voisi yhdistää 4 Ryzeniä ja yhden graffapiirin. Käyttikset ei tue usean graffapiirin yhdistelmiä, joten ongelmat on sanat kuin sli ja crossfire tapauksissa. Tuki pitää ohjelmoida joka ohjelmalle erikseen, eli ei maksa vaivaa...
Ei pidä paikkaansa alkuunsakaan. Ei käyttöjärjestelmän tarvitse "tukea" montaa grafiikkapiiriä. Ajurit voivat piilottaa monen grafiikkapiirin toteutuksen ja käyttöjärjestelmä ei tästä välitä. Ohjelmat jatkavat samojen rajapintojen käyttämistä ja nekään eivät välitä asiasta. Monen grafiikkapiirin toteutus voidaan piilottaa myös rautatasolle. Nämä ei ole edes asioita, mistä voi väitellä, joten ehkä kannattaa jättää tuollaiset mutuilut pois jatkossa...
Se ei tainne olla ihan noin helppoa...
AMD varmisti Navin olevan perinteinen GPU, aika ei ole kypsä useamman chipletin GPU:lle

Ainakaan AMD itsensä mukaan...
AMD’s Navi will be a traditional monolithic GPU, not a multi-chip module
 
Viimeksi muokattu:
Se ei tainne olla ihan noin helppoa...
Nyt sanot, että ei taida olla helppoa. Helppoudesta ei kukaan olekaan puhunut, vaan siitä onko mahdollista jo nykyisellä teknologialla. Kyllä on.

Toimii vain niin, että tuolla voisi yhdistää 4 Ryzeniä ja yhden graffapiirin. Käyttikset ei tue usean graffapiirin yhdistelmiä, joten ongelmat on sanat kuin sli ja crossfire tapauksissa. Tuki pitää ohjelmoida joka ohjelmalle erikseen, eli ei maksa vaivaa...
Tässä vanhemmassa postauksessa väität suoraan, että ei ole mahdollista. Todellisuudessa esim. neljän grafiikkapiirin toteutus voidaan piilottaa loogisesti minkä tahansa standardin rajapinnan taakse (rauta tai ohjelmistorajapinta), niin että se käyttäytyy samoin kuin yhden grafiikkapiirin toteutus.

Ongelmat näissä monen piirin näyttiksissä ovat ihan muut asiat kuin keksityt yhteensopivuusongelmat.
 
Nyt sanot, että ei taida olla helppoa. Helppoudesta ei kukaan olekaan puhunut, vaan siitä onko mahdollista jo nykyisellä teknologialla. Kyllä on.


Tässä vanhemmassa postauksessa väität suoraan, että ei ole mahdollista. Todellisuudessa esim. neljän grafiikkapiirin toteutus voidaan piilottaa loogisesti minkä tahansa standardin rajapinnan taakse (rauta tai ohjelmistorajapinta), niin että se käyttäytyy samoin kuin yhden grafiikkapiirin toteutus.

Ongelmat näissä monen piirin näyttiksissä ovat ihan muut asiat kuin keksityt yhteensopivuusongelmat.

Sorry. Taisin sanoa siinä postauksessa että se vaatii erikseen ajurien kirjoittamista kullekkin ohjelmalle, kuten sli ja crosfire tapauksissa. Eli kun köyttis ei tue suoraan useaa grafiikkapiiriä, niin grafiikka-ajureiden kirjoittajien pitää mahdollistaa se aina erikseen kullekkin sovellutukselle.
Käyttöjärjestelmät sen sijaan ovat jo pitkään tukeneet usean cpu:n käyttöä, jolloinka itse käyttöjärjestelmä huolehtii tehtävien jakamisesta eri prosessorien kesken.
Eli jos ja kun Linux, Windows jne käyttöjärjestelmät alkavat suoraan tukea useamman eri grafiikkapiirin käyttämistä ja jakaa tehtäviä niiden kesken useamman gpu:n yhdistelmät tulevat käyttökelpoisemmiksi verrattuna monoliittipiireihin.
Eli on vähän eri asia onko jokin mahdollista vs järkevää tällä hetkellä. Ja ainakin AMDn itsensä mukaan se ei lähinnä ole järkevää ainakaan toistaiseksi.
Toivottavasti useamman pikkupiirin yhdistäminen tulee helpommaksi ajan myötä. Se antaisi valmistajille vaihtoehtoisen tavan tuottaa hinnaltaan sopivia ja silti riittävän tehokkaita ratkaisuja. Usean eri asiaa keskittyvän toiminnan piireihin tämä jompäteekin, samoin kuin useamman cpu:n tapaukseen.
 
Viimeksi muokattu:
Sorry. Taisin sanoa siinä postauksessa että se vaatii erikseen ajurien kirjoittamista kullekkin ohjelmalle, kuten sli ja crosfire tapauksissa. Eli kun köyttis ei tue suoraan useaa grafiikkapiiriä, niin grafiikka-ajureiden kirjoittajien pitää mahdollistaa se aina erikseen kullekkin sovellutukselle.
Käyttöjärjestelmät sen sijaan ovat jo pitkään tukeneet usean cpu:n käyttöä, jolloinka itse käyttöjärjestelmä huolehtii tehtävien jakamisesta eri prosessorien kesken.
Eli jos ja kun Linux, Windows jne käyttöjärjestelmät alkavat suoraan tukea useamman eri grafiikkapiirin käyttämistä ja jakaa tehtäviä niiden kesken useamman gpu:n yhdistelmät tulevat käyttökelpoisemmiksi verrattuna monoliittipiireihin.
Eli on vähän eri asia onko jokin mahdollista vs järkevää tällä hetkellä. Ja ainakin AMDn itsensä mukaan se ei lähinnä ole järkevää ainakaan toistaiseksi.
Toivottavasti useamman pikkupiirin yhdistäminen tulee helpommaksi ajan myötä. Se antaisi valmistajille vaihtoehtoisen tavan tuottaa hinnaltaan sopivia ja silti riittävän tehokkaita ratkaisuja. Usean eri asiaa keskittyvän toiminnan piireihin tämä jompäteekin, samoin kuin useamman cpu:n tapaukseen.
Ei se käyttiksestä ole kiinni ja käyttikset kyllä tukevat useampaa grafiikkapiiriä, ennen käyttistä vastaan tulee ajurit jotka tukee maksimissaan tiettyä määrää (en muista ulkoa lukuja, jotain 8 - 12 taisi olla). "Käyttiksen tuki" ei myöskään vaikuta siihen ajuripuoleen, eikä kyse ole mistään SLI/CF-seteistä mitä noiden kanssa arvotaan.
 
Aaa.... sitten ymmärsin seuraavan väärin

- - - - - - - - - -
Game developers don’t want to spend the necessary resources to code their games specifically to work with a multi-GPU array with a miniscule install base, and that would be the same with an MCM design.

“To some extent you’re talking about doing CrossFire on a single package,” says Wang. “The challenge is that unless we make it invisible to the ISVs [independent software vendors] you’re going to see the same sort of reluctance.

“We’re going down that path on the CPU side, and I think on the GPU we’re always looking at new ideas. But the GPU has unique constraints with this type of NUMA [non-uniform memory access] architecture, and how you combine features... The multithreaded CPU is a bit easier to scale the workload. The NUMA is part of the OS support so it’s much easier to handle this multi-die thing relative to the graphics type of workload.”
 
The challenge is that unless we make it invisible to the independent software vendors you’re going to see the same sort of reluctance."
Tuossa nimenomaan viitataan siihen, että ohjelmistokehittäjät voisivat käyttää vanhoja olemassa olevia rajapintoja ja ne vain maagisesti toimivat. Eli pusketaan vanhaan rajapintaan 3D-mallit, tekstuurit ja muut roippeet ja käytetään olemassa olevia piirtokutsuja ja maagisesti kone käyttäisi konepellin alla useaa näyttispiiriä. Ohjelmoijan ei siis tarvitsisi tietää konepellin alla olevasta toteutuksesta.

En tiedä mitenkä paljon tiedät ohjelmistokehityksestä tai rautasuunnittelusta, mutta varmasti rajapinnoista tiedät jotain. Esim. pullonpalautuskoneessa on yksinkertainen rajapinta. Rajapinta on syöttöaukko, jonne työnnät pulloja. Jos työnnät liian nopeasti, niin kone piippaa ja menee jumiin. Jos tuollaista palautuskonetta modaisi ja tekisi siihen koneen syöttöpäähän Y-haaran ja tuplaisi lukulaitteet niin koneeseen voisi syöttää pulloja kaksikertaa nopeammin ilman, että se menisi tukkoon. Koneen rajapinta ei muuttuisi, vaan sitä käytettäisiin edelleenkin samoin kuin aiemminkin. Uudistus olisi näkymätön koneen käyttäjälle. Koneen syöttönopeus voitaisiin tuplata myös lisäämällä siihen toinen syöttöaukko, mutta voit kuvitella miten hölmöltä tuntuisi syöttää pulloja kahteen aukkoon. Rajapinnan vaihtaminen aiheuttaa sen, että käyttäjän pitää muuttaa tapojaan.

Samalla tavalla tietokoneen rauta ja softakerroksiin voidaan toteuttaa alemmalle tasolle asioita, jotka mahdollistavat vanhojen rajapintojen käyttämisen, mutta konepellin alla voikin olla vaikka MCM-tekniikalla rakennettu näyttis. Koska rajapintoja ei vaihdettu, niin myös vanhat ohjelmatkin toimivat kuten ennenkin.
 
Toki, mutta siinä sanotaan etteivät ohjelmoijat viitsi, koska se vaatii lisätöitä. Mahdollistaahan se toki on, mutta ei ohjelmoijalle ”näkymätöntä”.
 

Uusimmat viestit

Statistiikka

Viestiketjuista
257 000
Viestejä
4 465 826
Jäsenet
73 879
Uusin jäsen
Torvelo

Hinta.fi

Back
Ylös Bottom