- Google Pixel 9 Pro XL - hét szűk esztendő
- iPhone topik
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Xiaomi 15 - kicsi telefon nagy energiával
- Android alkalmazások - szoftver kibeszélő topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Eurós árlista a Google Pixel 10 telefonokhoz
- Magisk
- Samsung Galaxy S23 Ultra - non plus ultra
- Motorola G86 - majdnem Edge
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A HPC piacon is nagyon fontos ez. Sőt, talán fontosabb, mint más piacokon. Olyan platform kell, amivel az új architektúrák érkezésével a kódot nem kell a nulláról újraírni.
A konzumer szinten pedig olyan platformra van szükség, ahol az egyszer megírt kód hatékonyan skálázódik a különböző hardvereken.Egy GCN S.I./C.I.-re megírt C/C++ fordító a fenti fejlesztői igényekkel szembemegy.
-
#196
Abu85
HÁZIGAZDA
Meteorhead
#195
Abu85
HÁZIGAZDA
válasz
Meteorhead
#195
üzenetére
Nekünk olyan platform kell, amivel egyszerre lehet megoldani azt, hogy az egyszer megírt kód teljesítménye minden architektúrán skálázódjon.
Ha az AMD írna egy sima C++ fordítót GCN-re nem sokat érne, mert azzal a fejlesztő célozhatná ezt az architektúrát és kész. Minden megvan a hardverben ehhez, hiszen vannak virtuális funkciókat, kivételkezelés, rekurzió, pointerek, de az architektúra generációról-generációra változik, így folyamatosan új fordító kellene. Teljes architektúraváltásnál meg nulláról kellene ezt újra felépíteni. Márpedig úgyis lesz idővel új architektúra, hiszen épeszű cég nem fogja a skálázhatóságot orbitális méretű gyorsítótárakra bízni, ami elveszi a GPU hatékonyságát.Olyan rendszer kell, amivel a ma írt kód 15 év múlva is futni fog.
-
#194
Abu85
HÁZIGAZDA
Meteorhead
#193
Abu85
HÁZIGAZDA
válasz
Meteorhead
#193
üzenetére
Technikailag a Keplerben és a GCN-ben is megvan minden, hogy bebootoljanak egy OS-t. Még a Fermi is jó lehet itt, de akár az ARM Mali-T600/700 is.
Ha strukturálisan nézed a GCN CU és a Silvermont Larrabee verzióját, akkor túl sok eltéréssel nem találkozol.
GCN:decode == programozható skalár egység == 4 x 512 bites SIMD - 4 x 64 kB regiszterterülettel (+64 kB LDS) == cache rendszer
Larrabee (Silvermont) mag:
decode == programozható egység == 512 bites SIMD - 8 kB regiszterterülettel (hagyományos értelemben nincs LDS) == cache rendszer
Az értékek mások, de a felületes struktúra azonos. Az OpenCL-ért elsősorban azért sírnak, mert ezt a rendszert ebben a nyelvben a legegyszerűbb hatékonyan programozni.
-
Abu85
HÁZIGAZDA
Az NV és az Intel is az ultramobilt célozza. AZ Intel csupán tapasztalatlan a grafikus architektúrák fejlesztésében. Hiányzik az az egy-két évtized, amennyivel a többiek ezt az iparágat korábban kezdték.
Az NV-n igazából eléggé egyértelmű, hogy a Keplerben kevés a regiszter, nincs OOO logikás parancsprocesszoruk, ultramobil szintű a bájt/FLOP mutatójuk, és gyenge a flow control
Ha számokban megnézed a Tahiti-t és a GK104-et, akkor igen világos a koncepcióban az eltérés:
Tahiti: 1,5 bájt/FLOP, 8 MB regiszter, két külön OOO logikás compute parancsprocesszor, programozható skalár egység
GK104: 0,33 bájt/FLOP, 2 MB regiszter, nincs külön compute parancsprocesszor, nincs programozható skalár egység
Hawaii vs. GK110-re is megnézhetjük:
Hawaii: 1,5 bájt/FLOP, 11 MB regiszter, nyolc külön OOO logikás compute parancsprocesszor, programozható skalár egység
GK110: 0,66 bájt/FLOP, 3,75 MB regiszter, nincs külön compute parancsprocesszor, nincs programozható skalár egységCserébe persze a Kepler a Tegra K1-ben kisebb helyet igényel és durván korlátozott TDP mellett jobban teljesít majd, mint a kis AMD SoC-okban a GCN architektúra.
-
#190
Abu85
HÁZIGAZDA
Meteorhead
#189
Abu85
HÁZIGAZDA
válasz
Meteorhead
#189
üzenetére
Egyelőre csak az AMD-nek érdeke megszavazni egy teljesen compute irányra épített API-t a GAB-ban. A többieknek ez nem ideális.
A compute nincs ingyen. Szükség van nagyon sok regiszterre, hatékony flow control, nagyon gyors elérésű elsőszintű cache-ekre és lehetőleg OOO logikájú compute parancsprocesszorokra. Ezek mindegyike beépíthető, de mindegyik ilyen extra fogyasztani fog. Nem is keveset.
Jelenleg az AMD kivételével mindenki az ultramobil piacot célozza a grafikus architektúrájával, tehát a fenti területeken kompromisszumot fognak kötni, hogy ne fogyasszanak túl sokat. Éppen ezért a compute csak korlátozott mértékben jó a többség számára. Ezt az MS-nek is figyelembe kell venni. -
Abu85
HÁZIGAZDA
válasz
schwartz
#162
üzenetére
Már régebben elment az NV-től. Igazából ő volt az aki a TWIMTBP programot vezette még 2010 előtt. Akkor átrakták a Tegrára, de később a sztereó 3D-re is dolgozott. Viszont különböző nézeteltérések miatt otthagyta az NV-t. Akkor a Rightware-hez, majd kicsivel később az AMD-hez ment.
Ezek nem nagy dolgok. Mármint komoly nevű emberek mennek ide-oda nap mint nap. Nemrég például prof/automotive üzletágat menedzselő Nick Pandher hagyta ott az NV-t és csatlakozott az AMD-hez.
De például az AMD-től is ment már el ember régebben. Például Richard Huddy az Intelhez. Elég sokáig pletykálták, hogy brutális fizetést ajánlottak neki, amire nem szokás nemet mondani. Ő vezette az AMD-nek 2010 előtt a Gaming Evolved programot. Azóta ezt Ritche Corpus vette át. -
#184
Abu85
HÁZIGAZDA
tatararpad
#131
Abu85
HÁZIGAZDA
válasz
tatararpad
#131
üzenetére
Természetesen a DirectCompute vezető szerephez jut, hiszen compute-ra épül az egész next-gen. Viszont az OpenCL-t és a C++ AMP-t nem kell ide sorolni. A grafikus API-ban kell egy compute pipeline és kész. Igazából itt a DirectCompute már ma is jól működik, csak apróbb limiteket kell kiterjeszteni.
Az Xbox One szereplésére az Xbox One-on kell reagálni. De tudtommal egymilliárd dollárt költenek majd exkluzívokra szóval ez a két hónap nem igazán érdekli őket. Most csak felméri egymást a Sony és az MS. Az igazi harc majd 2015-ben kezdődik meg.
A Mantle fejlesztése addig tart amíg van rá igény. Nagyon kis költség ez az API, ha csak egy partner is támogatja, akkor már megéri.
Az összes erőforrás explicit kihasználása megoldható. A kérdés, hogy megoldják-e. Korai lenne erre válaszolni.
-
Abu85
HÁZIGAZDA
Azért a százalékoknál +10-30% a nagy átlag, van ennél kevesebb, de van aki +100%-ot is mért. Fix százalékot viszont nem érdemes mondani. Ahol a Mantle kicsi többletterhelésből profitál ott a gyorsulás 200-400% közötti, lásd Nitrous.
Én a compute shadert mondtam a DiRT 2-re. Tesszellátort ez a játék alig használt. Amit pedig mondtam, hogy a DiRT 2 teljes pompájához DX11-es hardver kellett. Nem mondtam, hogy vegyen AMD-t, hiszen az NV is készített DX11-es hardvert. A DX11 támogatás eléggé egyértelmű, hogy nem gyártóspecifikus. Az NV-nek sem én mondom, hogy hónapokkal maradjon le a legújabb DX API-k hardveres támogatása tekintetében az AMD-hez és az Intelhez képest. Ők döntenek úgy, hogy a hardver tudása nem olyan fontos. Ezzel nem értek egyet, de elfogadom az álláspontjukat.
-
Abu85
HÁZIGAZDA
A saját magam által leírt hsz-ekért felelek. Arról tényleg nem tehetek, hogy félreértették a tartalmát. Nem véletlenül írtam oda a relevánsat.
A Mantle az első PC-s API, ami monolitikus futószalagot, asszinkron compute-ot, explicit memória-hozzáférést, valós többszálú és rejtett driver szálak nélküli leképzést, limit nélküli erőforrás-használatot és explicit multi-GPU támogatást kínál fel. Ezt nehéz nem úgy eladni, mint forradalmi változás, hiszen nem tudok olyan API-t mondani, ami ezek egyikét már tartalmazta volna, olyat meg pláne nem, ami ezek összességét egyszerre kínálta volna fel.
Általában ha valaki jelentkezik egy olyan dologgal, aminek az előrelépése a korábbi opcióhoz képest nagyságrendi, akkor az forradalminak tekinthető. -
Abu85
HÁZIGAZDA
Idézzük be teljesen: "A DX11 ezen a futószalagon csak az utolsó releváns DX API, ettől még fejlődünk tovább." Mindig is a futószalagról volt szó, hogy a mostanihoz mit tudsz még hozzátenni. Őszintén szólva az IA-tesszellátor-VS-GS-raszter-PS-output sor egyes részein lehet módosítani, de sokkal előnyösebb, ha ezt az egészet szétrobbantjuk, és akkor lesznek fix funkciós és programozható erőforrások, amikből lehet legózni különböző egyéni futószalagokat.
Erre megy ma a Mantle, a D3D11.X és a libGNM, de nyilván nagyon esélyes, hogy az új PC-s DX és OGL is ilyen irányba fog lépkedni. -
Abu85
HÁZIGAZDA
Azokban a hsz-ekben is le van írva, hogy lesz! több DX, csak a fix futószalaghoz való kötődés szűnik meg. Ez az irány már akkor egyértelműen látszott. Ma már ezt konkrétan támogatja a Mantle, a Direct3D 11.X és a libGNM. Mindegyik API-ban lehetőséged van úgymond szoftver rendert írni. A mostani futószalaghoz nem tudsz mit hozzátenni, így menni kell a monolitikus irányba, amikor a fejlesztő összelegózza a saját fotószalagját.
Leírtam, hogy lehetőség lesz egyéni futószalagok kialakítására. A PC-n és a két új konzolon is van már most olyan API, ami ezt lehetővé teszi. Hát tényleg mekkora katyvasz, 2009-ben leírtam, hogy így lesz ... De szerintem már korábban is írtam a szoftver renderről, mint reális és vállalható lehetőségről.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#101
üzenetére
Én cáfoltam a nemlesz DX12 dolgot: [link]
Olyannyira tudtam, hogy készül egy radikálisan új verzió, hogy erről már az előző év közepén is írtam: [link]A forrás maradjon az én titkom, de tagja a GAB-nak, szóval eléggé megbízható.
A szoftver rendert pedig kifejtettem. Az lesz és van. Mondom a Mantle például PC-n már támogatja, hogy egyedi futószalagot írj a hardverre, de a két új konzolban is benne van ez a képesség. Logikus evolúciós lépcső ezt az új DirectX-ben is megoldani.
Ha a szoftver renderre úgy gondolsz, hogy egy központi processzoron megy, akkor olyan nem lesz. Egyes lépcsőket nem lehet hatékonyan emulálni. Például textúrázás. -
Abu85
HÁZIGAZDA
válasz
#06658560
#53
üzenetére
Keverjük a fogalmakat. A szoftver renderhez leginkább monolitikus futószalag kell. Olyan sosem lesz, hogy a CPU-n fog futni minden, mert túl kevés hozzá a számítási teljesítménye, és a fizika törvényei sem fognak belátható időn belül megváltozni. De olyan simán lesz, hogy a hagyományos futószalag funkciója nincs előre kialakítva. Van pár lépcső, és azokat összeillesztve kialakíthatja mindenki a saját futószalagját. Ezt a Mantle már támogatja, sőt az X1-es Direct3D11.X és a PS4-es libGNM is tartalmaz ilyen funkciókat. Semmi akadálya nincs annak, hogy a következő DX-ben ne legyen egyénileg felépíthető futószalag, hiszen a mai hardverek ezt támogatják. És ez technikai értelemben szoftver render, mert nem a bedrótozott futószalagot használod.
-
#27
Abu85
HÁZIGAZDA
Meteorhead
#20
Abu85
HÁZIGAZDA
válasz
Meteorhead
#20
üzenetére
A Unified Memory nem gond. Egy közös IL kell és kész. A HSA sem más és az is támogat ARMv8, MIPS64 és AMD64 architektúrákat egyszerre. Szóval az NV ARM-os integrációja ilyen koncepcióval simán használható. A queue nyelv a gond. Ott nincs egyetértés a gyártók között. Legalábbis a HSA-n kívül semmiképp.
(#25) wednesday: Természetesen az új API hardveres funkciókat is követel. De ha az Xbox One API-ja az alap, akkor nem feltétlenül szükséges hozzá új hardver. Attól függ, hogy a base funkciók mennyire komplexek. Ha jól rakják össze, akkor a GCN és a Kepler megfelelhet. Ha többet akarnak, akkor csak a GCN lesz jó. Ha még több kell, akkor pedig mindenkitől új hardverekre lesz szükség. Ha van egy kis eszük, akkor a base funkciókkal a GCN/Keplert célozzák. A többi pedig jó lesz kiterjesztéssel.
-
Mantle, OpenGL vagy DirectX az mindegy. Az a lényeg, hogy legyenek portolhatók a konzolról az új generációs effektek. Mindegy, hogy mivel érjük ezt el, de a szabványos megoldás az mindig jobb.Új hozzászólás Aktív témák
Hirdetés
- Bomba ár! Dell Latitude 5495 - Ryzen 5 I 16GB I 256SSD I 14" FHD I HDMI I Radeon I Cam I W10 I Gari!
- AKCIÓ! Gigabyte H610M i5 12400F 16GB DDR4 512GB SSD RX 6700XT 12GB Zalman S2 TG Seasonic 650W
- Bomba ár! Dell Latitude 7320 - i5-11GEN I 8GB I 256SSD I HDMI I 13,3" FHD I Cam I W11 I Garancia!
- Game Pass Ultimate előfizetés azonnal, élettartam garanciával, problémamentesen! Immáron 8 éve!
- Nvidia Quadro P400/ P600/ P620/ P1000/ T400/ T600/ T1000 - Low profile (LP) + RTX A2000 6/12Gb
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest