- Samsung Galaxy A56 - megbízható középszerűség
- Magisk
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Tesztpadon az exynosos Galaxy Z Flip7 FE
- Xiaomi 15 - kicsi telefon nagy energiával
- Okosóra és okoskiegészítő topik
- Ulefone Amor 34 Pro - a nagy vetítőgép
- A Mate 70 Pro+ és Mate 70 RS a Huawei titánjai
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Szerintem a G-Sync vs. A-Sync vita felesleges. Idővel az NVIDIA-nak is le fog esni, hogy maguknak csinálnak azzal rosszat, ha elvágják a felhasználóikat a piac legjobb, illetve legolcsóbb kijelzőitől, valamint pontosan tudják, hogy az A-Sync hardveres kiépítésben többet tud. Képes támogatni a skálázást, az OSD funkciókat, illetve működik mobil termékekben is. A G-Sync ebből a három fontos dologból egyiket sem tudja. Szóval hosszabb távon nincs választása az NVIDIA-nak sem. Alapvetően már a Samsung is utalt rá, hogy az NVIDIA csak a 3D Visionnel felhalmozott elavult panelkészleteket segít kiszórni a partnereinek. Utána mehet az A-Sync, mert ezzel modernebb paneleket tudnak biztosítani a vásárlóiknak.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#110
üzenetére
Miért szerinted a DX11-ben a deferred context működik? A Microsoft saját maga mondta, hogy egy tévedés volt. Persze tévedni emberi dolog, semmi baj nincs ezzel, de nagyban hozzájárul ahhoz ez a tévedés, hogy ma kapálózunk az API-k után. Ettől függetlenül a DX11 más része működik, csak ma már van jobb alternatíva.
Miben befolyásolja a program funkcionalitását egy szimpla render backend? Ez csak kirajzolja azt, amit a program kér. Az új backendek kb. hétszer gyorsabban, miközben pontosan ugyanaz a kép jelenik majd meg mint a szabványos implementáción. Persze ha te a lassabbal érzed jól magad, akkor használd azt.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#106
üzenetére
Mivel mondok ellent magamnak? A DX11 továbbra is nagyon jó arra amire kitalálták. Csak a fejlesztői igények ezen túlléptek, tehát nem tudja ellátni a feladatát, mivel nem fog problémamentesen kezelni 50-100k batchet frame-enként. Ettől rossz lesz egy API? Nem, csak lesznek nála jobb megoldások. Eleve az MS azt ajánlja, hogy maximum 2k batch legyen frame-enként. Ezt a terhelést viseli el az API. Aki többet vár keressen más API-t. Szóval ez egy nyitott könyv.
Majd felteszi a kérdést: hétszeres gyorsulás megéri? Ha nem, akkor nem kell megvenni. Ettől a gyorsabb futtatás valós igény, tehát a fejlesztőknek tenni kell azért, hogy gyorsuljon a program. Nincs az optimalizálással semmi gond.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#100
üzenetére
Mert a DX11 egy nagyszerű API, csak megvannak korlátjai. Abba gondolj bele, hogy 4 éve jelent meg. 4 év alatt hihetetlenül sokat fejlődött a GPU-piac, míg az API semmit. Viszont hatalmas előrelépés volt a compute shader, amire ma is nagyon épít az ipar, és nagyon sokat gyorsultak tőle a játékok.
A szoftver render ma is reális elképzelés, reálisabb, mint korábban. Számos fejlesztő elkezdte kutatni a GRAMPS-ot. Egyelőre Mantle alatt, de elméletben az OpenCL 2.0 is lehetővé teszi az implementálást a Pipes segítségével.(#101) Kopi31415: A vevő így is úgy is megveszi a programot. Ha akarja, akkor használhatja a régi leképzőt, de nem hiszem, hogy túl nagy lesz a felháborodás az új leképzőkkel, amelyek sokszoros gyorsulást hoznak a vevőknek.
-
Abu85
HÁZIGAZDA
Nem csak beleszólnak. Például John Kloetzli egy saját kiterjesztést írt az API-ba, hogy a CIV: BE úgy használhassa a több GPU-t, ahogy számára ideális. Ilyet nem csak ő tett az elmúlt évben. Johan Andersson is rakott még bele számos kiterjesztést a jövőbeli igényeit figyelembe véve. Az 1.0 megszületéséig azt megtehetik. Egyébként nagyon sok játékfejlesztő igen nagy tudással rendelkezik: Johan Andersson, Dan Baker, John Kloetzli, Josh Barczak, Kevin Floyer-Lea, Michael Bailey. Ők tényleg zsenik, mert időről-időre igen komoly dolgokat tesznek le az asztalra. És rájuk megéri hallgatni. John Carmack is zseni, csak ő már nem foglalkozik játékfejlesztéssel.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#94
üzenetére
Miért tenném ezt? Senki sem tudta, hogy nem fog működni csak miután kipróbálták a gyakorlatban. Erről a funkcióról amúgy sem írtam sokat. Rengetegen csináltak prototípus kódokat, és hiába implementálták sokszor lassulást hozott, mert a driver szálak összeakadtak a programszálakkal. Nagyon fontos egyébként a többszálú végrehajtás kapcsán Dan Baker kutatása. Ő az a programozó, aki tovább jutott bárkinél a DX11 deferred context használatával. Viszont ehhez mindent annak kell alárendelnie, hogy a grafikus driver elszeparáltan működjön. Ez ahhoz vezet, hogy egy sokmagos processzoron ugyan képes használatba venni az összes magot, de a processzor 70%-a így is kihasználatlan. És nem tud rá feladatot rakni, mert figyelni kell a driverre, különben a gyorsulás átcsap lassulássá.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#92
üzenetére
1. Nem az, hogy nem szabványos, hanem nem követi az OpenGL specifikációit. Tehát ha van egy aktuális OpenGL kódod, akkor azt a nulláról újra kell írni ennek a kiterjesztésnek a használatához. Vagy persze megtartani és írni egy újat mellé.
2. Ugyanaz. Azt is a nulláról kell megírni.
3. Semmi baj nem lesz a kompatibilitással. A render back-endet kell cserélni. Maga a main engine a programban változatlan marad, bár nyilván némi strukturális módosítással esetleg érdemes élni, hogy egyszerűbb legyen a jövőben az új API-k beépítése.El kellene fogadni, hogy nagyjából húsz professzionális piacon érdekelt cég kérte az AMD API-jának SDK-ját. És nem csak nézegetni fogják. Ugyanígy lehetőség szerint írnak majd még egy leképzőt az NV-re is. Most, hogy van megoldás ugye.
-
Abu85
HÁZIGAZDA
Hát, ez a verziózása. Logikát én már ezekben nem keresek.
Hivatalos dátum nincs, de szerdán lesz egy szoftveres/driveres konferenciájuk Pekingben. Mivel Huddy azt mondta, hogy idén ki akarják adni, így esélyes, hogy az most lesz szerdán.
(#67) Fiery: Nem valószínű, hogy lényeges különbség lesz a két API között. A DX12 egy az egyben azt a parancspuffer megoldást másolja, amit az AMD kidolgozott. Ezt megtehetik, mert az AMD-től megkapták a forráskódot, hogy felhasználják. Más szempontból már lesznek eltérések, ami okozhat némi sebességkülönbséget.
-
Abu85
HÁZIGAZDA
Ez nem pénzkérdés. Nagyon sok dologban javult a DX12, de vannak dolgok, amelyeket átmentettek a régebbi API-ból, és nem kellett volna. Például az erőforrások kezelése. A DX12-ben még mindig rengeteg eltérő erőforrástípus van: index, vertex, constant buffer, UAV, textúra, textúra tömbök, stb, ez egy rakás teljesen szükségtelen korlátozást jelent. Ennél sokkal célravezetőbb az egységesítés, mivel minden igény kielégíthető összesen két erőforrástípussal. Teljesen érthető, hogy egy fejlesztő felteszi a kérdést, hogy miért kell még ma is szívnia a legacy dolgok miatt, amikor a DX12 nem kompatibilis az elődjeivel. Semmi értelme ennyi erőforrástípust fenntartani, amikor ezt lehetne drasztikusan egyszerűsíteni.
(#64) Fiery: 0.10 lesz a végleges. Papíron ez az 1.0.
-
Abu85
HÁZIGAZDA
Nem. Viszont vannak cégek, akik úgy gondolják, hogy a DX12-nél jobb az AMD saját API-ja, és ezt akarják elsődlegesként használni. Ilyen a DICE, a Gamebase, a Firaxis, az Oxide, a Capcom, stb. Aki az adott videojáték-motor legjobb portját akarja futtatni készíthet egy drivert az AMD API-jához. És innen a megnyitásra vonatkozó igény. Az AMD-t hidegen hagyja a konkurencia, de a fejlesztőpartnereik igénylik a több lehetőséget, így úgy döntöttek, hogy akkor legyen nyílt a specifikáció amint véglegesítik az 1.0-s verzió fejlesztését. Ettől még lesz DX12 port, csak nem az kap kiemelt prioritást a kutatás szempontjából, mert a Microsoft API-ján keresztül nehezebben érhető el a videomemória.
-
Abu85
HÁZIGAZDA
Azért nem jó a DX11, mert nem működő megoldásokat vetettek be az MS-nél a problémákra. Maga a rajzolási parancs többletterhelése majd egy évtizedes gond. A DX9, a DX10 és a DX11 is tartalmazott rá megoldásokat. Azért tartunk most itt, mert egyik megoldás sem működött. Az új API-k amúgy is annyiból állnak, hogy lemásolták a PS3 GCM-jének a működését.
Az AMD olyan helyzetben van, hogy fityiszt mutathat a kompatibilitásnak. Ha valami újítást előnyt jelent a fejlesztőknek, akkor nagy nyugodtsággal dönthetnek úgy, hogy megbontják a régi API-val a kompatibilitást, annak érdekében, hogy egy új API-ba ezt a fícsőrt beépítsék. A low-level irány csak a problémák egy részét oldja meg, de most megjelent az a gond, hogy a shader nyelvek túl elavultak. Ez egy igény és ki lehet szolgálni.
-
Abu85
HÁZIGAZDA
Viszont ebbe egy API nem szól bele. Az egy specifikáció. Vannak minimum igényei, de ha azokat teljesíti a hardver, akkor nem befolyásolja a teljesítményt.
Az AMD API-ja MMU-t igényel minimum. Csak GCN, Kepler, Maxwell és Gen8 jöhet szóba az asztali megoldások közül.
Már most mondom, hogy lesz egy új API-juk. Nem azért mert a mostani rossz, hanem azért, mert jobb shader nyelvet akarnak a fejlesztők.(#49) Fiery: Abszolút nem érdekli az AMD-t, hogy ki implementálja. Viszont pár fejlesztők szeretne ezen az API-n maradni, tehát ahhoz, hogy más is elérje az összes technológiai újításukat nyílttá kell tenni az API-t, vagyis meg kell adni a lehetőséget a támogatásra. Innentől kezdve már egyéni döntés, hogy ki épít rá. Természetesen nem kötelező támogatni, ahogy a PC-s piacon való részvétel sem az.
-
Abu85
HÁZIGAZDA
A GCN a legkisebb probléma, mert megvan minden ahhoz, hogy erre az architektúrára és annak verzióira optimalizáljanak. Ráadásul ha megvan az alap kód, akkor azt egy nap alatt lehet optimalizálni az egyes verziókra. Itt csak a tesztautomatizálást kell jól megoldani.
Sokkal nagyobb gond, hogy a fejlesztők a GCN-en kívül nem ismerik a többi GPU architektúra működését. Valamelyiket nem tanulják meg (Intel), míg valamelyiket nem is tudják megtanulni, mert nincs hozzá dokumentáció (NVIDIA). Ez sokkal nagyobb kihívás lesz a low-level érában, minthogy egy meglévő alapra egy napos munkával készítsenek specifikus optimalizálást. -
Abu85
HÁZIGAZDA
De nem érted meg, hogy ez nem specifikus jelenség. A low-level irány része. A DX12-vel is ugyanez lesz. Amivel ezt ki lehet védeni az nem a szabványos API, hanem minden új architektúra teljes dokumentálása, illetve ezekhez hamar el kell készíteni a fejlesztőeszközöket és a disassemblert. Ha ez megvan, akkor meg lehet kérni a fejlesztőket, hogy írjanak az adott architektúrához specifikus kódot.
A DX12 ebből a szempontból elég rossz lesz egyébként, mert a funkcionális működését nem a PC-hez, hanem az Xbox One-hoz tervezték, tehát az integrált hardverek nagyon előnyben lesznek részesítve. -
Abu85
HÁZIGAZDA
Semmi olyat nem kér az AMD API-ja, amit más ne tudna támogatni egy olyan hardverrel, ami tud legalább OpenCL 1.2-t. Nem kell semmi kompromisszum a core specifikációval. Az implementációkat lehet hardverhez szabni.
(#34) Sinesol: Ez pedig a low-level irány velejárója. Ugyanúgy meglesz a DX12-nél és az új generációs OpenGL-nél. A driver nem tartalmazza az architektúra alapvető vezérlését, ezért ezt a fejlesztőnek kell beírnia az adott programba. Ha jön egy új hardver, akkor az eredeti programkód arra nem lesz hatékony. Ezért mondta az MS is, hogy a low-level irányt az vegye fel, aki képes azt támogatni, vagyis a debütálásra úgy legalább tíz architektúraspecifikus optimalizálással előállni, és a később érkező architektúrákhoz adjanak ki patch-et.
-
#30
Abu85
HÁZIGAZDA
cipofuzo87
#23
Abu85
HÁZIGAZDA
válasz
cipofuzo87
#23
üzenetére
A rajzolás mennyiségétől függ a gyorsulás. Átlagosan olyan háromszorosat várnak, de elképzelhető olyan modell, ahol hétszeres is lesz. Nyolcszoros még reális, de ritkaságszámba megy majd.
(#29) Thrawn: De ezt amúgy sem használná másik hardvergyártó. Ezzel nincs semmi baj. Észrevették egy éve, hogy a professzionális piac elindult az AMD API-ja felé, és most csináltak egy olyan kiterjesztést, ami szintén új leképzőt igényel, de AZDO mellett hozható benne az elég jó sebesség, mert sok szempontból megkerüli az OpenGL működését. Probléma->megoldás. Nem különbözik attól, amit az AMD csinál a saját API-jával, csak más a megoldás típusa.
-
Abu85
HÁZIGAZDA
válasz
#65675776
#20
üzenetére
De ez az NVIDIA privát problémája. Ha lett volna idejük ők is nulláról felhúztak volna egy API-t, viszont egy év alatt csak az OpenGL átdolgozása volt reálisan kivitelezhető koncepció. Ez is működik, csak jóval többet kell dolgozni a fejlesztőknek. A professzionális piacon, ahova ezt szánták valószínűleg nem lesz belőle gond.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
#06658560
#14
üzenetére
Igen. A vevők teljesítményt akarnak, tehát el kell érni, hogy a teljesítményt megkapják. Ha ezt nem lehet megtenni szabványos formában, akkor megteszik gyártókhoz kötődve legyen szó az AMD saját API-járól vagy az NVIDIA aktuális, OpenGL core specifikációkkal nem kompatibilis kiterjesztéséről. Teljesen mindegy a forma, végeredményben úgyis szükség van még egy nem szabványos leképzőre, és abból jön majd a teljesítmény.
-
Abu85
HÁZIGAZDA
Hivatalos bejelentés még nincs, de a SIGGRAPH-on az Autodesk ott volt, hogy ők implementálni szeretnék minden programjukba, ahol előnyt jelent. Illetve nem CAD, de az Adobe is érdeklődik.
Az egész egy alapvető reakció már. A piac a teljesítmény növelése érdekében használni fogja az új lehetőségeket. Az NV-nél is az AZDO+command_list opciót. Ettől jönnek majd a gyorsulások. A sima és szabványos OpenGL persze megmarad, de ha teljesítmény kell, akkor az új API-kat elő kell venni.
-
Abu85
HÁZIGAZDA
Mivel nem követi az OpenGL szabványos specifikációit, így ez a megoldás kvázi egy külön API. A nulláról kell hozzá új leképzőt írni a szabványos leképző mellé.
Az AMD biztos nem fog ilyet csinálni. Ők a Mantle-t kínálják erre a problémára. Azt egyszerűbb implementálni is, tehát semmi értelme az OpenGL-t így kiegészíteni, mert a fejlesztők úgyis a Mantle-t választanák, hiszen sokkal olcsóbb. Az Intel különösebben nem érdekelt a professzionális piacon.(#10) SityiSXT: Az NVIDIA a CAD alkalmazásokat szeretné célozni ezzel. A játékfejlesztőknek nem ajánlja.
Új hozzászólás Aktív témák
Hirdetés
- Xiaomi Redmi 10 128GB, Kártyafüggetlen, 1 Év Garanciával
- AKCIÓ! Gigabyte H610M i5 12400F 16GB DDR4 512GB SSD RX 6700XT 12GB Zalman S2 TG Seasonic 650W
- Bomba ár! Dell Latitude E6520 - i5-2GEN I 6GB I 320GB I HDMI I 15,6" HD+ I W10 I Gari!
- Telefon felvásárlás!! Xiaomi Redmi Note 13, Xiaomi Redmi Note 13 Pro, Xiaomi Redmi Note 13 Pro+
- Veszünk: PS5 Fat/Slim/Digital/Pro konzolt, játékokat, Portalt stb. Kérj ajánlatot!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest