- Kisebb méretben is elérhető a OnePlus Watch 3
- Belépő táblagépet is villantott a OnePlus
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- iPhone topik
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- Xiaomi 14T - nem baj, hogy nem Pro
- Feljutott a G96 a Moto széria csúcsára
- Samsung Galaxy Watch7 - kötelező kör
- Mobil flották
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Azonnali navigációs kérdések órája
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Realme GT 2 Pro - papírforma
Új hozzászólás Aktív témák
-
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#195
üzenetére
Valójában az kisebb mértékben számít, hogy mi mit emulál, és ez mennyi többletterheléssel jár. Úgy néz ki, hogy sokkal nagyobb szerepe van annak, hogy egy cég mennyire nyitott az adott architektúráról, mennyire rendezkedett be úgy, hogy a fejlesztők képesek önálló munkavégzésre, mert mostantól a fejlesztő szállítja a korábban driverben lévő funkciókat a programon belül. Ha nem mondják el nekik, hogy hogyan kell dolgozni az architektúrákra, akkor nem tudnak hatékony optimalizálást szállítani.
Aki dolgozik DX12-vel, vagy bármilyen low-level API-val, az egyértelműen a toolokra és a dokumentációkra, vagy ezek hiányára panaszkodik. Hiába van az Intelnek kétharmados részesedése a fejlesztő nem tudja lekérni azt az assembly szintű kódot, ami megmutatja, hogy a magas szintű forrás hogyan fut magán az architektúrán. NV-n dettó ugyanez. Ha ezt nem látja a fejlesztő, akkor nem tudja hol a szűk keresztmetszet és nem tudja javítani azt forráskódban. Emellett szintén nem ismert, hogy bizonyos hardverek mit szeretnek és mit nem, például az NV nem mondja meg. Pedig aszerint kellene meghozni a különböző döntéseket, hogy milyen erőforrás-formátumokat használjanak, de nem tudják meghozni, mert csak azt ismerik, hogy a konzolból a GCN mit szeret. Persze valaki úgy áll hozzá, hogy ha xy cég hallgat, akkor áthozzák a kódot a konzolból és majd ha belassulnak a hardvereik, akkor megered a nyelvük, és elkezdik készíteni a dokumentációkat. De ez nem megoldás, mert ez csak a DX12 gyengeségeit mutatná meg a világnak, vagyis azt, hogy nagyrészt a fejlesztőn múlik a program sebessége, és abba a gyártóknak gyakorlatilag nincs közvetlen beleszólása.
A Vulkan esetében például már gondol erre a Khronos és készítenek olyan conformance tesztet, aminek az eredményét a Vulkan tagságot igénylő fejlesztők megkapják. Ez ugyan nem dokumentáció, de alapvetően ad egy támpontot, hogy nagyjából mi hogyan fut a különböző architektúrákon, és ez így segít meghozni bizonyos döntéseket. Nem fog segíteni komolyabban optimalizálni, de legalább irányt mutat. Készül SPIR-V disassembler is, ami ugyan nem ISA disassembler, de a fejlesztők azért jóval többet láthatnak majd abból, hogy a magas szintű kód legalább a közbülső rétegre hogyan fordul le, és ott tudnak kísérletezni, hogy az adott hardvert esetleg mi gyorsíthatná be.
Az, hogy több gyártó sem low-level barát a kialakított ökoszisztémát tekintve jóval nagyobb baj most, mint azt nézegetni, hogy mennyi extra többletterhelés a binding TIER_2 a TIER_3-hoz viszonyítva. -
#188
Abu85
HÁZIGAZDA
hugo chávez
#163
Abu85
HÁZIGAZDA
válasz
hugo chávez
#163
üzenetére
Amit én kiszedtem belőlük az az, hogy elméleti síkra lebontva tudnák támogatni mindkettőt, mert hasonló kiterjesztéseket OpenGL-en is támogatnak vagy terveznek támogatni. De nem feltétlenül akarják. A konzolokon ez a két funkció meg van oldva és az AMD-nek az a jó, ha a konzolos kódot hozzák át PC-re a fejlesztők. Egyrészt azért, mert az fut mindenen, tehát eleve át kell hozni, másrészt a Radeonok abban erősek, míg a többi architektúra nem az. A Microsoft nem írja elő, hogy ha egy hardver képes lenne valahogy támogatni az adott funkciót, akkor arra kötelező is az adott gyártónak egy implementációt írni. Lásd az aszinkron compute. Azt az Intel képes lenne támogatni a Gen8-cal, de nem teszik, mert számukra nem jó.
A DirectX 12 szerintem ezért lett ilyen bonyolult. A Microsoft nem szólt bele, hogy mit hogyan lehet. Megadják a lehetőséget, aztán a gyártók úgy barmolják azt szét, ahogy akarják, nekik ott az Xbox, meg az igazán fontos újításokat előírták kötelezőre és azzal már a PC ellesz, az garantálja a futást mindenen.(#183) morgyi: Semmit sem dobtak el az MS-nél. Csak nem akarnak részt venni a gyártók közötti politikai jellegű cicaharcban. Éppen ezért kialakították úgy a DX12-t, hogy van egy kötelezően támogatandó rész, amit a Microsoft fontosnak gondolt, és valóban az is, így ez biztosítja, hogy minden hardveren elindul az alkalmazás és a hatékonyságot megkapja. Aztán csináltak egy lazán ellenőrzött részhalmazt egy rakás opcionális fícsőrrel és azon belül a gyártók ölhetik egymást. Úgy tesznek egymásnak keresztbe, ahogy akarnak. Ez a részhalmaz úgy van felépítve, hogy a felhasználói élményt ne rontsa a gyártói cicaharc.
Szerintem a Microsoftnak elege van abból, hogy három ilyen hülyét kell pesztrálnia, és a jövőben ebben nem is vesznek részt. Ott az Xbox One, hamarosan futtat Windows Store alkalmazásokat is. Kvázi PC-vé válik. Az alapja a DX12-nek jó szerintük, és ránézve a speckókra szerintem is. A többit boxolják le. -
Abu85
HÁZIGAZDA
Pedig a PhysX 3.3 nem rossz. Nem egy Havok, pénzért még mindig nem vennék meg, de közel sem olyan rossz és lassú mint régen. És már nyílt is. Persze az igaz, hogy ma a legnagyobbak pont arra mennek, hogy inkább fejlesztenek saját motort. Ez nyilván nem kedvez a middleware-eknek. Még a Havoknak sem.
-
Abu85
HÁZIGAZDA
A PhysX-nél azért érzed, hogy megy a kukába, mert nem nyitják meg és a Havok annyira gyors, hogy megalázza. Inkább fizetnek a fejlesztők a sebességért. A CPU-s részt most ezért nyitották meg.
A GameWorks céljával ellentétes, hogy megnyissák. Az NVIDIA azt akarja, hogy kontrollálják a sebességét, ha üzletileg az a jó, ha az effekt lassan fut, akkor olyan kódot adnak. Ez a cél. Ha megnyitják, akkor nem volt értelme a GameWorksöt kidolgozni, mert elveszti az értelmét. A HairWorks esetében is az, hogy nem túl szép egy sokad rangú dolog az NVIDIA számára. Nem a szépség termeli a profitot, azzal maximum azt érik el, hogy szélesebb lesz a mosolyod. -
#152
Abu85
HÁZIGAZDA
Menthirist
#147
Abu85
HÁZIGAZDA
válasz
Menthirist
#147
üzenetére
Értem én, nyilván senkinek nem tetszik, ha hülyének nézik. De az NV-t ez nem érdekli. Az érdekli, hogy ne légy elégedett az egy éve vásárolt hardvereddel. Vegyél mellé még egyet vagy egy újabbra cseréld le. Ez a célja a GameWorksnek. Ha elfogadod, akkor mehetsz a kasszához, a következő évben újra megteszik és így tovább. Egyelőre működik. Ha pedig a felhasználó elfogadja, hogy az NVIDIA-nak teljhatalma van afelett, hogy a kártyáján xy effekt milyen lassan futhat, akkor vegyen nyugodtan GeForce-ot. Ennyire egyszerű a helyzet.
Azt egyébként senki sem vitatja, hogy a saját felhasználóidat szívatni anyagi érdekből gonosz dolog. Majd ha nem fizetnek mint a katonatiszt, akkor átgondolják ezt a stratégiát. -
Abu85
HÁZIGAZDA
válasz
Callisto
#146
üzenetére
Ha akarjátok szidni a HairWorksöt, akkor a minősége kifogásolható. Nincs normális támogatása átlátszóságra, AA-ra és önárnyékra. Ezért szidható. Persze emellett az erőforrásigényét is fel lehet hozni, de állítsd be 16x-re a tessfaktort, tényleg semmi különbség nem lesz.
A céljuk az volt, hogy a régebbi GeForce tulajok új kártyát vegyenek, vagy vegyenek még egyet és kössék SLI-be. Ezt valószínűleg elérik, ha nem teszik konfigurálhatóvá a tessfaktort a driverben. Az, hogy az AMD-sek meg tudják oldani ezt nem számít nekik. Nem tekintik öngólnak, mert a saját felhasználóikat akarják vásárlásra kényszeríteni.
-
Abu85
HÁZIGAZDA
A HairWorksön nem tudom mit paráztok. Pont, hogy a Radeon tulajokkal nincs kibaszva. Beállítod a 16x faktort a driverben és alig eszik valamit, miközben a minősége nem változik.
A GeForce tulajok ezért akarják a hivatalos fórumon ezt a beállítást bele a driverbe, mert ők is nyerni akarnak 8-15 fps-t minőségvesztés nélkül, csak ezt most nem tehetik meg. Talán megenyhül az NV szíve és kisegíti őket, bár kétlem, hogy megtörténik, mert azzal a HairWorks elveszti a célját.Szóval a HairWorks esetében olyan dologért szidjátok az NV-t, amiből a Radeon tulajoknak pont nem származik kára. A GeForce tulajok felháborodása jogos lenne.
-
Abu85
HÁZIGAZDA
Az aszinkron DMA-ról sem érdemes megfeledkezni. Nem kell leállítani a futószalagot memóriamásolásoknál. Azért az nem kicsi előny. Az alapból elérhető kisebb overhead meg többszálú izélés mellett ez a két aszinkron funkció tűnik a legfontosabbnak, mert ezekből tényleg sok teljesítményt lehet kihozni.
Valószínűleg a kétszer több parancslista nem fog sokat számítani. Inkább az architektúrák belső különbsége lesz a meghatározó.
-
Abu85
HÁZIGAZDA
Olvasd el a korábbi híreket. Mindegyikben ki van emelve, hogy az adatok az előzetes specifikációkból származnak, tehát azok még változhatnak. A specifikációk három hónap alatt sokat változtak. Elég csak a bekötési modellre gondolni, amelyre ott egy összefoglaló hír is, hogy miképp változott meg az egész, vagy az, hogy az aszinkron shader kezdetben elfogadta azt a hardvert is, ami nem tudott egyszerre grafikai és compute parancsot kiadni, míg ma már ezt nem fogadja el, tehát kiesik a Kepler és a Maxwell v1, vagy hogy bukták a typed UAV loadsot. Viszont márciushoz képest nyertek TIER_2-t a bekötésnél.
Így alakul az API a megjelenés előtt, de ez most itt a végleges, amiből megint le van írva, hogy nem minden végleges, de ezt külön táblázatba szedtem. -
Abu85
HÁZIGAZDA
válasz
#85552128
#29
üzenetére
Nem ezért van.
Minden funkció különálló! És ez a lényeg.
Van különálló bekötési modell TIER_1/2/3 szinttel. Van Tiled Resources külön TIER_1/2/3 szinttel. Stb.
Nem függ össze, az hogy a hardver valamelyik funkcióból csak a TIER_1-et támogat, de a másikból TIER_3-at. Ez azért van, mert a paraméterezés minden funkciónál önálló. Önálló a funkció meglétének ellenőrzése és önálló, hogy azon belül milyen meghatározott szintekből mit támogat a hardver.
Lehet, hogy itt van egyébként, ami miatt ez nehezen érthető. Tehát a bekötési modell TIER_1/2/3-nak semmi köze a Tiled Resources TIER_1/2/3 szintekhez. Ezek függetlenek egymástól. -
Abu85
HÁZIGAZDA
Nem számol más részegység grafikai feladatokat. A többletterhelés azt jelenti, hogy a processzornak van egy kis munkája, hogy a bekötés megtörténjen. Nagyon leegyszerűsítve a cél az adott erőforrást a multiprocesszorba eljuttatni. A TIER_1-en ezt nagyrészt a CPU köti be, ettől lesz a többletterhelés relatíve magas, a TIER_2-nél a bekötés a mintavételezőbe történik, és onnan még lesz egy kis többletterhelés mire eljut a multiprocesszorba. A TIER_3-mal direkten a multiprocesszorba jut el az erőforrást, tehát nincs vele munka.
Ha mindent nézünk, akkor egyetlen hardver támogatása sem teljes, így lehetségesek olyan játékok, ahol bizonyos effektek GCN-en, míg bizonyos effektet Maxwell v2-n nem kapcsolhatók be. A többi architektúra jóval limitáltabb tehát több lesz a hátrány. -
Abu85
HÁZIGAZDA
Ha a bekötési modellről beszélsz, akkor általánosan le van írva a cikk végén, de most bemásoltam a korábbi, amúgy linkelt hírből a különbségeket. A lényeg az, hogy minél nagyobb a TIER szint annál kisebb a többletterhelés a processzoron és annál több effektet tudsz aktiválni, ha az adott programban a TIER_1, vagy a TIER_2 szintre vonatkozó erőforráslimitek nem elegek.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#15
üzenetére
Azóta változott. Abban a prezentációban egy csomó dolog máshogy volt, mint ami ma szerepel a lényegében végleges speckókban. Például bukta számos hardver a typed UAV loadsot. A bekötés ki lett emelve, stb. A feature level önmagában így nagyon kevés információ, mert el lehet érni rengeteg funkció támogatása nélkül is. Persze a miheztartás végett beleírtam, de a táblázatos rendszer most lényeges több információt ad át a hardverek képességeiről, hogy az egyes funkciókra vonatkozóan milyen a támogatás. Van-e vagy nincs, illetve ahol ez specifikálva van ott milyen a TIER kategória.
-
Abu85
HÁZIGAZDA
A Tiled Resources nem kötelező. Egy csomó dolog ki lett itt emelve a feature level szintekből. Ez valóban nagyon bonyolult így. A feature level innentől kezdve nem elég információ, mert rengeteg funkció támogatása nélkül is el lehet érni egy szintet, és ez igaz fordítva is. De ezért is készítettem táblázatot az egyes funkciókra lebontva, hogy egyszerű legyen értelmezni. Ezeket a funkciókat úgyis külön ellenőrzi az adott program. Ha így nézitek, akkor szerintem sokkal egyszerűbb látni, hogy mi mit támogat.
Új hozzászólás Aktív témák
Hirdetés
- iPhone topik
- EAFC 25
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- gban: Ingyen kellene, de tegnapra
- Home server / házi szerver építése
- Nagyrobogósok baráti topikja
- iPhone-t használók OFF topikja
- Xiaomi 14T - nem baj, hogy nem Pro
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Simbin topic (GTR, Race07, GTR Evolution, RaceRoom Racing Experience, stb.)
- További aktív témák...
- Microsoft Surface Pro 7 - Újszerű, dobozban, gyári töltővel, billentyűzettel
- Lenovo 13 Core i3-7100 Cpu laptop eladó
- LG OLED Televíziók: FRISS SZÁLLÍTMÁNY -30%
- Bomba ár! HP ProBook 450 G5 - i5-8GEN I 8GB I 256GB SSD I 15,6" FHD I HDMI I Cam I W10 I Garancia!
- AKCIÓ! Dell Precision 5820 XL Tower PC - Xeon W-2123 112GB RAM 512GB SSD 1TB RX 580 8GB Win 11
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest