- Samsung Galaxy S25 - végre van kicsi!
- Honor 200 Pro - mobilportré
- Samsung Galaxy A55 - új év, régi stratégia
- iPhone 16e - ellenvetésem lenne
- Google Pixel topik
- Xiaomi 15 - kicsi telefon nagy energiával
- iPhone topik
- One mobilszolgáltatások
- Telekom mobilszolgáltatások
- Bemutatkozott a Poco X7 és X7 Pro
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
dergander
#443
üzenetére
Nem szükséges. A HSA fut NV-n és Intelen is. Nem szükséges a direkt támogatás. Olyan ez mint a Java. Eléggé a user módból valósul meg az egész. Írsz rá programot és automatikusan a legjobb elérhető teljesítménnyel használja az adott gépet. Leginkább ez tolja a piacot a HSA felé, mert így nem kell dönteni, hogy kinek a hardverén fusson. Meg eleve az alapítvány nyílt. Ennél nyíltabb kezdeményezés erre a problémára sosem lesz. Ha valahova beállna az NV és az Intel az a HSA, mert nem éri őket hátrány. Mondjuk előny sem, de legalább ugyanazokat a jogokat kapják mint a többiek.
-
Abu85
HÁZIGAZDA
A modulos megközelítés inkább marad az aktuális adatok szerint. Egy ilyen koncepcióval megspórolod a beépítendő FPU-k felét, és ez csak a legújabb ISA-t éri negatívan, míg a többit egyszerűen nem. Az meg világos, hogy a fejlesztők túl bonyolultnak tartják az AVX-et complier intrinsics mellett, míg az autóvektorizálásban messze a C++AMP a leghatékonyabb. A kettő közötti lehetőség az OpenCL, de azt még az Intel nyomására is kerülik a fejlesztők. Nincs értelme egy olyan ISA-ra hardvert építeni, aminek nincs meg a kellő mértékű támogatása.
Persze a fejlesztők előre gondolkodnak, és láthatják, hogy a beleölt munkához képest a legjobb AVX kihasználást HSA-val fogják kapni. És ezért nem kell igazából tenniük semmit, mert elintézi a munka nehéz részét a runtime. -
Abu85
HÁZIGAZDA
Egészen pontosan az úgy szólt, hogy a Mantle a fejlesztők kezében lehet ostor, amivel csapkodhatják az MS-t. Ez tök egyértelmű irányzat. A Mantlebe mindig minden bekerül legalább egy évvel hamarabb. Már a szabványosítási procedúra szükségtelensége miatt is. Az MS pedig az új funkciók implementálására ezzel rá lesz kényszerítve.
-
Abu85
HÁZIGAZDA
Ahogy írtam a soktízezer batch. A DX hivatalos tűréshatára 2k/frame, ennél többet az MS nem ajánl. A Nitrous feldolgozási koncepciója viszont annyira jól működik, hogy még 20-30k/frame mellett is tartja a 30 fps-t, de a program csinál 180k/frame-et is, amihez már nem elég a végletekig optimalizált motor, ez a szint 90x nagyobb terhelés, mint amire a DX-et felkészítették.
Az is szép egyébként, hogy a Nitrous kvázi tízszer többet kihoz a DX-ből, mint amire az MS elvben képesnek tartotta az API-ját. Nyilván kell hozzá egy olyan zseni, mint Dan Baker, de ő sem képes a csodákra. -
Abu85
HÁZIGAZDA
Ha már leárnyalsz egy objektumot, akkor az onnantól kezdve minimális erőforrásból rajzolható ki. Szinte semmiből. A DX11 ott hal meg, hogy nincs meg benne a megfelelő koncepció a soktízezer batch kezelésére. A kirajzolás ennek az API-nak is semmi, mert már le van árnyalva az objektum, azaz a munka oroszlánrészével már végzett. Ha nem így működni a Nitrous, akkor DX11-ben másodpercekig számolna egy frame-et, míg Mantle-ben is alig lenne 3-4 fps-ed. Eleve nem véletlenül működik így a Renderman sem. Egyszerűen ez az ideális, ha keveset akarsz számolni. Nem mindegy, hogy egy szobányi szerverparkot építesz, vagy egy teljes lakótelepnyit.
-
Abu85
HÁZIGAZDA
Ezt nem kell lemérni, átvették a filmekben alkalmazott motion blur effektet. Azért tették ezt meg, mert a low-level API működése lehetővé teszi ezt a koncepciót. Ez nekik olcsóbb, mivel Nitrous úgy működik, mint a Renderman. Ha egyszer leárnyalsz valamit, akkor azt onnantól akárhányszor kirajzolhatod a processzor terhelése nélkül. Ezért használják ezt a megoldást, mert jelentős erőforrást vesz le a processzorról azzal, hogy nem kell egy rakás extra számítással.
Az új generációs API-knál (Mantle, modern OpenGL és DirectX) ez a módszer sokkal gyorsabb. Főleg a lövedékek miatt, mert azok nem részecskeeffektet, hanem fizikailag modellezett elemei a játéknak. Mindegyik lövedéket elég egyszer árnyalni, és onnantól mind a több ezer eredmény kirakható kvázi ingyen. -
Abu85
HÁZIGAZDA
Nem. Az egy direkt példaprogram arra, hogy a Nitrous motorra készülő játékok hogyan futnak majd a hardvereken. De ez a koncepció a next-gen. John McDonald az NV-től az OGL előadáson külön kiemelte, hogy a mostani terhelés érdektelen, minden játékból a 40-60k-s draw call szintet akarjuk megütni, mert ennyit tudnak a konzolok. A jelenlegi 2k-s draw call szintre elég akármelyik API, de nem akarunk ezen a szinten maradni.
-
Abu85
HÁZIGAZDA
Azért ez attól is függ, hogy áthozzák-e az effekteket. Ha igen, akkor nyilván a GCN-re optimalizált HLSL programokban semmi esélye a többieknek. Ha viszont nem, akkor a GameWorks egy adott effektje építhető be a konzol effektek helyére. Ezért nem is az API számít, hanem az, hogy egy játék konzolrok hozza az effektet PC-re, vagy az NV GameWorks csomagjából választja ki az alternatívákat.
Érdemes elolvasni Humus előadását, hogy mennyire sokat lehet optimalizálni HLSL-ből egy architektúrára. [link]
-
Abu85
HÁZIGAZDA
Ha az OGL példaprogramokra gondolsz, akkor azok eléggé specifikusak. Egy direkt problémát vizsgálnak, amire van gyorsulás. Természetesen ez egy modern játékkörnyezetbe építve nem hoz ekkora gyorsulást, mert ott van más számítás is, de az API terhelésétől függően 1,5-2x-es előrelépést simán hozhat a tényleges végeredményben. Legalábbis az NVIDIA ezt kalkulálja egy StarSwarm szintű next-gen játékjelenetre.
-
Abu85
HÁZIGAZDA
Igazából nem. A batch jellemzésének van értelme, mert eleve batch-el a DX-ben a programozó. A batch pedig lényegében a GPU felé küldött független parancs. Ez lehet geometria, de akár effekt vagy compute dolog is. Esetleg részecskerendszer eleme. Viszont a batch nem feltétlenül jelent egyetlen geometriai részt. Jelentheti akár ezer ugyanolyan elemet, mert az instancing ezt megoldja. A gond itt az, hogy a kötegelés nagyon munkaigényes.
Nem az egy szál a legnagyobb probléma, hanem a rengeteg ellenőrzési réteg, ami miatt az egy szál is lassú. A modern OpenGL nem multi thread, de mégis mutatták a GDC-n a példákat, hogy 30-150x gyorsabb a feldolgozása a DX11-nél. -
Abu85
HÁZIGAZDA
A DX12-ről már sokszor leírtuk, hogy régebb óta létezett. Nem a Mantle indította be a projektet. Lehet, hogy sokat segített az MS-nek, hogy az AMD odaadta nekik még 2013 elején a Mantle early specifikációit, ezzel mutatva egy irányt, de attól még maga a projekt régi és nem a Mantle-re egy reakció.
A DX12 azért lesz csak 2015 végén, mert egyrészt kell hozzá egy csomó alap az OS-ben is, amit részben vissza kell portolni a régi Windowsokba, egyeztetni kell kismillió kérdésben a gyártókkal, el kell készíteni a WHQL tesztsort rá, kellenek a drivereket, a fejlesztőeszközök, stb. Szabvány szinten fejlesztett API-k jellemzően másfél éves lemaradásban vannak, mert a szabványosítási procedúra elvisz ennyit.
-
Abu85
HÁZIGAZDA
Éppenséggel a Mantle ugyanúgy néz ki a BF4 alatt. Illetve csak elméletben, mert Mantle alatt megjelennek olyan árnyékok, amelyek DX alatt nem, de Repi már sokszor leírta, hogy a DX11 kódban van egy bug. Azért nem jelennek meg az árnyékok egyes helyeken. Azt is tudja, hogy mivel kapcsolatos a bug, csak nem tudja még, hogyan lehetne javítani sebességvesztés nélkül. Dolgozik rajta, egyszer kijavítja.
A low-level API biztos siker. Nincs más lehetőség ahhoz, hogy a konzollal tartsa a lépést a PC. Mindegy, hogy modern OGL, DX12, vagy Mantle, de valamit be kell vetni. A miérteket elmondja a világ egyik legjobb fejlesztője: [link] -
Abu85
HÁZIGAZDA
Azt is, csak a mai API-k nem adnak igazán jó QoS-t a program oldalán a driver monitorozására. Ez valahogy működik, de erről a program oldalán már semmilyen visszajelzés nincs. Ezért akar a világ változást, mert jelenleg optimalizálsz valamire, aminek a működése megjósolhatatlan. Frostbite Team és Nixxes szintű anyagi háttérrel ez nem akkora gond, mert az EA/SE odaad nekik több zsák pénzt és egy brutális szakmai gárdát alkalmazhatnak, hogy kutassák a DirectX+WDDM+driverek működését. Erre másfél-két év alatt fejlesztenek egy olyan rendert, ami világverő teljesítménnyel működik. Főleg gondolva itt a Frostbite 3-ra. Ehhez képest egy modern API-val ugyanerre egy ember képes 2-4 hónap alatt töredékpénzből.
-
#31
Abu85
HÁZIGAZDA
matteo_szg
#28
Abu85
HÁZIGAZDA
válasz
matteo_szg
#28
üzenetére
És természetesen az egyszeri gamernek a programfejlesztő a hibás, hogy nem tud PC-re optimalizálni. Ezt az üzenetet kellene átadni a gamereknek. A híresen rosszul optimalizáló csapatok közül nem az Ubisoft (főleg az ukrajnai stúdió), Activision, Bohemia Interactive, Gaijin Entertainment, stb a béna, hanem az API-k nem fejlődnek a hardverekkel. A fejlesztők elköltik az erre szánt büdzsét és jutnak ameddig jutnak.
-
#26
Abu85
HÁZIGAZDA
matteo_szg
#18
Abu85
HÁZIGAZDA
válasz
matteo_szg
#18
üzenetére
Ugyanúgy kifullad a StarSwarm alatt az új driver, ha a DX tűréshatárán túlmegy. Ezt Dan Baker írta. Lemérte, hogy ahol kellene javulás ott semmit sem javul. Ahol eddig is gyors volt, ott javult, de ezzel csak a sebesség nő a gondokat pedig görgetjük magunk előtt. Ez a probléma nem a driverből, hanem az API-ból ered.
Eleve az NV-nek az üzenete is sántít. Nem kell ide semmi, mert jó a DX11, de azért várjuk a DX12-t mint a messiást, illetve hirdetjük a modern OpenGL-t a problémákra, amelyek a marketingben már nem léteznek, mert a DX11 elég. Most melyik állítása igaz az NV-nek? Elég a DX11, vagy kell a DX12 és a modern OpenGL. A kettő kiüti egymást. Az a kérdés, hogy a marketinges csapatnak (DX11 elég), vagy a rendszerprogramozói csapatnak (kell a DX12 és a modern OpenGL) higgyünk. -
Abu85
HÁZIGAZDA
A programozónak semmi kontrollja nincs a driver rejtett szálai felett. Ez ma a legnagyobb gond. Annyit tud tenni, hogy a program oldalán bekalkulálja ezeket és a processzor valós erőforrásainak mondjuk csak a felét használja, így a másik felén jobban érezheti magát a driver. A Frostbite 2/3 azért viselkedik extrém módon Hyper-Threading mellett, mert A DICE az elmúlt években rengeteg kutatást végzett abban, hogy a sync pointokra optilamizáljanak, és ezeket lehetőleg elkerüljék. Ez működik is és ez a motor valóban képes használni a rendelkezésre álló összes szálat, de ez a koncepció Hyper-Threadinggel mikroakadásokat okoz. A Mantle annyiban különbözik, hogy a program által lefoglalt erőforrást nem fogja elvenni egy driver. Ez kiszámíthatóságot ad.
-
Abu85
HÁZIGAZDA
Nem a Mantle és a DX12 a lényeg, hanem a konzolok optimalizációja. Ebből a szempontból a DX12 még jobb is, mert megoldható, hogy copy-paste legyen az Xbox One kód a PC-re. A Mantle közelebb áll a PS4 API-jához, így azt onnan érdemes portolni, kivéve a PSSL-t, de az Xbox One HLSL-ek megint másolhatók.
Az NVIDIA számára azért kell a szabványos API, mert ahhoz tudnak írni GameWorks csomagot. Ez az egyetlen jövőkép, ahol mentes marad a PC a konzol optimalizációtól. Ehhez persze az is kell, hogy a konzol effekteket ne kapja meg a PC, de az NV-nek ez mindegy, mert megírják a fejlesztők helyett az eljárás feature_level_11_0 szinten is futó verzióját. Ezeket ráadásul nem is módosíthatja a játék programozója.
Új hozzászólás Aktív témák
Hirdetés
- btz: Internet fejlesztés országosan!
- Háztartási gépek
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Újra instabilitásba futott a Raptor Lake generáció
- Autós topik
- Méretes QD-OLED monitor jött az ASUS ROG-os portfóliójába
- 3D nyomtatás
- Reklámblokkolók topikja
- Samsung Galaxy S25 - végre van kicsi!
- Formula-1
- További aktív témák...
- BESZÁMÍTÁS! SAPPHIRE NITRO+ RX 7900 XTX 24GB GDDR6 videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800 XT 16GB GDDR6 videokártya garanciával hibátlan működéssel
- MSI RTX 3080 Ti SUPRIM X 12GB GDDR6X Videokártya! BeszámítOK
- Nvidia RTX 4070 Gainward ghost Video Kártya
- GIGABYTE AORUS RTX 4070 Ti ELITE 12GB - 20 hónap garancia
- Wacom Cintiq DTK-2260 - Digitális rajztábla
- Eredeti Windows 10 / 11 Pro aktiválókulcs AZONNALI SZÁLLÍTÁSSAL!
- BESZÁMÍTÁS! Asus B450 R7 2700X 16GB DDR4 512GB SSD RTX 2070 8GB Rampage SHIVA TT 500W
- Csere-Beszámítás! Asztali számítógép játékra! I5 14400F / RX 6900 XT 16GB / 32GB DDR5 / 1TB SSD
- Lenovo LEGION Pro 5 / Pro 7, Lenovo Yoga Pro gépek (RTX 4060 / 4070 / 4080 / 4090)
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest