- SkyShowtime
- Facebook és Messenger
- Debian GNU/Linux
- Hálózati / IP kamera
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- Milyen routert?
- Kínai cégek segítik ezentúl a Teslát, a Renault-t, a Hyundait és a Toyotát
- WLAN, WiFi, vezeték nélküli hálózat
- Az iPadOS-re írt appokra is díjat vet ki az Apple
Új hozzászólás Aktív témák
-
ermisukrám
tag
viszont cserébe gondolom a felépítése miatt a CPU mellé (illetve bocs APU) besegíthetnek ezek az "x86"-os grafikus? magok ha szükséges (render párhuzamosításánál eléggé masszív lehet a cucc)
Aki másnak izébizé annak nyelve szabadlapos
-
#16939776
törölt tag
Szinte mindent emulálunk, nem tudjuk garantálni az egyenletes teljesítményt, lehetnek képhibák, és még a támogatás is inteles.
"Amennyiben egy adott alkalmazás igényel valami új funkciót egy effekthez, akkor az Intel frissíti az úgymond GPU emulátort, és a hardver képes támogatni mindazt, amire aktuálisan igény mutatkozik."
Ez most kínlódás?!
-
zetor2000
senior tag
És nem lesz az, mint volt 20-25 éve, hogy válasszak, milyen GFX meghajtót akarok használni? DirectX, Voodoo 3D, OpenGL, OpenCL, Mantle, meg mittudoménmiaz nVidia vacka... ?
Ez a dal a lelkünk közötti híd kövei között a malter közötti szeretetet átitató áldás közötti békesség.
-
nagyúr
nocsak. PS3 emu FTW?
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
smkb
őstag
Hát, ha ezt meglépi az Intel, akkor mint az x86 cpu piac 80%-os részesedésével bíró cég, irgalmatlan készpénzállománnyal a háta mögött, masszívan bedarálja a konkurencia erőlködéseit, már nem csak cpu szinten.
-
KAMELOT
titán
Meglátjuk mi lesz ebből!
V1200 - 18CORE - SUPRIMX
-
bunevo
tag
Azt hittem ennél nagyobbat fog előrelépni az Intel az új MIC-vel. Nagy csalódás.
Viszont magukat szívatják, hiszen a mobilpiacról lemaradtak, a konzolpiacról lemaradtak, a szerver piacon most jön az ARMv8, PC-re eleve már csak egy-két hardcore gamernek van szüksége, de ott is inkább Kaverit és Radeont vennék.
A gyártástechnológiai előnyük lassan el fog olvadni, hiszen 10nm alá nem lehet menni.
Mi lesz így az Intellel?
Semmi stratégiája sincs a technológiai döntéshozóiknak? Mit csinálnak azzal a sok pénzzel amit az eddigi monopól helyzetük adott? -
O_L_I
őstag
Asszem én is fejlesztek egy új API-t... Ha jól látom most ez a divat.
-
Fiery
veterán
"A gyártástechnológiai előnyük lassan el fog olvadni, hiszen 10nm alá nem lehet menni."
Ezt honnan veszed? Az Intel mar most is fejleszti a 10 es 7 nm-es processzeit, leven hogy a 14 nm-rel mar kesz vannak.
Megjegyzem, ez a MIC-es megoldas a computing vonalon is erdekes tavlatokat nyit. Pl. nem kell OpenCL-lel vacakolni, hanem direktben lehet AVX-512-vel programozni, kihasznalva _egyszerre_ a hagyomanyos x86 CPU magok es a MIC magok teljesitmenyet, aggregaltan.
[ Szerkesztve ]
-
-
mcloud76
tag
Te hiszel meg a meseben?
Ez a most jon mit takar? Mert kb egy eve ezt hallgatja az ember.
Arrol nem is beszelve hogy elsore tuti nem lesz tul hasznalhato.
A masik meg, hogy az arm hurcika cuccba valo ott azert lett sikeres mert jo a felvett teljesitmeny-valos szamitasi teljesitmeny-tdp aranya.
Itt ahol ez nem annyira fontos csak a teljesitmeny, eselyuk sincs.[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz ermisukrám #1 üzenetére
Nincs bináris kompatibilitás a MIC és a normál x86 magok között.
(#4) gbors: Azt már ma is lehet írni csak eléggé komplex. HSA-val egyszerűbb lesz, de ott is le kell emulálni a szoftveres környezetet, ami túl időigényes. Ezért nem fog bele senki.
(#13) Fiery: Az OpenCL a programozó oldaláról egyszerűbb, mint a vector intrinsics. Jóval kisebb erőforrás befektetésével kapsz ugyanolyan gyors kódot. Ennél egyszerűbb megoldás csak a C++AMP nagyon hatékony autóvektorizálója, de ezzel lassabb lesz a kód, vagy komplexebb dolgokat nem lehet megcsinálni vele. Persze sokaknak elfogadható lesz ez a kompromisszum.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
En nem mondtam, hogy egyszeruen fog menni az Intelnek a 7 es 10 nano, csak hogy dolgoznak rajta. Hol volt abban optimizmus, amit irtam? A 14 nano pedig kesz kell hogy legyen, maskepp nem lesz belole Broadwell az igert (kicsit arrebb csusztatott) idopontra. Mas kerdes, ha kicsit me'g faragni kell a Broadwellen, hogy jobb legyen a kihozatal, de maga a processz kesz.
-
Alchemist
addikt
Larrabee reloaded... és vajon ki/mi fogja ezt majd alkalmazásokkal ellátni? akik mindmáig kitartanak az Itanium mellett?
[ Szerkesztve ]
Éppen olvasok egy érdekes könyvet az antigravitációról... képtelen vagyok lerakni.
-
-
Fiery
veterán
A programozo oldalarol me'g egyszerubb lenne, ha nem kene contextekkel, device-okkal, command queue-kkal es hasonlokkal vacakolni, hanem direktben lehetne programozni a GPU-t. Nem mondom, hogy AVX-512 assemblyvel feltetlenul, de egy egyszeru libraryval meg lehetne oldani az egeszet, nem kene az OpenCL overheadje oda. Aki meg feketeoves, az programozhatja direktben a MIC-et.
Szamomra 2 alapveto kerdes maradt a MIC kapcsan, talan Te tudod a valaszt ezekre:
1) Hanyszoros multithreadinget kapnak a Skylake MIC magok?
2) Vajon az operacios rendszer (foleg Windows) szamara elerhetoek, lathatoak lesznek-e kozvetlenul a MIC magok? Vajon a kernel tud-e utemezni szalakat a MIC magokra? Az alapjan, hogy a Knights Landing-en elvileg fel fog tudni bootolni egy oprendszer, siman elkepzelhetonek tartom, hogy a Skylake magjai is teljes(ebb) x86 magok lesznek, mint a Knights Corner eseteben. Mas kerdes, hogy az oprendszer utemezojet adott esetben modositani lenne celszeru, hogy ne pakoljon oda csipcsup szalakat, hanem csak bizonyos feladatokat utemezzen a MIC magokra. Sci-fi ez az egesz, vagy van benne racio?
-
apatyas
Korrektor
"Amennyiben egy adott alkalmazás igényel valami új funkciót egy effekthez, akkor az Intel frissíti az úgymond GPU emulátort, és a hardver képes támogatni mindazt, amire aktuálisan igény mutatkozik."
Bocs, kösz, nem. Azért, jót nevettem rajta.
Sz: #2 Duracellm már írta[ Szerkesztve ]
pezo77 #5 2017.12.14. 13:29 Hmm. És ez az e-hajó akkor hol is tud kikötni? Az e-bay -ben? ;)
-
LordX
veterán
Ez a legnagyobb hülyeség amit tőled valaha olvastam, már bocsánat. Ha direkten szálakat futtatok, akkor nincs szinkronizáció? Annak nincs overheadje, akár kézzel történik (-> extra meló), akár az oprendszer csinálja (túl általános célú -> gyenge perf)? Nem véletlenül van context meg command queue - pontosan erre.
És hogy írjak direkten ASM utasításokat? Mert a C++ fordító, OpenCL fordító nem ismeri őket, vagy mi? Ilyen alacsony szinten ma már senki nem dolgozik komolyan. Max egykét kritikus ponton optimizál kézzel, de ez pont azt jelenti, hogy nem dobják ki a magas szintű programnyelvet.
Nem ez a különbség. A hagyományos grafkártya data parallel modellben működik, az Intel MIC meg task parallel. A kettő ég és föld - egyik se jobb a másiknál (azonos elméleti peak teljesítmény mellett, és itt viszont úgy tűnik a GPU-knak áll a zászló), de ha a másik kabátját akarod ráhúzni, akkor eléggé döcögősen fog menni.
-
#06658560
törölt tag
"És hogy írjak direkten ASM utasításokat? Mert a C++ fordító, OpenCL fordító nem ismeri őket, vagy mi? Ilyen alacsony szinten ma már senki nem dolgozik komolyan. Max egykét kritikus ponton optimizál kézzel, de ez pont azt jelenti, hogy nem dobják ki a magas szintű programnyelvet."
Bár nem programozó vagyok, de az élet egyéb területeiről szerzett tapasztalataim alapján DE.
#26 Lomha 8V: küldjem a számlaszámom? Direkt támogatással sikeresebb lennék, hamarabb érnék eredményt.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Most is lehet bármit programozni a fémen, de annyira irreális az ezzel járó extra munka, hogy nincs értelme egy bizonyos szint alá menni. Az OpenCLnek vannak hibái, de nagyjából az a szint, ami még vállalható erőforrás befektetését követeli, és az eredmény is nagyon gyors. Ez alatt már a nyerhető extra megkérdőjelezhető jelentőségű, főleg annak tudatában, hogy mennyi erőforrást kell még belefektetni.
1) A Knights Landing magját kapják, tehát annak a speckóit kell figyelni.
2) A MIC magok nem kompatibilisek a mai fő magokkal. Hiába az x86 akkor sincs bináris kompatibilitás a normál és a MIC magok között. Ennek az az oka, hogy az x86 memóriamodelljét módosítani kellett hogy a rendszer skálázódjon.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
bbTamas77
aktív tag
-
Fiery
veterán
Koszonom az elismero szavakat
"Ha direkten szálakat futtatok, akkor nincs szinkronizáció? Annak nincs overheadje, akár kézzel történik (-> extra meló), akár az oprendszer csinálja (túl általános célú -> gyenge perf)? Nem véletlenül van context meg command queue - pontosan erre."
Miert kellene az oprendszer szalkezelesenek lassunak lennie? A Knights Landing be tud majd bootolni egy oprendszert, tehat valamilyen szinten az oprendszer fogja kezelni es utemezni a MIC magokat. Ha a Knights Landingnel ezt megoldjak, akkor miert ne oldhatnak meg a Skylake-nel vagy a Goldmont-nal is?
Az assembly hogyan mukodik x86-on? Yasm peldaul? No rocket science. GCN-re, Keplerre, az Intel GenAkarmennyijeire nincs assembly, pontosabban nem nyilt a rendszer. MIC-re -- ha az Intel egy kicsit is okosan csinalja -- lesz x86 assembler, jo esellyel a Yasm is tud majd forditani ra.
"Ilyen alacsony szinten ma már senki nem dolgozik komolyan"
Mi ennel alacsonyabb szinten is dolgozunk komolyan. Pl. kodgenerator, direkt gepi kodu programozas, stb. De persze tudom, hogy a fejlesztok 99%-a nem mereszkedik idaig, tudom hogy kisebbsegben vagyunk. Az extrem optimalizaciohoz azonban a legjobb megoldas mindig az, ha nem kell OpenCL, D3D, OpenGL es hasonlo overheadekkel vacakolni. A Mantle sem veletlenul szuletett, ott is az overheadet probaljak lekuzdeni.
-
Fiery
veterán
"A MIC magok nem kompatibilisek a mai fő magokkal. Hiába az x86 akkor sincs bináris kompatibilitás a normál és a MIC magok között. Ennek az az oka, hogy az x86 memóriamodelljét módosítani kellett hogy a rendszer skálázódjon."
Igen, ezt tudom, de akkor hogyan fog a Knights Landing bebootolni egy oprendszert? Ha pedig az be fog tudni, akkor a Skylake MIC magjai is kepesek lehetnek ra -- elvileg. Es onnantol vagy az a szitu, hogy a MIC magokat "okositjak" fel mondjuk egy Quark szintjere, vagy az oprendszer kernelet modositjak, hogy a MIC magokat is be tudja sorolni a normal x86 magok koze vagy mellé. Ez utobbi erdekelne engem, azaz hogyan lehet megoldani azt, hogy a MIC magokat is lehessen barmilyen celra hasznositani Windows alatt, direkt threadinggel, direkt x86 (akár assembly) programozassal.
[ Szerkesztve ]
-
LordX
veterán
válasz #06658560 #29 üzenetére
Mutasd meg a legutolsó programot, amit 100% ASM (vagy lejjebb) volt programozva. Megmondom neked: Transport Tycoon Deluxe, 1995. Disclaimer: nem az a lényeg, hogy pont ez a játék, hanem hogy mikor történt. Azóta minimum C, és csak a kritikus részekben vannak ASM utasítások (vagy még az se, megállnak intrinsics-nél). Ma már ott tartunk, hogy néhol JavaScriptben(!!!) csinálnak számításokat (mondjuk az már erősen /facepalm kategória).
Fiery: Azért nincs ASM AMD kártyákra, mert minden 3. évben kijön egy gyökeresen új ISA, és dobhatnád ki az egész kódodat a francba. Nagyon, NAGYON kevesek engedhetik meg maguknak, hogy ez így menjen, a 99%-hoz még pár kilencest nyugodtan hozzá lehet írni. <1% userre meg senki nem fog új nyelvet/API-t/fordítót fejleszteni 3 évre (de néha még 10%-ért sem). A Mantle nagyon nem ugyanaz a kategória, az egy tényleges piaci rést céloz meg, nem véletlenül néz ki majdnem ugyanúgy, mint az új konzolok APIjai.
-
Meteorhead
aktív tag
Nem igazán látom, hogy ez a szoftveres réteg, ami a vas és a user-space programok között húzódik miben különbözik egy drivertől. Egy drivernek is támogatnia kell bizonyos API-kat, és azokat lefordítja a vas nyelvére. Ez nem pont ugyanezt csinálja? Nem látom a különbséget.
A 7000-es Radeonok egyik PR slide-ján volt a "Full compute graphics API? Start thinking about it" felirat. Ez a MIC architektúrás biznisz ebbn a formában naggyon ide vág. Ha minimális szép érzés és humanitás szorult ebbe a bandába, akkor valami olyat csinálnak, ami moduláris. C++AMP egy totál jó felület lehetne erre, csak nyílván az egy saját köztesre fordít. A mai DX és GL szerelőszalagokat is meg lehetne írni full compute módon, szépen úgy, hogy az ember a szalag egyes lépcsőit felüldefiniálhatja, vagy totál custom lépéseket iktathat be közéjük. Ekkor persze az ember kidobja a fix funkciós egységeket a rákba, de simán lehetne egy olyan API-t kidolgozni, ahol a fix funkciós egységek a default lépésekben vannak benne, mint például a raszterizáció. Akkor minden vendor olyan módon implementálná ezeket, ami a saját HW-ének fekszik. Ha ennyire flexibilis lenne a szerelőszlalag, akkor a mozaikos leképezés is könnyen menne, egy custom Input Assembler (hogy egy kis DX terminológiát is bekeverjek) lépésben, ahol megtörténik a sorbarendezés, és lenne XXfinish() parancs, amitől még működne is.
Nyílván, aki Mantle-t akar használni, az azt fog, de én baromira bírnám, ha Intel felzárkózik IGP tudásban, akkor nem valami újat csinálna, hanem beállna a sorba, illetve ha már valami újat csniál, mert a Mantle neki nagyon nem fekszik, akkor valami olyat csinálna, ami a konkurens vason is megy. (Vagy legalább AMD vené a lapot, és implementálná)
Tudom, eddig azt szajkóztuk, hogy nem kell az API, most meg amikor megszűnik és mindenki megcsinálja a saját low-level cuccát, akkor megy a sírás rívás. Mndenesetre úgy látom, hogy annyira a compute irányba mennek a dolgok, hogy igazából kell egy API, csak legyen hasonlóan alacsonyszintű, mint a Mantle, és legyenek default belépési pontok, ami mögé a most még meglévő fix funkciós egységek meghajtását be lehet rakni. Aztán ha az idő úgy gondolja, legyilkolja mögülük a spéci drótozást, és emulálva lesz az is a többivel egyetemben.
Vagy nagyon rosszul látom?
-
GeryFlash
veterán
Az Intelnek kb75%-os piaci részesedése van cpu fronton, ha zet meglépi akkor tényleg lesöpörheti a konkurenciát. Intelesként mondom, hogy ez nem lenne jó.
Az biztos, hogy a Skylake izom lesz, már régóta szemezek vele, és a régi öreg core2duo-mat se akartam lecserélni, pontosan ezért, mert sem a sandy-ivy bridge, sem a haswell és a broadwell nem a jövő, csak egy tanulási folyamat (kis fogyasztás, erős igp) aminek a vége a Skylake lesz, ami ha a pletykák igazak, ugrásszerűen megerősödik az IGP-je, vagyis a 2015-s AMD-kel lesz pariban vagy még erősebb is lesz.
A saját API viszont nem tudom mennyire jó ötlet, azért hiába anyg piaci részesedés, az AMD rentege játékot támogat amik valószínűleg Mantle-re fog építeni, csúnya háború lesz itt, meg kéne állapodnia a 3 nagynak valami közös API-ban, mert a direct x nem megoldás (miért is lenne az, hisz a microsoft csinálja...)
Amúgy akkor az OpencL.lel mi van? Akkor az már az Intel szerint is zsákutca?
[ Szerkesztve ]
Hi, i'm new to APHEX TWIN, so i was wondering how much the IQ requirements was to enjoy his stuff. and understand all the underlying themes, because its really complex stuff. I have IQ of 119 but i heard that you need atleast 120 is it true?
-
-
#06658560
törölt tag
Márpedig mégis, ha a kommentem képtelen voltál értelmezni a sajátoddal kapcsolatosan- idézet tőled:
"Ilyen alacsony szinten ma már senki nem dolgozik komolyan."
Az, hogy te nem találkozol ilyennel, nem jelenti azt, hogy nincsenek ennyire elborultak-a maguk területén egyébként hihetetlen zsenik. -
Abu85
HÁZIGAZDA
válasz Meteorhead #36 üzenetére
Egy GPU-t azért még mindig úgy terveznek, hogy az API-hoz illeszkedjen. Többek között van parancsprocesszoruk, amihez tartozik egy megfelelő driver. A MIC-nek ilyenje nincs, mindenképp szükséges egy olyan szoftveres réteg a hardver előtt, ami igazodik az adott API-hoz. Emulál egy GPU-t, erre nincs jobb szó. Viszont, hogy ne legyen azért vállalhatatlanul sok absztrakciós réteg, így érdemes olyan szoftvert írni, ami igazodik a hardverhez. Persze az egész felfogható egy túlhizlalt drivernek is, de kétségtelen, hogy nem szokványos a működés. Az egész egyébként elvi szinten hasonló lehet a SwiftShaderhez.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"csak a kritikus részekben vannak ASM utasítások"
Ez teljesen normalis. Mint ahogy az OpenCL-t hasznosito szoftverekben is csak a kritikus reszeken van OpenCL kod.
"Azért nincs ASM AMD kártyákra, mert minden 3. évben kijön egy gyökeresen új ISA, és dobhatnád ki az egész kódodat a francba"
Ettol me'g lehetne. Mindenki dontse el, hogy ilyen feltetelek mellett is megeri-e neki a fejlesztes assemblyben. Egyebkent a "minden 3. évben" es a "gyökeresen" egyutt eleg nagy tulzas. A VLIW5 architektura a Radeon HD 2900 XT-vel jelent meg 2007-ben. Azt facelifteltek, ugy szuletett a VLIW4 -- ami nem gyokeresen eltero architektura -- a Radeon HD 6970-nel 2010-ben. Az igazi uj generacio a GCN, ami 2012-ben jelent meg, tehat mondjuk 5 evente van gyokeresen uj architektura. A GCN2 (vagy mas neven GCN 1.1) sem gyokeresen uj architektura, csak faceliftelt, es velhetoen az is ki fog tartani cca. 2017-ig, kisebb-nagyobb patchelgetesekkel. Az nVIDIA-nal ugyanez a helyzet, a G80 (2006) ota, azzal egyutt is eddig 3 generacio volt, a Tesla, a Fermi meg a Kepler, de ez utobbi 2 vita targya lehetne, hogy mennyire gyokeresen ternek el.
[ Szerkesztve ]
-
#06658560
törölt tag
-
#25954560
törölt tag
sajnalom, de akarcsak Fiery, en is assemblyben (is) dolgozom. egy eve uj teruleten vagyok, de egy evvel ezelottig _kizarolag_ assembly volt.
multinal, nem kicsi garazscegnel. ha teljesitmeny kell, akkor tovabbra is nagyon ugy latszik h adott vason a gepi kod az, amivel a legtobbet ki tudsz belole hozni. idoigenyesebb, ez ketsegtelen. de megeri
szoval nem csak par oskovulet z80-on szuttyog asm-mel -
Abu85
HÁZIGAZDA
Mindenképp módosítani kell az oprendszert, hogy bebootolja. De egyébként bármelyik modern GPU bebootol egy oprendszert, ha megcsinálod hozzá a szükséges vezérlőhidat a hardveres háttérnek és megírod rá a szoftvert. Itt inkább az a gond, hogy senki sem gondolkodik ilyenben. Önmagában ennek nincs is értelme, mert ha már raksz a rendszerbe kettő vagy négy procimagot (márpedig rakunk), akkor azon sokkal hatékonyabban megy bármilyen OS. A koprocesszorok - mert nyilván ezek a MIC/GCN-féle dolgok azok lesznek - a programfuttatásra vannak.
Minden IGP-nek van ma is egy vISA szintű hozzáférési felülete, bár ezzel az Intel nem igazán törődik, mert kevés fejlesztőt érdekel. De a mostaniaknak is van, csak nem annyira jó, mint az AMD AGSL, vagy az NVIDIA NVAPI. Nyilván ilyenje lehet a MIC-nek is.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#65675776
törölt tag
Szóval az egész kb úgy fog működni, mint a PowerVR-ek (TBR), csak mindent emulál. Legalább lehet tudni mi értelme volt az atomoknál a kitérőnek IGP esetén. Gyűjtötte az intel a tapasztalatot a rendszer működéséről. Most meg gyakorlatilag azt fogja emulálni a saját hw-én. Az egyetlen érdemi eltérés, hogy most házon belül lesz a sw réteg fejlesztése. Bár ismerve az intel termék- és támogatási politikáját, sokkal előrébb nem lesz emiatt senki.
[ Szerkesztve ]
-
LordX
veterán
VLIW4 gépen VLIW5 kódot ha beleszakadsz sem fogsz tudni futtatni, de még VLIW5 és VLIW5 között is lehetnek masszív különbségek, amit fordító nélkül úgyse fogsz megoldani, de hatékonyan még inkább nem (pl. VLIW equals scheduling model, különböző pipeline hosszal, vagy csak simán különböző számú delay slot..). A VLIW pont annak mintapéldája, amit direkt úgy terveznek, hogy van jó fordító (és ennek hiánya miatt bukott eddig mindegyik) - nem is véletlen, hogy átálltak skalárra AMD-ék.
[ Szerkesztve ]
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen