- HiFi műszaki szemmel - sztereó hangrendszerek
- Nvidia GPU-k jövője - amit tudni vélünk
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Dell notebook topic
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Steam Deck
- Azonnali informatikai kérdések órája
- Milyen monitort vegyek?
- Autóhifi
Hirdetés
-
Mindent megtudtunk az új Nokia 3210-ről
ma Részletes képek, specifikációk és euróban megadott ár is van a legendás modell újraélesztett verziójához.
-
Senua's Saga: Hellblade II - Íme a végleges gépigény
gp A folytatás megjelenéséig kicsivel több mint két hetet kell már csak várnunk.
-
Spyra: akkus, nagynyomású, 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! :)
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Microsoftnak van mérése erről. A TIR funkcióval 151-523%-kal gyorsabb feldolgozás lehetséges.
Az UAV-k esetében bonyolultabb a helyzet. Alapvetően pufferről van szó, ami lehetővé teszi, hogy a GPU adatot olvasson vagy írjon akárhova (itt inkább az írás a kulcs, mert az olvasás az SRV-n keresztül eddig is meg volt). Korábban ez előre definiált volt. Gyakorlatilag a programozónak biztosít egy komolyabb flexibilitást. Ha úgy vesszük, akkor scatter/gather operációkról van szó. Az egész a DX11-ben mutatkozott be és a pixel/compute shaderhez volt használható. A pixel shader lépcsőn való támogatás azt is lehetővé tette, hogy a programon belül az adatok könnyen megoszthatók legyenek a compute és a render futószalag között. Ezzel számos effekt sokkal hatékonyabban volt leprogramozható. A DX11.1 gyakorlatilag ezt annyival egészíti ki, hogy az UAV elérhető az összes programozható lépcsőn.
Hogy példát is mondjak. A vertex shader esetében hasznos funkció lehet, ha LOD információkat akarsz nyerni a következő képkockára. UAV-t bevetve megoldható, hogy az előző képkockáról származó információk alapján határozd meg az új képkockán a mesh LOD szintjét. Gyakorlatilag az előző képkocka kimentett információiról azonnali LOD szintet lehet beállítani bármire. A hull shader esetében sok hasznos dolgot nem tudok elképzelni, és hasonló a helyzet a domain shader esetében. A geometry shader érdekesebb. Itt lehet talán a legtöbbet ezzel nyerni. Az UAV-vel például eléggé olcsón megoldható az alliassing jelenségtől mentes shadow mapping. Utóbbira számtalan megoldás született már, de eddig egyiket sem vetették be, mert a sebesség az nagyon gyenge. A DX11.1 gyakorlatilag értékelhető sebesség mellett teszi lehetővé az alkalmazását. Itt tényleg sokszoros sebességkülönbségről lehet szó.
Az UAV-k kezelésének kiterjesztése még arra is jó, hogy bonyolultabb grafikai megoldásokban gondolkodj, több helyen vesd be a compute shadert, amivel a teljes feldolgozás felgyorsítható.(#53) tome.jr: A DX11-ben is félreértik az emberek az extra sebességet. Tényleg jó példa a DiRT Showdown. Ha DX9-ben írnád meg ugyanazt a grafikai minőséget, amit felmutat a program DX11-ben, akkor nem lenne VGA, amin 2-5 fps-nél gyorsabban futna. Az olcsóbb vagy régebbi VGA-k egy másodpercen belül nem számolnának egyetlen képkockát sem. Természetesen meg lehet kérni a fejlesztőket, hogy ugyan oldják már meg azokat a DX11-ben elérhető effekteket DX9-ben is. Nincs technikai akadálya, de tényleg óriási kérdés, hogy megéri? Dolgoznál vele hónapokat azért, hogy egyetlen VGA-n se fusson pár fps-nél többel. Ha te fejlesztő lennél megcsinálnád?
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Az AC3-ban rengeteg olyan dolog van, ami compute shaderrel gyorsítható mindegyik terméken. Ehhez képest nem is tartalmaz CS kódot. Ez teljesen érthetetlen, és a sebességre is nagyon rányomja a bélyeget, mert a grafika az nem annyira komplex. Alapvetően nincs rosszul optimalizálva, csak valamiért nagyon ragaszkodtak a régi dogmákhoz. De amúgy ezzel nincs gond. Ők így döntöttek. Amit ebből ki lehet hozni, azt kihozták.
[ 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 Flashback #90 üzenetére
Nem teljesen értem a kérdést. Illetve azt, hogy mi megy más irányba. Arra gondolsz, hogy az új DX11-es játékok közül már számos program erősebb compute terhelést fejt ki? Mert, ha igen, akkor ez igazából normális. Amikor egy effektet compute shaderben írnak, akkor a fejlesztő nem azt nézi, hogy a Radeonok el fognak húzni a GeForce-októl, hanem azt, hogy a compute shader kód a GeForce-on is gyorsít. Az lehet, hogy az NVIDIA-nak ez kellemetlen a benchmarkokban, amikor a hardvereket összehasonlítják, de neked, mint felhasználó, még GeForce mellett is az az érdeked, hogy amit lehet írjanak meg compute shaderben, mert egyszerűen gyorsabb, mintha nem használnák. Aztán a gyorsulás mértéke már függ az architektúrától, illetve attól, hogy milyen bonyolult az effekt, de a program sebessége szempontjából a compute shaderrel mindenképpen jól jársz. Ne úgy fogd fel, hogy a fejlesztők most ki akarnak cseszni az NV-vel és erős compute terhelést csinálnak, ami általánosan kedvez a GCN architektúrának. A fő cél itt az, hogy a program gyorsabban fusson mindenkinél. Az NV persze lobbizhat, hogy erre nincs szükség, de akkor a saját felhasználóitól is elveszi azt az extra sebességet, amit a compute shader jelent. Persze nekik ez valahol megéri, mert a GCN ebből az irányból sokkal többet nyer, mint a Kepler.
Ha a DX11.1-re gondolsz, akkor azt tudom írni, amit a hírben. Számítanak azok a funkciók, amiket a Kepler nem támogat, nem mondhatjuk azt, hogy jelentéktelenek, mert nem azok. Abban viszont nem vagyok biztos, hogy mikor lesznek kihasználva egy játékban. Ha csak a fejlesztőkön múlna, akkor nagyon kis esélyt adnék rá, hogy fél éven belül lesz DX11.1-es játék. Viszont az AMD manapság talicskával tolja a pénzt a játékfejlesztésekbe, és így a Gaming Evolved partnerprogramon belül már kérhetnek olyat, illetve fejleszthetnek olyan irányba, amilyet a normál fejlődés mellett a fejlesztők amúgy nem használnának ki (idén ezt már több játéknál megtették). Ez egy bizonytalansági faktor, amivel nagyon nehéz számolni.(#104) TTomax: Tudom milyen az AC3. Írtam is, hogy van problémája az erőforrás kihasználásával. Azért valamennyi mindig van a driverekben. Persze valószínű, hogy pár százaléknál nem több, de mindenképpen megéri beprofilozni a játékot. A patch az igazából mindig opció. Bármit lehet javítani, csak a kérdés, hogy megéri-e ezzel foglalkozni. Ha egy kiadó elzárja a pénzcsapot a további optimalizálás elől, akkor nyilván ez a fejlesztési irány lezárult. Az AC3 sebességet a leggyorsabban compute shaderrel lehetne nyerni, de ezt teljesen mellőzték a fejlesztők.
Szerintem a PC-s portokhoz rosszul állnak a kiadók. A fejlesztőnek tartani kell a dátumokat, és ennek jellemzően a PC-s optimalizálás issza meg a levét, mert annak van a legalacsonyabb priorítása. Ilyen szempontból most már én is belátom, hogy a Square Enix csinálja jól. Fenntartanak egy stúdiót csak a PC-s portokra, és eddig működik ez a koncepció. Amilyen rossz ötletnek tűnt pár éve annyira bevált, így talán másnak is meg kellene ezt az irányt fontolni.(#114) Jack@l: Miért lenne fura? Az előző képkocka alapján már tudod, hogy melyik meshez milyen LOD tartozik. Ha közelítesz, akkor azt tudni fogja a rendszer, csak nem az aktuális jelenetről, hanem az előző frame számításai alapján. Minden frame számítása során ki kell menteni egy struktúrát, ami alapján ez meghatározásra kerülhet egy compute shaderben. A megadott állandók alapján így is mindig meghatározható a LOD. A különbség annyi, hogy előre meghatározod.
A TIR százalékos adat a Microsoft hivatalos mérése. [link]
(#115) Jack@l: Remélem nem azt akarod mondani, hogy eddig azt hitted, hogy D3D-re vonatkozik. Benne van a hírben, hogy 2D-s grafika esetén. Legalább azt olvasd el, mert ha nem teszed, akkor feleslegesen magyarázom.
(#85) nbg: Az ATI(AMD)-nak volt egyszer egy nézeteltérése a Microsofttal a shader modell 3.0 esetén. A Radeon X1000 sorozat nem támogatta a Vertex Texture Fetch-et. Erre a Microsoft nem akarta megadni így a shader modell 3.0-s minősítést, de végül megadták, mert az ATI azt hozta fel, hogy ők az R2VB-t implementálták. A probléma az volt, hogy utólag a Microsoft is elismerte, hogy semmilyen formátumot nem írtak elő kötelezően a vertex textúrázás támogatására, így a dokumentáció szerint jó az R2VB és a VTF is. Ezért lett a Radeon X1000 sorozat shader modell 3.0-s végül. A Microsoft a DirectX 10 API esetében már pontosan specifikálták a vertex textúrázás formátumát.
[ 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
- HiFi műszaki szemmel - sztereó hangrendszerek
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Politika
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- ANNO 1800
- Nvidia GPU-k jövője - amit tudni vélünk
- Filmvilág
- GoodSpeed: Windows 11 PRO FPP (Full Packaged Product) - Retail, Box, dobozos
- Netfone
- További aktív témák...
- BESZÁMÍTÁS! GIGABYTE WindForce 2X GTX 960 4GB GDDR5 videokártya garanciával hibátlan működéssel
- PCX Garancia! MSI RTX 3080 Ti 12GB GDDR6X Gaming X TRIO Videokártya! BeszámítOK
- Eladó ASUS GeForce GTX 1660 Super 6GB Phoenix videokártya (PH-GTX1660S-6G)
- Újszerű - POWERCOLOR Radeon RX 5500 XT 8GB GDDR6 VGA videókártya
- ELADÓ 32 DB Nvidia RTX 3060 Ti és 8 DB Zotac Gaming Geforce RTX 3080 Trinity / KOMPLETT BÁNYAGÉP
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest