- Apple asztali gépek
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fejhallgató erősítő és DAC topik
- AMD GPU-k jövője - amit tudni vélünk
- Acer notebook topic
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Samsung Galaxy Tab tablet topik
- Melyik tápegységet vegyem?
- Házimozi belépő szinten
- Veszélyben az adataid? Gond van a WD népszerű HDD-ivel
Új hozzászólás Aktív témák
-
arn
félisten
A dx11 megis egyertemu elorelepes volt, ficsorben, latvanyban, sebessegben. A dx12vel mi a helyzet? Harom eve jelentettek be, ket eve piacon, aztan egyet elore egyet hatra kb... ez pc, valtozo hwel, x fele architekturaval, mindig is a hw huzta az egeszet, nem a sw optimalizacio. Az, hogy hwben nem leptek elore sokaig, jol lathatoan a konzolgeneraciok es a kihasznalatlansag az ok, nem az, hogy nincs hova. Most atpasszoltak a labdat a fejlesztoknek, de ezt max globalisan szabalyozva lehet meglepni, nem x uton x felekeppen. Jobban mukodne az egesz korlatok kozott, mert semmit sem er a szabadsag, ha nincs aki mutatja az utat.
-
Abu85
HÁZIGAZDA
Azt csinálta a D3D11, és mindenki egyetért abban, hogy nagyon szar volt. Valahol a két végletet képviselő D3D11 és D3D12 között van az általános igazság. A Metal 2 modellje tűnik az arany középútnak.
(#46) Jack@l: Meg tudják, amikor szétválasztják a Windows 7 és a 10 settings beállításait. Ma még a fejlesztés összevont. De mint írtam az összes tesztünk aktivált HBCC szegmessel futott, tehát működik hiba nélkül. Az AMD is mondta, hogy aki szeretné aktiválja, mert stabil.
Nem a sorral van a probléma, hanem a tesztelés különválasztásával. Ha eltérők az alapbeállítások, akkor a Win7/10 settings tesztelését nem lehet összevonni. Jelenleg a legtöbb ember a Redux meghajtón dolgozik, vagyis nincs igazából erőforrás különálló tesztelésre. -
Abu85
HÁZIGAZDA
válasz
#06658560
#40
üzenetére
Nem, hiszen szépen fejlődik az ipar.
Azt senki sem mondta, hogy szar. Inkább az a baj, hogy a programozóknak az a része lett megkérdezve, akik alapvetően nagyobb szabadságot akartak. Az a része régebben nem is szólhatott bele, akik esetleg más álláspontot képviseltek. Az utóbbi réteg most kezdi belevetni magát és felmerültek a problémák. Ezek közül a legsúlyosabbat szerencsére egy szimpla függvénykönyvtárral, vagy mondjuk egy olyan hardveres megoldással, mint a HBCC kezelni lehet. Ennyi.
A legtöbben egyébként a Metal 2-t tartják a jó iránynak, de nyilván új API-t nem fog csinálni a Microsoft. Ebben benne van a pénz és az idő, így a D3D12-n belül fogják kezelni a felmerült problémákat.(#42) Jack@l: Mert még nincs különválasztva a default konfiguráció Windows 7-re és 10-re. És mivel HBCC nincs Windows 7 alatt, így alapértelmezetten a default konfigot inaktiválni kell. De egy kattintás aktiválni, és működik. Az összes tesztet ezzel csináltuk.
-
#06658560
törölt tag
Mindjárt itt a konzol port, mindjárt itt a Mantle, mindjárt itt a DX, mindjárt itt az SM6.0. Mondd, nem unod még?
"Azért vezették be, mert nem alakul tökéletesen a D3D12 és a Vulkan ebből a szempontból, így ha a programozók nem tudják ezt megoldani, akkor adni kell alájuk hardveres segítséget."
És kell várni két évet, hogy elkezdjenek hisztizni a programozók, miszerint ez egy szar, vagy már jövőre is lesznek ilyen hangok?
-
Abu85
HÁZIGAZDA
Igen. Ez egy hardveres rendszer, tehát nem számít, hogy milyen szar a programban a memóriamenedzsment, a hardver erre nagyrészt immunis, mert programfüggetlen a vezérlés nagy része. Azért vezették be, mert nem alakul tökéletesen a D3D12 és a Vulkan ebből a szempontból, így ha a programozók nem tudják ezt megoldani, akkor adni kell alájuk hardveres segítséget.
-
"Az egész a mára tervezett hardverekkel probléma, de a holnapra tervezettekkel már nem tényező."
Vega most jelent meg pár napja. a GCN meg a DX 12 meg már jó pár éve. Pont ezt írtad ezelött x éve is a GCN megjelenésekor.
Ilyenkor ezért érzed azt,hogy mekkora nagy átverés volt eddig az egész és megint arról szól a fáma, hogy a vásárlók a tesztalanyok és mekkora felelősséget hordoztok ezekkel a semmibe kilökött kijelentésekkel, amivel embereket vesztek rá, hogy higgyenek és vásárolnak is ezen dolgok alapján. Nem is tudom hogy tud még bízni az a pár radeon hívő ezek után bárminek, vagy éppen hogy tudja NV-t pocskondiázni, mikor megint az látszik , hogy igen is ők látják jól a piacot és nem azért mert ők diktálnak, hisz a konzolok magasabban kvalifikáltak a PC nél.
Vega 56 egy jó kis kártya, de nem azért " mert majd jó lesz" hanem azért mert most jó. -
Abu85
HÁZIGAZDA
válasz
#06658560
#33
üzenetére
Ezt úgyis kezelni fogják. Lásd a Vega a HBCC-vel.
Az egész a mára tervezett hardverekkel probléma, de a holnapra tervezettekkel már nem tényező.Egyáltalán nem kell nagyon specifikus kódot írni. A Microsoft megoldása olyasmi lenne, mint ez: [link] - persze nem Vulkan API-ra, hanem D3D12-re, de az alapelv tök ugyanaz.
-
#06658560
törölt tag
Komolyan gondolod, hogy nem jelent gondot az, hogy újabb hardveren rosszabbul futhat egy adott játék?
#31 awexco: "Most meg a gamerek sírnak mert a programozok lusták és vagy drága a bérük ."
Nem hiszem, hogy lusták, hanem nincs rá idő, egyszerűen nem éri meg hat féle kódot írni, tesztelni és karban tartani.
-
arn
félisten
Hude regen megjosoltam, hogy ez igy lesz... Egyszeruen a jatekfejleszto abban erdekelt, hogy a jateka jol fusson a gepek nagy reszen, es nem abban, hogy egyik masik hw kepessegeit kidomboritsa, a nagyon eltero felepites hibait kijavitsa, etc. Mennek a tomeg utan. Max lefizetett cimekben latunk mast.
-
Abu85
HÁZIGAZDA
Ezt nem lehet megcsinálni hardveresen. Ahhoz hardveres támogatás is kell, lásd Vega. Egy függvénykönyvtár pont úgy működne, ahogy egy aktuális D3D12-es program, csak úgy jó ezer kódsort a Microsoft adna. Ennyi. Igazából az egész nem sokban különbözik attól, amit az AMD kínál a Vulkan API-hoz VMA néven. Az elv és a cél ugyanaz.
(#26) Kopi31415: A megjelenés utáni hardverek már nem jelentenek komoly gondot. Pár százalékkal lehet rosszabb a hatásfok.
(#28) KKaresz45: Itt egyelőre szó sincs magasabb absztrakciós szintről. Csak egy függvénykönyvtár lenne az egész.
-
Abu85
HÁZIGAZDA
A driver egy rendkívül vékony réteg a D3D12-ben. Gyakorlatilag minden feladat, ami a D3D11-ben a kernel driverben volt, azt D3D12-ben programba kell írni. Ezeket a programkódokat biztosítaná a Microsoft egy esetleges függvénykönyvtárban. Ezek igazából a játékra vonatkozóan nem tesznek semmit, csak alapvető menedzsmentfeladatokat látnak el, amelyek régen amúgy is a driver feladati voltak. Például egy ilyen függvénykönyvtárral nem kell azt is megírnod, hogy miképpen allokálsz egy puffert, hanem csak meghívod az erre vonatkozó függvényt és a hozzá tartozó headerben már ott van az erre vonatkozó programkód.
-
KKaresz45
senior tag
Korrekt írás, kifejti az AMD felelősségét is a kialakult helyzetért. A MS-nak azért is kellett égetően a DX12, mert kellett valami amivel Win 10-re csalhatja a gamereket.
Viszont hardver közeli API-val úgy kell PC-re is játékot fejleszteni ahogy konzolra kellett. Az pedig nehéz. Azért volt jó PC-re játékot fejleszteni, mert relatíve egyszerű volt a high level API miatt. A PC nem konzol, és aki konzolt akar csinálni a PC-ből az megbánja.
A megoldás egy újabb high level API lesz PC-re, ahogy a cikk vége is fejtegeti (csak nem nevezi nevén). Szerintem a mostani irány egyszerűen zsákutca a PC játékok szempontjából.
-
Jack@l
veterán
Peersze, szidjuk az nvidiát amiért egy eleve eröltetett félig hülyeség low level apival a fejlesztők nem akarnak dupla ideig szórakozni... Vagy mert éppen semmi előrelépés nem volt vele sebeségben.
Besült, pedig mennyire hi-tech világmegváltó volt még induláskor a mantlival együtt.
UI: nem lepődnék meg ha ez így maradna még néhány generációváltás után is, aztán kiderülne hogy nem a Pascalokkal volt gond ilyen téren. -
#06658560
törölt tag
A nem csinál semmit úgy értsd, hogy nem a játék érdemi részével foglalkozik. Hanem figyeli, hogy áll a VRAM telítettsége, s millió if esetén csinálja A-Z kimenetek valamelyikét a memória megtelése elkerülése érdekében. Vagy folyamatosan szinkronban tartja a memóriát a rendszermemóriával. Stb. De ezeket is a játékot fejlesztőnek kell kezelnie, figyelembe véve a három gyártó tíznél több architektúráját, és a GCN-ek eltéréseit is.
#25: Persze, hogy nem egyszerűbb. De nem mindegy, hogy a játékfejlesztő kell megírja, vagy a hardverfejlesztő. Aki egyszer megírja és adhatja oda minden stúdiónak, azonos minőségben, vagy minden stúdió magának gányol minden hardverre valamit. Pláne a játék kiadása után megjelenő hardverek esetén érdekes a support kérdése.
-
Inkább mondjuk úgy hogy AMD is ( talán Microsoft is)rájött arra, hogy nem olyan jó ez a túl nagy szabadság a fejlesztők kezébe, mert szarnak rá, se pénz se idő ,ezért jobban járnak, ha még is csak az átkozott NV által járt kissé szabályozottabb utat választják, azaz például megpróbálják a memória menedzsmentet hardveresen megoldania fejlesztők helyett stb...
-
hapakj
őstag
Tulajdonképpen az egész arról szólna, hogy a Microsoft biztosítaná azokat a kódokat a fejlesztőknek, amelyek önmagukban továbbra sem csinálnak semmit, de alapvetően szükségesek a rendszer működéséhez.
Ezt nem teljesen értem. Valaki tudna mondani példát olyan program kódra ami nem csinál semmit, de alapvetően szükséges a rendszer működéséhez, meg olyan programkódra ami önmagukban is csinálnak valamit?
Egyébként a kommentekből azt sikerült leszűrni, hogy az AMD továbbra sem tud drivert írni. Illetve ne csináljon olyan komplex hardvert amihez nem képes. "A hardver szoftver nélkül csak homok"
-
Ragnar_
addikt
Kíváncsi leszek hány év lesz a megjelenéstől, mikor azt mondhatjuk, hogy a Vega egyértelműen (15-20%) gyorsabb már DX12 játékok alatt, mint a teljesítménykategóriájának megfelelő Pascal. Elvileg az már csak a szoftver oldalon múlik akkor, kb. mint a 4c/8t és 8c/16t prociknál, hogy mikor kezdik hatékonyabban kihasználni a többmagot... (És nem az van, hogy egy 6c/12t proci átlag 40%-on fut, ami amúgy nem rossz, mert nem lesz procilimit miatt akadás de optimális kihasználásnak azért nem mondanám..)
-
Abu85
HÁZIGAZDA
Mivel még nincs bindless program, ezért a D3D12-ben az erősorrend sokat változhat. Ez független a Vegától. A Vegának szimplán meghajtók kellenek, amelyek aktiválják a képességeit.
Pascalon is segít a D3D12, ha sok rajzolási paranccsal dolgozik a program. A többi gyorsulást hozó tényező nem igazából létezik Pascalon, így az aszinkron compute, a bindless, és az FP16 extráiból nem tud érvényesülni.
-
Ragnar_
addikt
Értem. Akkor mondhatjuk, hogy a dx12 jelenleg még korántsem mutatja az igazi előnyöket, ahogyan a Vega is lesz még gyorsabb. Ez így életszerű, és az Nvidia is valószínűleg kénytelen lesz követni a dx12 igényeit a következő architektúrájával. (És Pascalon már ne is várjunk csodát dx12 teljesítményben, akármit is változtatnak szoftver oldalon.)
-
Abu85
HÁZIGAZDA
Még nem, mert tele van inaktivált funkcióval a meghajtó. Emiatt látható az, hogy a Vega nagyon haknis a különböző tényezőkre. Van amikor az 1080 Ti sem jelent problémát neki, de van amikor az 1070 is kemény ellenféllé válik. Majd akkor kell ezt megnézni, ha a meghajtóban aktiválják a hardverbe épített képességeket. Akkor lehet erre vonatkozóan levonni bizonyos következtetéseket.
-
Abu85
HÁZIGAZDA
Igazából kevés emulációt használó implementációkon már most azok.
Az is tipikus probléma, hogy a parancsmotorok kezelése rendkívüli módon megváltozott. Egy rakás sokszor használt parancsra építettek a gyártók az architektúrába úgynevezett fast pathot (az NV szinte csak ebből élt). Ezeket használták D3D11 alatt, viszont annyira erre építettek, hogy az általános pathot el is hanyagolták. Ugyanakkor a D3D12-ben az operációs rendszer címzi a fő parancsmotort, a meghajtó csak a compute parancsmotorokért felel. Ezáltal a D3D12-nél a hardverekben hiába van sok fast path, az elhanyagolt általános pathra kényszerül a munka, mert az OS a fast pathot nem ismeri, a driver pedig nem súghat neki. -
-
Abu85
HÁZIGAZDA
Ez sajnos nem csak a fejlesztőkön és az API-n múlik. Az egyes D3D12 implementációk (hardver és szoftver együttvéve) nem alkalmasak arra, hogy gyorsabbak legyenek bizonyos körülmények között, bizonyos konfigurációkkal. Például te az aláírásodban szereplő gép pont beletartozik ebbe a körbe, de a hardverek fejlődnek, hatékonyabbak lesznek az általános adatutak a parancsprocesszorokban, és emiatt egyre inkább a D3D12-höz tudják a gyártók igazítani az szoftveres implementációjukat is, így az újabb architektúrákkal jóval kevesebb emulációt fog használni a meghajtó.
-
awexco
őstag
"Persze ezen próbálnak javítani az érintett fejlesztők, de egy alkalmazást, különösen egy játékot nem fejlesztenek örökké, így pár hónappal a megjelenés után jön esetleg egy nagyobb frissítés, és jutottak ameddig jutottak alapon a komolyabb optimalizálásnak vége is."
lásd Dishonored 2 de Hitman is tud érdekes dolgokat művelni .
Add már meg az amd szoftver részlegének emailjét, leírom nekik a 2 sort amivel megoldható...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 13 mini 256GB Midnight -1 ÉV GARANCIA -Kártyafüggetlen, MS3623, 94% Akkumulátor
- REFURBISHED és ÚJ - DELL Universal Dock UD22
- BESZÁMÍTÁS! ASUS ROG Phone 9 Pro 16GB/512GB telefon garanciával hibátlan működéssel
- ÚJ HP OmniBook Ultra Flip 14"OLED 2,8 K 120Hz - Ultra 7 256V - 16GB - 1TB - 2,5 év gari - MAGYAR
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest