- Telekom mobilszolgáltatások
- Motorola Edge 40 neo - színre és formára
- Az okosórák meghódítására készül a Galaxy AI
- Bivalyerős lett a Poco F6 és F6 Pro
- Xiaomi Mi 8 - így csinálunk csúcsmodellt Mi
- Motorola Edge 30 Ultra - a 200 megapixeles kérdés
- Milyen okostelefont vegyek?
- Huawei Watch Fit 3 - zöldalma
- Google Pixel topik
- Android szakmai topik
Hirdetés
-
Ősszel jönnek a Toshiba új, vállalati szegmensbe szánt merevlemezei
ph A kritikus üzleti applikációkhoz gyártott, CMR-es adattárak kétféle interfésszel vásárolhatók majd meg, és 10 TB-ig fedik le az igényeket.
-
S.T.A.L.K.E.R.: Legends of the Zone Trilogy - Befutott a MOD támogatás
gp Mostantól a konzolos kiadásokhoz is elérhetők a különböző rajongói módosítások.
-
Ellopták a Tesla akkumulátor-titkait
it Beperelte egy korábbi beszállítóját a Tesla, és azzal vádolja, hogy üzleti titkokat lopott a Tesla akkumulátorgyártási technológiájával kapcsolatban.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
namaste #24208 üzenetére
Bocs, de ez megint nem ilyen egyszerű. A TFLOPS és a blending teljesítmény igazából csak architektúrán belül lényeges. Elsődlegesen azért, mert az AMD és az NV ma már eléggé hibrid architektúrákat tervez. Nem igazán IMR-ek, de nem is igazán TBR-ek. Valahol a kettő között vannak, de az gyártótól függ, hogy mennyire húznak az egyik irány felé. Az NV a Maxwell óta inkább a TBR felé húz, ami miatt jóval aktívabban használnak mozaikos optimalizálást, mint az inkább IMR felé húzó AMD GCN. Ennek a hátránya, hogy jóval nagyobb blending teljesítményt igényel, viszont kisebb terhelés a memória-sávszélesség felé. Az AMD ennek pont az ellentéte. Nem igényel nagy blending teljesítményt, de nagyon igényli a memória-sávszélességet. Tehát már az eltérő architektúrák miatt is lényegtelen a direkt ROP és sávszél összehasonlítása, mert az NV-nek sok ROP kell, de kevés sávszél, míg az AMD-nek kevés ROP, de sok sávszél. Persze ezt relatív összehasonlításban kell érteni. A TFLOPS pedig azért erősen elméleti, mert a DX12 alatt is D3BC-n keresztül működnek a rendszerek, amely IR-t a 2000-es évek elején befutott architektúrákra húztak fel. Ma már egyáltalán nem úgy működnek a hardverek, hogy a D3BC jól mappelhető legyen rájuk. Ezért hoz a Microsoft a shader model 6.0-ban egy új IR-t, ami a DXIL. Microsofttól elszakadva ugyanezért hozott a Khronos is egy SPIR-V-t. Szóval az elméleti TFLOPS az tök jó, de nincs olyan PC-s hardver, ami nem SIMT modellt használna és ezáltal ne függene a teljesítmény a regiszterhasználattól, hiszen minél erősebb terhelés éri a regisztereket, annál kevesebb wavefront-warp/akármiwave futhat párhuzamosan, és annál rosszabb lesz a rendszer kihasználása. Ugye erre reakció részben a GCN4 utasítás-előbetöltése. A DXIL-en és a shader model 6.0-n már lehet látni, hogy a SIMT modell felé lépdel, hiszen mindegyik hardver ilyen már. Ettől nőni fog a hardver kihasználhatósága is, mindegyik hardveré.
A DirectX 12 több szintre bontja a bekötési rendszer. Van a TIER_3, aminél az erőforrás direkten a multiprocesszorba kerül bekötésre. Ez az alapvető modell, és ennek vannak butított szintjei. A TIER_2 szint a mintavételezőbe engedi bekötni az erőforrást, és driverrutinra van szükség ahhoz, hogy az onnan átkerüljön a multiprocesszorra. Na most ez a driverrutin processzoridőt igényel. A TIER_1 szint esetében maga a bekötés úgy zajlik, hogy a host processzor végzi a teljes munkafolyamatot, és köti be az erőforrást a multiprocesszorba.
Abból egyébként nincs semmi gond, hogy minden cég hardvere ideálisan működik a maga módján, és ha nem lenne az API, akkor ezek abszolút tökéletesek lennének, de az API létezik, és ebben vannak bizonyos szabályok, amelyeket követni kell az adott implementációnak. Szóval az NV-nek azért van szüksége arra a processzoridőt használó driverrutinra, mert abban a fránya DX12 API-ban megkövetelte a Microsoft, ugyanis a pure bindless modellre építették fel a bekötést, és a rosszabb modelleket ehhez igazították hozzá, ami áldozatokkal járt, hogy ez a három szint egyáltalán kompatibilis legyen egymással. Ez teljes mértékben egy szoftveres döntés volt, gondolva arra, hogy a DX12 itt lesz 2020-ban is, amikor már minden hardver pure bindless lesz. De egyébként dönthettek volna úgy is, hogy a DX12 bekötési modelljét arra húzzák fel, hogy elég a mintavételezőbe bekötni az erőforrást, és akkor az az NV-nek lett volna jó, de a jövő szempontjából nem ez tűnt a legjobb döntésnek.Persze, hogy nincsenek kötelező szabályok. Az MS csak azért ajánlja, amit ajánl, mert így működik az API gyorsan. Lásd Rise of the Tomb Raider, ahol nem követték az MS ajánlásait. Azóta mindenki ezeket követi, mert látványosan nem működik akkor a DX12, ha kifejezetten nem ajánlott RS modellt követnek a fejlesztők. Függetlenül attól, hogy az NV ajánlja ezt vagy nem.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Telekom mobilszolgáltatások
- Kínai, és egyéb olcsó órák topikja
- Formabontó vezetékmentes klaviatúrák jöttek a Keychron műhelyéből
- Luck Dragon: MárkaLánc
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Villanyszerelés
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Hardcore café
- sziku69: Fűzzük össze a szavakat :)
- További aktív témák...
- Xiaomi Redmi 10 64GB, Kártyafüggetlen, 1 Év Garanciával
- Xiaomi Redmi Note 10S 128GB, Kártyafüggetlen, 1 Év Garanciával
- Lian Li Lancool III ARGB fekete új garanciával
- Dobozos új Asus ROG Zephyrus M14/RYZEN 7-6800HS/16GB Ram/1 TB SSD/AMD RADEON RX 6700S 8GB/WQXGA/GARI
- Arozzi Vernazza Soft Fabric Gamer Szék - Világos Szürke