- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Androidos fejegységek
- Épített vízhűtés (nem kompakt) topic
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- MILC felhasználók szakmai topikja
- Mini-ITX
- Mérföldkőhöz ért az LG a Micro-OLED technológiában
- Az LG elengedi a feltekerhető tévéket
- Steam Deck
- Autóhifi
Hirdetés
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Nem gyárt több LCD tévépanelt a Sharp
ph A cég bezárja utolsó, Sakaiban található üzemét, amivel egy korszak ér véget.
-
Így fest a Steel Effigy korai béta változata
gp A külső nézetes hack&slash akciójáték az előzetes információk szerint PC-re érkezik.
-
PROHARDVER!
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz Petykemano #47748 üzenetére
Nem. Azért tűnnek furának, mert az utóbbi időben a GPU-kból eltűntek a co-issue és dual-issue feldolgozók, de régen igen sűrűn voltak ilyenek bevetve. Talán emlékszek még az R600-ra, ami szám szerint 320 FP32-t használt, de úgy, hogy 1+1+1+1+1 co-issue módban üzemeltek a multiprocesszorok (és ez igaz volt egészen a GCN-ig, bár az utolsó dizájnok már 1+1+1+1 co-issue módra váltottak vissza). Ezzel szemben ment az NV-nek a G80-ja 128 FP32-vel, de mindenféle co-issue nélkül. De itt az Intel is, ami 4+4 co-issue multiprocesszort használ. Az utóbbi időben ezek a trükkök kikoptak a GPU-kból, mert a komplex kódokban nagyon nehézzé vált a co-issue mód kihasználása, de hardveres szinten ezek azért megfontolandók, mert a tranzisztorköltsége nem nagy a nyers ALU-knak. Ami igazán viszi a tranyót az az ütemezés, az adatbusz, a regiszterek, stb. És pont ezt kerülik meg ezek a co-issue módok, amik valami speckó helyzetet kihasználva hozzácsapnak némi extra kapacitást a rendszerhez. Ezzel kvázi dupla ALU-t kapsz anélkül, hogy jelentős tranzisztorköltsége lenne, cserébe nem olyan a multiprocesszor utilizációja, hogy azt a dupla ALU-t olyan hatékonyan lehessen felhasználni, mintha erre ráterveznéd az ütemezést, a regisztereket, az adatbuszt, stb. Ezért sem tudja az RTX 3080 a nyers paraméterek alapján nagyjából háromszoros előnyét háromszoros fps-re váltani a 2080-hoz képest. Ebből az NV szerint kétszerest abszolvál a gyakorlatban, bár mondjuk nyilván minden szentnem maga felé hajlik a keze, de most tegyük fel, hogy hoz ennyit. Tehát az FP32 utilizáció lényegesen rosszabb lett, de arányaiban azt kell nézni, hogy a befektetett tranzisztorköltséghez képest mit javult.
Az efféle módokról egyébként az teljesítményingadozás miatt álltak le a gyártók, mert az R600-ra például jellemző volt, hogy valahol nagyon alázott, valahol pedig nagyon szar volt, és ez attól függőt, hogy egy adott alkalmazásban mennyire lehetett kihasználni a specifikus működési módokat. Ha például egyáltalán nem lehetett, akkor az R600 320 ALU-jából használható maradt 80 (az NV például külön ezzel szopatta az AMD-t, hogy teleírta a fejlesztőknek leadott kódjait függőséggel). Tehát a teljesítménye jó részét elvesztette. Valószínű, hogy az egész co-issue-féle trükközés a sugárkövetés miatt tért vissza, mert oda eleve kell int32, és azokat az ALU-kan nem volt nagy meló megtoldani FP32-vel, még csak komoly tranzisztorköltség sem.
Manapság egyébként a gyártók pont azért nem tudják jelentősen megszopatni egymást a fejlesztőknél, mert nem alkalmaznak semmilyen co-issue trükközést, de régen keményen szívatták egymást, hogy direkt limitre rakták az adott dizájn működését, és úgy elvették tőle a benne lévő teljesítmény jó részét. De ennek már majd 10-15 éve, azóta szerintem jó útra tértek, és biztos nem fogunk majd ilyen szopatást látni az AMD-től és az Inteltől.
(#47755) b. : Szerintem félreérted, én régen nagy híve voltam ezeknek a megoldásoknak. Az R600-at pont emiatt tetszett nagyon, mert egy rakás ALU kapacitást raktak bele ilyen trükkökkel. Nyilván ezek a megoldások kikoptak, de újszerű GPU-kat kell tervezni az új igényeknek, és ha belegondolok, hogy int32 kell a sugárkövetésnek, akkor nagyon is jó ötlet azt kiegészíteni FP32-re is. Tranzisztorköltségben nagyon kicsi lábnyoma van, és ha a kódok 20%-a képes kihasználni, akkor már megérte. Emiatt írtam, hogy nem azt kell nézni, hogy maga az utilizáció kifejezetten alacsony lesz (ez jellegzetessége a trükkös dizájnoknak), hanem azt, hogy a trükközés nélküli állapothoz képest mennyi tranyót emésztett fel az extra teljesítmény kinyerése. Ilyen szempontból az R600-hoz hasonlóan bizonyosan előnye van az Ampere-nek is. Örülök is neki, hogy az NV ezeket a trükközési formákat hozza vissza.
Az utolsó mondat egy poén, ezért van mögötte fejecske.
[ 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!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen