Új hozzászólás Aktív témák
-
Ahhh, my God.
#59 sh4d0w: Szerintem még két dolog befolyásolja ezt. A párhuzamosítás nagyon kifizetődő, főleg ha grafikáról beszélünk. Az ARM komoly fenyegetést jelent már minden területen az x86-ra.
Mindkét okhoz kötődik, hogy a párhuzamosítással villámgyorsan és energia-hatékonyan lehet műveleteket végezni.
Ráadásul kis energiaigényű magokkal mindenkit ki lehet szolgálni, a telefonoktól a szerverekig, mindössze azt kell meghatározni, mennyi kell belőle. -
-
MaUser
addikt
Értem így világos, bár ez nem app logic, hanem sima sync overhead, aminek aztán semmi köze magához az app logic-hoz.
@Loha: lásd fent, az ábra vacak, attól függetlenül, hogy ők írják (vagy íratják...) dx12-őt.
Szerk: Bár gondolom a sync overhead-t nem akarták felírni, mert elég hülyén venné ki magát, hogy ugyan eddig miért nem így csinálták és miért most jöttek rá, hogy jé hát a szálak között sync olyan vacak, hogy megeszi a cpu 20-30%-át önmagában.
-
Abu85
HÁZIGAZDA
DX12-ben nincs sync point. Ettől csökken az app logic ideje ugyanannyi számítás mellett. Ez az oka, hogy ezek a low-level API-k elméletileg végleten mennyiségű threaden képesek futni. Egymástól teljesen elkülönülten dolgoznak, és semmiféle szinkronizáció nincs a szálak között.
-
Loha
veterán
Ha megnézzük ezt az MS által készített ábrát (DX11 felül, DX12 alul):
Forrás.Akkor látható, hogy DX12 a DX11-hez képest jelentősen csökkenti az 1 CPU magra jutó terhelést, de nem szünteti meg teljesen, tehát DX12 alatt is egy mag nagyobb terhelést fog kapni mint a többi, és annak az egy magnak a teljesítménye fogja limitálni a proci DX12 alatti összteljesítményét.
Tehát SZVSZ nem változik semmi, továbbra is az a proci lesz a jobb választás, amelyik a nagyobb összteljesítményt nyújt, ugyan annyi vagy kevesebb maggal. -
Jack@l
veterán
Intel szerintem nem a consumer piacot célozta meg vele, hanem a kutatós részleget. Nekik sok szálas szimulációkban jól jöhet, mikor nem tudnak leprogramozni valamit gpgpu-ra(eleve aki nem informatikus az még az erősen típusos nyelvekkel se szeret bajlódni). Tehát ahova nagyon sok szál kell és x86, oda lesz jó.
A játékfejlesztés tipikusan nem az az állatfaj. -
leviske
veterán
Az APU-ban található IGP nem magának adna parancsot, hanem a dGPU-nak és értelmezésem szerint erre is lett utalás téve a cikk végén. Korábban is volt róla szó, hogy a GCN képes lehet (később, vagy akár most? arra nem emlékszem) magának parancsot kiosztani.
Azt meg tudom, hogy a MIC nem GPU mellé lett tervezve, de ha a cikkben ecsetelt irányba menne el a piac, akkor sokkal közelebb kerülhetne vele a consumer piachoz az Intel ilyen felhasználási módban, mint aktuális formájában. -
Jack@l
veterán
Feltéve hogy a cikk és a cikkíró nincs nagyon félretévedve. Az okokat és a miérteket lehet találgatni.
A másik dolog, hogyha az igp magának adna paracsot, akkor mi szükség parancsra?
Vagy úgy gondoltad, hogy az igp majd parancsot kap, hogy adjon parancsot egy másik gpu-nak? (fura...)A MIC nem gpu mellé készült, hanem GPGPU helyett.
-
leviske
veterán
válasz
atti_2010
#79
üzenetére
Elvileg, ha jól értelmezem a cikket, akkor ha az IGP kezelné még a rajzolási parancsok kiosztását is, akkor a CPU magok feleslegesen lennének a konzolok lapkáiban.
Amíg meg erre egy masszívan sok szálon dolgozó CPU alkalmas, addig emlékeim szerint a Bobcat/Atom iránnyal szemben a MIC a legideálisabb megoldás, mivel rengeteg, gyenge X86-os egységből áll. -
pakriksz
őstag
válasz
atti_2010
#79
üzenetére
mondjuk az a problem, hogy a konzolos játékok, már kb a 3d megjelenése óta ilyen mantle/dx12 szerű alacsonyszintű gyors API-t használnak, szóval ez nem újdonság. Maximum az hogy a pc-nél elérték a határt mivel a CPU-k inkább csak a magszámban fejlődnek az utóbbi időben.
-
leviske
veterán
Fiery már ezt a Jaguar kapcsán korábban emlegette. Viszont, ha jól sejtem, az AMD-nek inkább érdeke a IGP-re való terhelés, mert a leírtak alapján, ha jól értem, akkor az Intel a MIC-el erre az irányra elég jól fel van készülve. Az Atom kapcsán szerzett energiagazdálkodási tapasztalatok csak ráadás.
-
#77
sh4d0w
félisten
tatararpad
#76
válasz
tatararpad
#76
üzenetére
Jujjjj....
-
#76
tatararpad
őstag
tatararpad
őstag
Ez nem a jövő, már itt van: [link]
-
pakriksz
őstag
válasz
#10691584
#64
üzenetére
nem volt érdemesebb, hanem egyszerűen nem lehet több magra írni. Persze a hangot, fizikát, betöltést, AI-t ki lehet rakni külön szálakra, de annyira elenyésző CPU használatot jelentenek ezek a kirajzoló szálhoz képest, hogy észre sem venni.
Egy játéknál a CPU terhelés 80%-a az API (directx)-re, és annak babusgatására megy el. Ha egy mai játékot megírnának az új apikra rendesen (mantle vagy dx12, vagy az opengl megfelelő képességeit használva), akkor kb egy dzsunkAtom kihajtana egy R290X-et -
bunevo
tag
Úgy tűnik ez a vita sajnos kitart majd az évtized végéig, és részben attól is függ majd, hogy a PS4/XBone architektúrája mit tud majd bizonyítani. Viszont mire ezen túlleszünk, addigra remélem a mobil SoC architektúrák már előrébb tartanak majd a válasszal, és talán ott a szoftveres környezet (OS, API, SDK) is gyorsabban tud majd változni.
A hangsúly szerintem a jel és adatfeldolgozás felé fog tolódni (hangfelismerés, gesztusfelismerés, általános komplex mintafelismerés), így az egyszálas teljesítmény szinte lényegtelen lesz és jöhetnek a nagyon heterogén big/middle/little/micro rendszerek 1/100/10000/1000000 maggal.
-
MaUser
addikt
A párhuzamosítás ma már nem lustaság kérdése. A mai fejlesztési környezetekben egy plusz szál elindítása és két szál közötti adat szinkronizálás egy perc pluszmunkát jelent. A gond ott van, hogy mit tudsz párhuzamosítani. Egy 2D konvolúcióra épülő képfeldolgozási algoritmust baromi egyszerű, mert pl. négy mag esetén szétdobod a képet négy mátrixra és négy szálon megcsinálod a konvolúciót mátrixonként majd a végén összefésülöd őket a "választóvonalaknál". Ugyanígy rengeteg mátrixműveletnél semmi gond.
Mit csinálsz azonban egy időfüggő logikánál? Azaz amikor van egy baromi nagy ciklusod, ahol az i. elem függ az i-1.-től? Általában ilyen esetre is van megoldás, de sokszor igencsak extrém munkát jelent annak megtalálása. Az 50-100€/h-s programozót meg igen ritkán fizetik azért, hogy két hónapot gondolkodjon azon, hogy lehet optimalizálni valamit, ami egyébként 0.5s alatt megvan megfelelően gyors proci esetén.
-
#10691584
törölt tag
Épp az a cikk lényege (ha jól értem) hogy eddig a DX és a társult API-k korlátai miatt volt érdemesebb/megtérülőbb 1-2 procimagra írni, ezért nem nagyon erölködött szinte senki. De ha már képtelenek lesznek a gyártók értelmes költséggel csíkszélt csökkentve "fejleszteni" akkor máshoz kell nyúlniuk. erre ugye ott a HSA/OpenCL és társaik, de én őszintén szólva 2008 óta ezeknek a nagymérvű és határtalan fejlövéséről olvasva sem láttam még 3 ezekre fejlesztett, használható programnál többet. Elhiszem, hogy "ez a jövő" de már igazán ideje lenne ideérnie így 5-6 év után (lesz az 8 is..) A magonkénti leosztás és az API-k megreformálása talán több lehetőséggel kecsegtet, vagy nem tudom.. Akárhogyis legyen, egyik sem holnapután fog eljönni, így max lesz idejük "összeérni" és tandemben talán még erősebbek lesznek, ha szerencsénk van. Az androidot meg nem érdemes (szerintem) ide sorolni, az egy sebtében összetákolt, linux kernelre rákulázott java/dalvik szörnyszülött, amit már ők (google) is bánnak, hogy ilyen lett, de már nincs lehetőség visszacsinálni, mert túl sok húron pendül és a userek így is seggüket földhöz verik, hogy jujjdeszép, naggyonjóó, húdebaba-
Szerk: basszus félreolvastam.. így jár az, aki éjjel felkel vázee..
-
atti_2010
nagyúr
Igen de arról lenne szó hogy elméletileg a DX 12 elhozza nekünk a sok magot használó játékokat is és egy hardverközélibb API-t ami vagy igaz lesz vagy nem az MS már tett ilyen kijelentéseket és nem lett belőle semmi, meglátjuk az egyetlen fény az alagút végén hogy a DX 12 az XBOX-ONE konzolján is szeretné használni az meg 6 magos így lehet hogy valóban megcsinálják.
-
Sinesol
veterán
válasz
atti_2010
#61
üzenetére
Ja hát valo igaz ez nem az Intel vagy az Amd hibaja.
De nemtudom ki fog itt sok kis magra fejleszteni amikor még 4-re se megy...8rol meg nem is beszélek.
Összeteszem a kezem ha latom egy evbe egyszer hogy egy jatek vagy program akár 4 teljes magot kihasznál...
Nem tudom igy hirtelen hany eve van 8 magos Amd de még mindig nagyreszt az 1 szálas erö a nyerő...no comment, ennyi év és nullaval egyenertekü fejlődés szoftverek tekintetében.
De a bf4 akár 8 magot kihasznál...mindenki megnyugodhat.
-
Sinesol
veterán
Az Amd messze van még attol a hatartol
![;]](//cdn.rios.hu/dl/s/v1.gif)
Viszont viccet felreteve jelenleg is 1-2 szálat hasznalnak ki 90 szazalekban, tehat ne mondja senki szerintem hogy itt a határ mert még felét se hazsnáljak ki annak sem ami most van tehat akkor miröl beszélünk
Az hogy a fejlesztök lusták/leszarjak/stb az nem jelenti azt hogy ennyi van benne...de igen legyen uj architektura mer a leszarom hozzaallas miatt ugyis 3-4 szer oylan erös kell mint amit kihozunk belöle...
Ez olyan mint ha a hazadhoz megvennéd a tüzéptelepet aztán hatha sikerül szerencsetlen kömüvesnek egy nyomorult viskot összehozni belöle... -
Nem azért kell más irányokat keresni, mert az AMD-nek nem megy a processzortervezés, hanem mert a processzorgyártók elérik azokat a fizikai határokat, amelyeket nem lehet áthágni a jelenleg rendelkezésre álló technológiai szinten. Nem kell nagyon messzire menni, lásd P4. Maga az architektúra bírt volna magas órajeleket is, de a szivárgási áram megpecsételte a sorsát.
Most ott tartunk, hogy megint kell valami, mert egyszerűen képtelenség sok processzormagot integrálni és szinkronban tartani magas órajelen, épkézláb fogyasztás mellett és x86 alapon.
-
#58
oraihunter
aktív tag
oraihunter
aktív tag
Drukkolok, a sok kicsi sokra megy elvnek! És ebben az irányban valóban nagyobb egyenlőre e fejlődési lehetőség.
-
Abu85
HÁZIGAZDA
Végül is csak két konzolt sikerült OEM konstrukcióban behúzni egyetlen fícsőrrel. Utoljára OEM konstrukcióban az Intel szállított konzolhardvert az MS-nek. Ez a legrosszabb üzleti modell egy konzolgyártónak, mert jóval többet fizet a beszállítónak mint szeretne, de nem tud mit tenni ellene.
-
atti_2010
nagyúr
Igen csak eddig nem került sokba a szerver cuccokból való átültetés de játékra külön nekik nem éri meg tervezni, ameddig az AMD -nek ott a Jaguár ami viszonylag kevés módosítással lehet bővíteni és még mindig megegyezik a konzolok lelki világával ameddig az Intel ettől most nagyon messze áll, ha nekik nem lesz hasonló a szerver architektúrájuk akkor erre nem fognak erőforrást pazarolni.
-
Abu85
HÁZIGAZDA
Ebben senki sem kételkedik. Mindenkinek egyszerűbb lenne egy 60 GHz-es egymagost tervezni, de nem lehet. Az összes reális alternatív útból az APU koncepciója adja messze a legjobb parformance/watt mutatót. Ráadásul proof of concept, mert a Cell működött.
A problémamegoldás mindig időszakos. Pár évig elleszünk ezzel, aztán megint felerősödnek más limitációk. A Microsoft már most figyelmeztet, hogy a DX12 megold egy csomó mindent, de a helyükre eddig nem érzékelt, új limitációk lépnek. Ezek még nem kritikusak, de később azok lesznek. Arra lesz majd egy újabb problémamegoldás és így tovább.
-
#51
Menthirist
veterán
Geri Bátyó
#50
válasz
Geri Bátyó
#50
üzenetére
Egyrészt nem vagyok olyan nagyon biztos hogy jól megoldották, másrészt meg az android android, a windows meg windows, microsoft
nem úgy megy az 
-
#50
Geri Bátyó
addikt
Menthirist
#49
válasz
Menthirist
#49
üzenetére
Nyilvánvaló, hogy ezt az oprendszernek is támogatni kell, de nem olyan nagy probléma. Droidon is hamar megoldották.
Gyanítom, hogy a mai oprendszereket is simán lehetne frissíteni erre a felállásra, ha az MS akarná. -
#49
Menthirist
veterán
Geri Bátyó
#47
válasz
Geri Bátyó
#47
üzenetére
Ahogy abu is írta, itt az operációs rendszerek esetén kell megoldani annak a támogatását, hogy tisztában legyen azzal, ha több különböző teljesítményű magja van, és hogy milyen feladatot kinek osszon. Jelenleg feltételezi hogy van x darab programszálja, ami ugyanolyan erősségű, tehát a szabadnak adja ki vagy beütemezi az egyikre a feladatot (azaz hát itt ugye lehet mondani a különböző ütemező algoritmusokat)
-
atti_2010
nagyúr
Ha valakik miatt elszaródik az egész ipar, piac az az AMD lesz és a ratyi cuccaik.
Mi szaródhat el már most is az és az AMD csak a játékos piacot célozza amit nem elkurni szeretne hanem valamit helyrehozni a karokból, ha könnyen lehet portolgatni a konzolról PC -re és a DX is összeszedi magát az mindenkinek csak jó lehet, Intelt a játékos társadalom abszolút nem érdekli neki ott van a szerver és az üzleti réteg ami jóval zsírosabb.
-
#47
Geri Bátyó
addikt
Értem én, hogy mindkét cégnek (AMD, Intel) van nagy és kis teljesítményű magja is és nehéz kitalálni, hogy mi legyen a következő fejlesztési lépcső, de mobil vonalon (ARM) már rég létezik a big-little koncepció, ahol nagy és kis teljesítményű magok is vannak a SOC-ban. Szerintem ezt PC-n is könnyedén meg lehetne valósítani. 2 nagy és 6-10 kis teljesítményű mag ideális megoldás lehetne, akár HT-vel megfejelve.
-
jacint78
addikt
Igen, ki gondolta volna, hogy ha az AMD-nek nem megy a processzortervezés, akkor hírtelen ilyen irányba kell elmenni. Korábban még az volt az elmélet, hogy az x86 akkor ér valamit, ha kevesebb, de erős mag van. Ha valakik miatt elszaródik az egész ipar, piac az az AMD lesz és a ratyi cuccaik.
-
Sinesol
veterán
válasz
atti_2010
#41
üzenetére
Nem annyira az oldalnak kritika, inkabb a Microsoftnak szol bár kis reszben annak is hogy ezt lehozza a Ph amikor már korabbi cikkekböl megtudhattuk mindezt.
Pakriksz:
A bulldozernél szerintem minden gyorsabb szoval az sokat nem jelent, igazabol ott is a 8 gyenge mag van hogy elverjen 4 inteles eröset, na de nem megyek bele ebbe, no offense nem akarok fanokat uszitani
-
nbg
senior tag
"Manapság a PC-ben az AMD és az Intel is nagyjából hasonló koncepciót követ, így alapvetően terveznek egy erős, illetve egy gyenge magot. Előbbit a magas órajelre élezik ki, míg utóbbinál főleg az alacsony fogyasztás dominál, és ezeket felhasználva fedhető le a teljes piac."
Most vagy felreerttettem ezt a ket mondatot, vagy itt pont nem a PC-s vonal lett leirva, hanem a mobilos...
-
Sinesol
veterán
De most ebben mi a hír érték?
Hónapok vagy talán évek óta tudhato hogy pl az Intel Skylake is Mic-re épül majd sok gyengébb maggal, az Amd is ugyanezt elölegezte meg a jaguar magokkal egyelöre a konzolok esetében..
Nincsen egyéb hír és a Microsoft is csak ugy elmondja a nyilvanvalot?Legközelebb arrol is legyen hir hogy xy cég szerint a viz olvadáspontja minden bizonnyal jövöre is 0 fok környeken alakul..
-
Sir Ny
senior tag
"hiszen ugyanaz a kód a konzolokon gyakorlatilag lineárisan skálázódik"
ugyanaz a kod a konzolokon O(1) rendben skalazodik.
"Jó hír viszont, hogy az új generációs grafikus API-k a rendszert egyetlen ponton sem kényszerítik soros feldolgozásra,"
wtfdijr?
ez most Velemeny, vagy mi?
-
-
MaUser
addikt
Átlag programhoz pont elég az egy aszinkron szál.
Nem kell több processzormag azért, mert valamit a háttérben akarsz csinálni, itt nincs érdemi nyereséged a párhuzamosításból, az aszinkron szálak közötti szinkronizációs veszteség meg általában minimális. Kép- és egyéb multimédiás anyagok szerkesztésénél van értelme a több szálnak, mert egyrészt baromi egyszerűen kihasználható (pl. képszerkesztésnél ha programoztál bármilyen szűrű algoritmust, akkor tudod miért) de az meg bármilyen meglepő nem gyakori. Félreértés ne essék, én lennék a legboldogabb, ha lenne a mai procik teljesítményével rendelkező mondjuk 10 magos proci, de baromi nagy öngólnak látom ha a végén lesz egy 100 magos, szálanként a maik 10-edét hozó, ahogy a cikk leírja... Egyszerűen rengeteg mindent nem tudunk ma párhuzamosan megoldani gazdaságosan.Abu85: Nyilván ebben látják, mert erre tudnak olcsón menekülni. Motorvezérélésben pl. most a GDI-ben látja az összes cég a jövőt, de nem azért mert olyan jó lenne, csak azért, mert erre tudnak menni egyszerűen a meglévő kiindulási pontjukról.
-
Abu85
HÁZIGAZDA
Az idei GTC-n volt erről előadás.
Az integráció a ray-tracing alapja, mert az adatmásolással rengeteg idő elmegy. Persze a maiak még fejlődnek, de például ott az Echelon koncepció. [link] - nem teljesen ez, de ilyenek jönnek három éven belül.(#32) Jack@l: Nagyon ki vagy azzal segítve egy játékban, hogy statikus jelenettel állóképeken jól működik.
(#26) DigitXT: Erre kell építeni a játékkoncepciót. Minden jelenetet a biztonsági kamera vesz fel és kész.
-
.mf
veterán
Még mindig nem értem, hogy miért nincsenek itt is heterogén magok. Már évekkel ezelőtt meg kellett volna lépni, s akkor már sw-es támogatás is lenne hozzá. Pl. lenne ultramobil megoldásba 1 vagy 2 Silvermont és 1 ULV Haswell mag, normál laptopba és alap desktopba 2+2, DTR és desktopba 2+4. Az Atom magok vinnék az OSt és a háttér-programokat alacsony fogyasztással, a nagyobb teljesítményű mag pedig deep sleepből csak akkor éledne fel, ha nagyobb egyszálas teljesítményre van szükség.
Közben már ARM-vonalon is megvalósították, ld. big-little. Az x86 lassan mozgó dinoszauruszok. -
polika
senior tag
Átlag normál PC felhasználásnál per pillanat tényleg csak a játékok amik magas egyszálú teljesítmányt igényelnek a szar erőforrás használat miatt. Levelezéshez, internet, irodai, kép szerkesztés, multimédia, itt minden esetben műkszik a párhuzamosítás. Max olyan mérnöki számítások esetében kell a magas 1 szálú teljesítmény, amelyek nem párhuzamosíthatók, mert egyik számolás a másik eredményein múlik.
Viszont én a sok kis mag helyett azt hiszem hogy PC-be is beköltözik majd egy idő után az ARM-os big little koncepció, lesz 1-2 magas 1 szálú teljesítményt adó, órajellel nagy intervallumban skálázható potenciális erőmű, és lesz mellé egy fürtnyi alacsony órajelű, kisebb fogyasztású CPU, vagy az IGP-ben található GPGPU fogja annyira kigyúrni magát, hardveresen és szoftveres támogatásban, hogy átveszi ezt a szerepet teljesen.
-
DigitXT
félisten
Ennél a mákosodásnál ocsmányabb opció nem létezik.
Pedig el tudok képzelni játékot, ami simán rájátszik erre az effektre. Annak
idején az AC-ben a "biztonsági kamerás" felvételek tök hasonlóak voltak.
Mondjuk az egész játékon keresztül nézegetni valsz' "kicsit" fárasztó lenne. -
-
-
Abu85
HÁZIGAZDA
Ki beszél itt path-tracingről? Itt ray-tracingről van szó. A path-tracing jelenleg egy erősen kompromisszumos megoldás arra, hogy a mai rendszereken is legyen mit mutogatni, de ettől még látod, hogy iszonyatosan korlátozott az egész, mert csak egy picit mozdul a kamera jön a mákok háborúja.
Ugyanazt, amit más API. Feldolgozza.
(#19) bence96benko: Lehetséges. Főleg az operációs rendszerben kell hozzá fejlesztés, hogy megkülönböztethető legyen a magok ereje.
-
O_L_I
őstag
válasz
djculture
#18
üzenetére
Szerintem ez inkább úgy fog kinézni, hogy ha erre mennek rá a gyártók akkor kb megragad a /core teljesítmény a jelenlegi állapotban és a magok számát kezdik el szaporítani.
(Az AMD-nek ez baromi jó lenne mert a TSMC HP miatt szívnak az órajellel az APUkban és ez valsz 20nm-en sem lesz jobb) -
djculture
félisten
Nem haragszom. Most mi számit egy játéknál? Az hogy megfelelő teljesitménnyel fusson az az 1-2 szál ami használ.. Az intel azért erősebb a gyakorlatilag egy szinten lévő fx széria előtt. Csak a szálankénti teljesitmény számit most. Ha most jön egy olyan cpu széria aminél sok mag lesz de gyenge egyenkénti teljesitmény ezek a játékok képregényként fognak futni. Nem hiszem hogy majd ujrairják az összes most használt játék motort amelyek mind erre vannak épitve.(jó mondjuk a mantle-s dolgoknál működhet de van egy csomó régi játékmotor amelyeknél nem)
-
Abu85
HÁZIGAZDA
Sem a GPU, sem pedig a CPU nem jó. Mindkettővel kompromisszumra kényszerülsz valahol, csak máshol. A CPU és a GPU integrációja a legjobb, mert célirányosan oszthatod el a részfeladatot a lapkában található részegységek között.
A legnagyobb problémát az adatmásolás jelenti. A Brigade a GTC-n beszélt róla, hogy egy 12,7 millió poligonból álló jelenet 500 MB-ot foglal, a gyorsítóstruktúra pedig 1,5 GB is lehet. A leképzés megkezdéséhez a jelenet adatbázisát és a gyorsítóstruktúrát, át kell másolni a GPU saját memóriájába. A gyorsítóstruktúra esetén a másolás maga 48 ms, ami alatt a CPU is kiszámolja az egészet. Ezért alkalmaznak rengeteg trükköt és kompromisszumot, például amint megmozdul a kamera teljesen elmákosodik a kép. Erre a megoldás az integráció.
-
Abu85
HÁZIGAZDA
Mindenki az osztott architektúrában látja a jövőt. A hardver oldalon nem kérdés, hogy a CPU+IGP mély integrációja a következő lépcső. Az a kérdés, hogy a szoftveres alapot ad platform mi legyen előtte. Van egy rakás cég a HSA mellett, az NV a CUDA-t élteti, míg az Intel az AVX akárhányban hisz.
A koncepció annyiban kedvezőbb most, hogy a HSA biztosan kínálni fog legacy módot, így ha ebben írod a programod, akkor senki sem lesz kizárva, sőt AVX2-3 is támogatva lesz.
-
Jack@l
veterán
Ezt magyarázd meg annak a 3 api fejlesztő brigádnak, akik a háttérben gőzerővel nyomják a fejlesztését, és gpu az egyetlen alternatíva hozzá.
(mert a cpu 20-ad annyit se számol, mint egy gpgpu)APU meg a computing?
hagyjukmár... (trabival drag racingre)UI: csak hogy legyen egy kis nyálcsorgató video is a jövő "apijáról": http://www.evermotion.org/articles/show/8621/brigade-3-0-real-time-path-tracing
-
MaUser
addikt
És ugyan ott vagyunk amit vagy 5 éve szajkózunk itt fejlesztők, hogy azért mert az AMD kínjában az osztott architektúrában látja a jövőt, attól még ugyanúgy ki lehet törölni vele a fenekünket néhány speciális esetet kivéve, mert ahogy kolléga is írja, az algoritmusok jó része gazdaságosan nem párhuzamosítható.
Lesz egy fasza visszalépés ezerrel így, amíg a fordítók fel nem nőnek ehhez. Az meg ki tudja hány év vagy évtized.... -
Abu85
HÁZIGAZDA
A ray- és a path-tracing sem a CPU-ra sem pedig a GPU-ra nem jó. APU-val osztható fel úgy a feladat, hogy kedvező legyen a hatékonyság. De ez még minimum 10 éves távlat. Olyat lehet elképzelni még, amit az Imagination csinál. Dedikált fixfunkciós hardver a sugárkövetésre. Pár effekt ezzel egyszerűbben és gyorsabban megvalósítható, mint árnyalással, de ettől a raszter megmarad. Ez egyébként reális jövőkép, és valszeg a hibrid render az elkövetkező pár évben általánossá válik.
-
Jack@l
veterán
De az célhardver, nem általános számolásra/programfuttatásra használják, hanem ugyanarra, mint a gpgpu-kat. (intel azzal akart játékban maradni, csak nem hozta a gpu-s teljesítmény felét se kb...)
Ha a grafikus api azt jelenti, hogy nem shading, hanem ray- vagy path-tracing(az tényleg sokszáz magra is jól skálázható), akkor persze hogy az lehet a jövő. Csak oda meg kraft is kell, nem x86-os magokkal fognak bohóckodni.
-
-
Abu85
HÁZIGAZDA
Ezért használnak a fejlesztők job rendszerű motorokat. Az eredmény azt mutatja, hogy lineáris lehet a skálázódás, ha az API nem kényszeríti egy magra a leképzést.
A jobnak annyi hátránya van, hogy egy szálat csak a fő thread elvisz, így ezért látsz majd minimum négy szálat igénylő játékokat már idén.
-
-
Jack@l
veterán
"Példaként említve 16-24 darab AMD Jaguar vagy Intel Silvermont mag, illetve ezek leszármazottai lényegesen gyorsabbak lesznek az új játékokban, mint a mai elvek szerint fejlesztett négy-, hatmagos processzorok."
Ja, biztos gyorsabbak lesznek, feltéve hogy 1 szálon is legalább olyan gyorsak majd...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- VADIÚJ Bontatlan! Honor 400 Lite 8/256 AMOLED 120Hz Velvet Grey, Dual SIM 2év telekom gar
- AZONNALI SZÁLLÍTÁSSAL Eladó Windows 8 / 8.1 Pro
- Honor X7 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! GIGABYTE A520M R7 3800X 32GB DDR4 512GB SSD RTX 3060Ti 8GB ZALMAN N4 Cooler Master 650W
- ÁRGARANCIA!Épített KomPhone i5 14400F 16/32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest