Új hozzászólás Aktív témák

• #195 Meteorhead aktív tag Abu85 #194

  Új Válasz 2014-02-09 20:28:12 #195

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz Abu85 #194 üzenetére

  Osztom Fiery véleményét, hogy a legegyszerűbben C++-ban lehet programozni, de mivel ott nincs direkt nyelvi támogatás a szálak csoportba rendezésére (ami egyre több vason lesz kritikus), ezért AMP a legjobb megoldás, ahol közel transzparens a gazda oldali kód és az eszköz oldali kód közti átmenet.

  A kérdésem: ha ennyire okos mindegyik architektúra, hogy be tudna bootolni egy OS-t, akkor miért nincs egyetlen API sem, ahol könnyen lehetne programozni?

• #193 Meteorhead aktív tag Abu85 #192

  Új Válasz 2014-02-09 18:19:18 #193

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz Abu85 #192 üzenetére

  A Skylake baromira nem a mobil frontot célozza, de nagyon remélyem, hogy ott is nevezni fog. Ugye a mostani Phi generáció is már bemutatkozik alaplapi processzorként, ami képes OS-t futtatni. Én azt képzelném, hogy Intel ezt az architektúrát fogja IGP-nek is felkészíteni, de akármennyire is butítják, az lesz az egyik legkomolyabb compute képességű IGP (még ha nem is a leghatékonyabb, de a legnagyobb tudású).

  Intel is szeretné compute irányba tolni a dolgokat, nem véletlen sírnak OpenCL-ben írott játékokért.

  Szerintem ma már annyira sokat tud bármelyik ultramobil SoC, hogy ha nem lenne a parasztvakító PR, akkor egyedül a tudás számítana. Igazából ***vára mindegy, hogy egy mobiltelefonban 500 GFLOPS vagy 1 TFLOPS számítási teljesítmény van. Az sokkal többet számít, hogy tudjon minden API-t, és rugalmas legyen. Ehhez pedig az egyedüli út, az általános célú "tranyópazarlás".

• #189 Meteorhead aktív tag Abu85 #184

  Új Válasz 2014-02-09 17:16:19 #189

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz Abu85 #184 üzenetére

  Miért nem kell az AMP-ot idesorolni? Csak nekem vannak olyan lázálmaim, hogy mennyivel szebb lenne az élet, ha grafikát compute oldalról lehetne csinálni, és nem ennyire vastag API-kon keresztül? Ha a fix funkciós egységeket mind elérhetővé tennék built-in függvényeken keresztül egy compute nyelvben? Akkor tényleg akármilyen pipeline-t össze lehetne rakni.

  Kérdezték még, hogy Intel mennyire örül/nem-örül ennek. NV és Intel biztosan örül annak, ha egy Mantle-hez hasonló, számukra is kényelmesen implementálható, életképes API-t kapnak ingyen, amihez csak drivert kell írni.

  Ami a leginkább érdekelne, hogy az Intel Skylake fejlesztésről mit lehet tudni. Annak mit fog tudni az IGP-je?

• #81 Meteorhead aktív tag gbors #79

  Új Válasz 2014-02-07 12:58:50 #81

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz gbors #79 üzenetére

  A harmadik nem kussol, hanem kijelentette, hogy a drivereit újraszervezi, hogy hatékonyan tudjon "emulálni" minden API-t, mert nekik sincs fingjuk sem, hogy mi fog befutni.

  MS csak annyit lát ebből, hogy hirtelen a lovak le***rják a gyeplőt, és ahányan vannak, annyi irányba szaladnak.

• #80 Meteorhead aktív tag partxxx #70

  Új Válasz 2014-02-07 12:56:31 #80

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz partxxx #70 üzenetére

  Amennyire én tudom, nem kell hozzá DX. Sőt... a BF4 motorjában is teljesen külön leképező a DX-es és a Mantle leképező. Azt tudom elképzelni max, hogy a shadernyelve lehet HLSL. Abu persze kijavít ha hülyeségeket mondok.

  Amikor motort írnak, akkor a leképező az mindig egy wrapper valami API köré. Ha az ember olyan leképezőt akar írni, amiben lehet több szálból rajzolni, akkor vagy gagyi mutexekkel rakja körül a kritikus rajzolási rutinokat, és gyakorlatilag visszakapja a soros rajzolást, vagy deferred contextet használ és hónapokig tuningolhatja a wrappert, mire a motorháztető alatt a driver és az API értelmesen többszálasít, vagy a Mantle-t wrappeli, aminél tized annyi munkával sokkal jobb teljesítmény hozható ki.

  Ha lenne publikus SDK, akkor az ilyen hanadók, mint én is tudhatnák pontosan hogy a rákba is működik. Amennyire tudom, semmi köze a DX-hez, és teljesen más utat járnak be a rajzolási parancsok.

• #39 Meteorhead aktív tag wednesday #25

  Új Válasz 2014-02-07 11:23:34 #39

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz wednesday #25 üzenetére

  Hát ez az, ami miatt itt tartunk. Pont, hogy nem lesz hasonló a felépítés. Ha a gyártók nem erőltetnék a saját felépítésüket, amiket nem dollár milliókkal, hanem dollár milliárdokkal fejlesztettek ki, akkor már rég mindenki besorolt volna a HSA alapítványba, mert az tényleg hordozható módon elintézne mindent. CPU szintű szolgáltatásokon nemigen lehet továbblépni. Mindenkinek a vasa 1-2 nüansznyi dolgot nem támogat, és nem is hajlandó a fejlesztéseit abba az irányba vinni, hogy azokat kiküszöböljék.

  MS-nek végképp nincs akkora pélója, hogy rávegye a gyártókat, hogy változtassanak a saját architektúráikon, és a DX-hez igazítsák. Sokkal inkább fordítva történik: az MS igazítja a gyártók igényei szerint az API-t. Ezért (is) fejlődik olyan nagyon lassan, mert eléggé divergálnak a gyártók elékpzeléseik.

• #38 Meteorhead aktív tag partxxx #34

  Új Válasz 2014-02-07 11:19:16 #38

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz partxxx #34 üzenetére

  Mi értesz az alatt, hogy "dx felett áll"?

• #20 Meteorhead aktív tag vinibali #3

  Új Válasz 2014-02-07 10:49:28 #20

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Meteorhead

  aktív tag

  válasz vinibali #3 üzenetére

  Visszafele két ok miatt nincs boldogság:

  Egyfelől nem feltétlen érdeke a régi rendszereket promotálni az újakkal szemben avval, hogy minden kemény dollármilliókat felemésztő fejlesztés elérhető a régebbi platformokon is. Hiába lenne képes a vas elvinni, nem feltétlen éri meg működésre bírni.

  Pont a visszafele boldogságtól olyan tetű lassú a DX. Egyszerűen túl sok runtime lehetőséget kell lekezelni. Egyszerűen nagyon hamar kezelhetetlen lesz az API implementáció. Eszeveszettül sokat lehetne írni arról, hogy ez miért van így, de érdemi előrelépést csak úgy lehet tenni, hogy kukázni kell rengeteg mindent, ami régi.

  Az új DX ha igyekszik hasonlítani az XBox One low-level API-jához, akkor egészen biztosan lesz Unified Memory, ami nélkül életképtelen lesz. Valószínűleg nem lesz core feautre, mert NV csak ARM-os memóriacímteret képes kezelni koherens módon, és nem fog magával kibabrálni MS annyira, hogy a két nagy gyártó közül az egyiknek implementálhatatlanná teszi a specifikációt. Többszinten támogatható, opcionális extension lesz, Tiled Resources-hoz hasonlóan. Ennek a megvalósításához természetesen új WDDM is kell, ami nem kotlik olyan szigorúan a memória felett, hanem direktebben lehet garázdálkodni.

  Új DirectX-hez új Compute Shader is jár, és reménykedhetünk VS2014-ben (ha így fogják egyáltalán hívni) új C++AMP fordítóban is, ami kezelni is tudja már a Unified Memoryt. Ha eltűntetnék a megszorítást, mely szerint const referenciát csak AMP array-re és array_view-ra lehet állítani, akkor elkezdődhetne a feketemágia. (Például a BLAS könyvtárat meg lehetne írni teljesen Expression Template alapokon, és minden compile time optimalizálódna ki az utolsó regiszterig.)

  Röviden: mennél nagyobbat mernek lépni, annál jobb.

Új hozzászólás Aktív témák