- HiFi műszaki szemmel - sztereó hangrendszerek
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- AMD vs. INTEL vs. NVIDIA
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- 3D nyomtatás
- Akciókamerák
- Milyen TV-t vegyek?
- Milyen monitort vegyek?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen videókártyát?
Hirdetés
-
Minden információt felhasználnak rólunk a közösségi cégek
it Az amerikai hatóságok szerint a közösségi média felhasználói nem igazán rendelkeznek irányítással azon adatok fölött, amit az AI-rendszerekkel megetetnek a nagy cégek.
-
E61 blog 2. rész
lo [Előző rész]Folytatnám a történetét a E61-nek. A sztereotípiákkal ellentétben még nem kerültem anyagi csődbe, és nem...
-
Végre a Logitech is bemutatott egy analóg klaviatúrát
ph A dolog már eléggé időszerű volt, mindenesetre a három színben készülő, TKL-es megoldás nem dúskál a hobbistáktól ellesett okosságokban.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Mindenhova ez megy x-y darab letiltott CU-val. Akkor lenne értelme két lapkát csinálni, ha nem tudnának 13-14 TFLOPS-ot rakni ~400 mm2-es lapkába. De mivel tudnak, így felesleges mellé még egy ~300 mm2-es lapkát tervezni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
GDC/SIGGRAPH papírok. Az a megkülönböztetés célja, hogy a GAB-hoz kapcsolódó kutatásoknál ki legyen emelve, hogy a kutatás mire lett elvégezve, mert nem biztos, hogy a kutatásban szereplő prototípus implementáció lefut minden D3D12-es hardveren, hiszen lehet, hogy egyes hardverek kifutnak a slotlimitből. Ha ki van emelve a cGPU a kutatásnál, akkor a prototípus implementáció biztosan több erőforrást tölt be, mint amit a minimum D3D12 specifikáció megkövetel, tehát figyeljen rá a fejlesztő, hogy ez a kód nem fut ám minden D3D12 hardveren.
A GAB leírásában egyébként cGPU minden GCN-es GPU és minden Intel Gen9 vagy újabb IGP. Ezeken nincs slotlimit, mert memóriaalapú architektúrák.Szerk.: Privi ment.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az egy dolog, hogy mindjárt október, de ez nem jelent semmit. Feldolgozzák a beérkező adatokat megírják róla a jelentést, és kb. december legjobb esetben, amikor kapsz valamit a Q3-ról. Aztán van még némi NDA és valamikor januárban publikálja a JPR a Q3-as adatokat. Nem olyan ám ez, hogy október és máris jön az összesítés, itt komoly statisztikáról van szó.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Oliverda #122 üzenetére
Nem lesz légyfing, de nem lesz GCN4 szintű előrelépés. Egyszerűen csak új utasítások jönnek, és megy is pár, illetve új lesz a memóriamodell. De ez közel sem akkora előrelépés, mint mondjuk egy utasítás-előbetöltés. A GCN4->GCN5 olyasmi előrelépés lesz, mint a GCN2->GCN3. A nagyobb lépcsőnek a GCN1->GCN2 számított (flat memóriamodell), és a GCN3->GCN4 volt a legnagyobb (utasítás-előbetöltés).
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A node kiismerése mindig hoz 10-20%-ot, ez igen jellemző. Másrészt nyilván a fizikai implementációt lehet magas órajelre tervezni, de ennek sok extra tranzisztor az ára. De ez már az eszközszint, ami nyilván az architektúra része, de itt most az ISA-ról és a funkcionális fejlesztésekről beszéltünk. A fizikai implementációnál az a kérdés, hogy hol van az az ideális balansz, ami jó órajeleket, illetve jó tranyószámot és lapkaméretet hoz.
Azt is figyelembe kell venni, hogy az AMD-nek a feszültségskálázása rendkívül stabil. Egyszerűen képesek arra, hogy egy igen magas PowerTune órajelen működtessék a GPU-t, és a hardver magát a környezetet figyelembe véve visszaskálázza egy olyan szintre, ami stabil marad. Lásd például mobil RX 480-at, ami ugyanazt az órajelet kapta, mint az asztali verzió. Nem kell hetekig tesztelgetniük a kiadás előtt, hogy mi a stabil maximum, mert a hardver beállítja magának, csak meg kell adni egy nagyon magas órajelet, amin még nem fagy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Volt gyors ugrás ott is. Emlékezhetsz a GHz Edition termékekre. Persze bele kell számolni, hogy a 28 nm-es node-on eléggé kezdetleges DVFS-t használtak az első GPU-knál. Emiatt azért az órajelek tekintetében is eléggé biztonságosan kellett eljárni, legalább akkora tesztelést igényelt, mint korábban.
Ma már nyolclépcsős rendszert használnak AVFS-sel kiegészítve, így a PowerTune órajel kiválasztásánál csak azt kell nézniük, hogy mi az a maximum órajel, ami alatt a hardver a legrosszabb körülmények között stabil. Ezt beállítják és a hardver innentől minden körülményhez beállítja magának a lehető legnagyobb órajelet. Innentől kezdve csak az a fontos, hogy a maximális órajel elég magas legyen.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Ren Hoek #131 üzenetére
A throttling egy nagyon fontos dolog a GPU-knál. Iszonyatosan sok pénz megy bele, hogy a throttling folyamatos legyen, mert az jelzi, hogy az alkalmazott feszültségskálázás valóban skálázás, és a hardver minden pillanatban a lehető legnagyobb órajelet állítja be magának.
A Hawaii az túl régi, abban nincs natív FP16, nincs DPP és SDWA, nincs permutáció, illetve nincs utasítás-előbetöltés. Az utóbbi a legfontosabb egy új lapkánál, mert a tavasszal érkező DirectX verzió legfontosabb fejlesztése a wave ordering lesz, ami utasítás-előbetöltés nélkül félkarú óriás. Ezekre a mostani lapkák élettartamában szükség lesz. Az új Frostbite már használ wave ordering optimalizálást, csak arra vár a DICE, hogy legyen AGS4 kiterjesztés rá.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez a teljesítmény egyenletességén egyáltalán nem ront, sőt javít. A sebességen meg plane javít úgy 10-15%-ot. Ha inaktiválnák, akkor a mostani sebességből lejönne ez a 10-15%. Részben az AVFS az oka, hogy a Polaris erős minimum fps-ben. Ha kevesebb ALU fogható be, akkor felnyomja az órajelet, így kevésbé nő a frame kiszámításának ideje.
Ez nem fontos fícsőr lesz, ez ma fontos fícsőr. Nagyobb sebességet és egyenletesebb képmegjelenítést biztosít az órajel állandó maximumhoz állítása.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Ren Hoek #147 üzenetére
Fijiben ebből nincs utasítás-előbetöltés és natív FP16.
Pascalban nincs utasítás-előbetöltés, DPP és SDWA, illetve FP16 van, de le van korlátozva a driverből, tehát effektíve nincs. Ami mondjuk szerintem egy elég nagy hiba, mert ott van a hardverben, és sokat tud gyorsítani a játékokban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Elsődlegesen a grafika miatt hozta be a Microsoft az FP16-ot, mert ilyen formában a fejlesztők bizonyos shadereket felezett pontosságra is írhatnak. Nem mindig szükséges a szimpla pontosság, mert az ezzel nyerhető minőségelőny minimális, így inkább a sebességet érdekes választani. A DirectX 12 ebből a szempontból automatikusan elvégzi a oda-vissza konverziót, ha az adott precizitást nem támogatja a hardver. Elég a célzott precizitásra dolgozni, és a többiről gondoskodik az API, úgy hogy a végső képminőség ugyanaz legyen minden hardveren.
Ilyen shadereket használ már a Hitman és az új Deus Ex.Mindegy, hogy a hardver mit tud, ha a driver ezt jelzi vissza az API-nak:
D3D12_SHADER_MIN_PRECISION_SUPPORT_NONEEz kell az FP16<->FP32 konverzió elkerüléséhez:
D3D12_SHADER_MIN_PRECISION_SUPPORT_16_BIT[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egy fejlesztő azt nézi, hogy megéri-e a többlet. Mert többlet lesz belőle. Az, hogy mennyi ez a töblet annyira nem lényeges, minden extra számít. Pont ezért van úgy felépítve a DX12, hogy igazából a legtöbb problémára elég legyen egy megoldás, és az API automatikusan elvégzi a konverziókat, hogy támogathatók legyenek a megoldást nem támogató hardverek. Ez végtelenül leegyszerűsíti a fejlesztők döntését. Ha mondjuk kellene két kódút a pontosságra, akkor szarnák ők is le az FP16-ot, de így elég erre írni és az API megoldja a kompatibilitást.
(#155) Ren Hoek: Nyilván a Pascal Refresh sorozatba be lehet kapcsolni, és el is lehet adni, mint új fícsőr, amit azonnal tud használni pár játék.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont arról írtam, hogy nincs többletmunka. Az API úgy van felépítve, hogy csak egy kódút legyen, méghozzá az a kódút, amit céloz a fejlesztő. Ha mondjuk FP16-os precizitást céloz, akkor nem számít, hogy a hardver nem támogatja-e. Az API automatikusan elvégzi az oda-vissza konverziót, és minden hardver ugyanazt az eredményt adja. Az egyetlen különbség a sebesség lesz.
(#162) Henkei: Nincs sok időm rá a munka mellett, csak hobbi szinten csinálom.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez természetes, hogy jobban gyorsul. A Hawaii sokkal érzékenyebb a single-engine limitációkra, mint a Polaris. Jóval kevesebb slotja van a parancsmotorjának. A Polaris 128 slotos, míg a Hawaii csak 32. Emiatt DX11-ben a Hawaii kevésbé etethető, míg a Polaris számára ez négyszer nagyobb input fogatásának lehetőségével nem akkora probléma. DX12-ben, multi-engine kóddal már mindkét hardver jól etethető. A Polaris kap egy kis extrát még az FP16 miatt is.
Egyébként az FP16-ot nem az AMD erőlteti a fejlesztőkre. Itt pár shaderről van szó, ami nem feltétlenül hoz végeredményben 2-3%-nál nagyobb extrát. Az Intelnek sokkal jobban számít, és elsődlegesen ők azok, akik erre vonatkozóan győzködik a fejlesztőket.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Ren Hoek #166 üzenetére
A senkit az túlzás. Az Intelt nagyon, illetve az AMD sem ellenkezi, ahogy egyébként az NV sem, mert ettől nekik hátrányuk nem lesz, hiszen az API úgyis elvégzi a konverziót. A fejlesztők elsődlegesen az Intel igényeit szolgálják ki ezzel, mert az AMD és az NV nem fogalmazza meg az FP16-ot kritikus fontosságú eljárásként, míg az Intelnél eléggé az. Erre van elég sok leírásuk, hogy hol éri meg alkalmazni és miképpen. Ezeket követi a Hitman és a Deus Ex MK.
Az Intel elsődlegesen azért ennyire FP16 "imádó" cég, mert a Broadwell óta a teljes termékskálájuk képes előnyt szerezni belőle, míg az AMD-nél ez csak a GCN3 óta igaz. Itt sem akkor az előny, mint az Intelnél, mert csak natív a támogatás, nem pedig kétszeres sebességű.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Ren Hoek #170 üzenetére
Nézd a program szintjén ez csak pár sor. A fejlesztők eleve tisztában vannak vele, hogy hol érdemes ezt alkalmazni, tehát azt a pár sort megéri beírni, és máris működik minden hardverre. Még csak a tesztelést sem nehezíti meg, mert az API gondoskodik a működésről. A későbbiekben pedig egyre több hardver támogatja majd ezt nem csak natívan, hanem kétszeres sebességgel is, vagyis a már megírt kódokban jön a gyorsulás.
Az egész igazából főleg döntés kérdése, hogy rááldozzák-e azt a 10 percet a több éves fejlesztési időből, hogy definiálják a minimum precizitást az egyes shadereknél. Még egyszer írom, hátrány senkit sem ér, csak előnyös lehet az implementáció.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
Hirdetés
- Apple iPhone 13 - hízott, de jól áll neki!
- Ford topik
- Formula-1
- Budapest és környéke adok-veszek-beszélgetek
- Futás, futópályák
- Kertészet, mezőgazdaság topik
- Router gondok
- HiFi műszaki szemmel - sztereó hangrendszerek
- A fociról könnyedén, egy baráti társaságban
- Fűzzük össze a szavakat :)
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen