- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy S23 Ultra - non plus ultra
- Vivo X200 Pro - a kétszázát!
- iPhone topik
- Egy óra, két rendszer
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Fotók, videók mobillal
- Samsung Galaxy S24 - nos, Exynos
- Samsung Galaxy A54 - türelemjáték
- Átlépi végre az iPhone az 5000 mAh-t?
Ú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.
-
-
-
bozont
veterán
Úgy rémlik a G-ből kimaradt egy-két apróság a sietség miatt. De ha megjelennek az összehasonlító tesztek akkor kiderül van-e jelentősége. Viszont az hogy az Nv nem támogatja, az legyen az ő baja, csak rajta múlik. Nálam ez megint egy ok, hogy ne vegyek Nv-t, pedig ez a Maxwell igen szimpatikus architektúra.
-
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.
-
#06658560
törölt tag
Javaslom fuss neki noch einmal a #58-as kommentednek! Azért nem jó a DX... Egy x éve fejlesztett, azóta maximum csak reszelt rendszeren kéred számon, hogy teljesítse az azóta felmerült igényeket. nem lehetne, hogy a különböző, egymásról nem tudó személyiségeid valahogy megszámozd, hogy tudjuk mikor melyik mit ír?
"Majd felteszi a kérdést: hétszeres gyorsulás megéri?"
Ejj de értetlen vagy. A sebességnél vannak fontosabb tényezők is egy cég életében. vagy neked egy szoftver csak akkor jó, ha sebességben javul, minden más mellékes? Remélem soha nem leszel olyan pozícióban, hogy te dönts arról, milyen szoftvert kelljen használnom napi munkám során.
-
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.
-
#06658560
törölt tag
Na, akkor az állításaid hozd már összhangba! Magadnak mondasz ellent.
Hatalmas tévedésben vagy. A vevő akkor veszi meg a programot, ha neki megéri. Nézz körbe az iparban! Melyek az aktuális CAD verziók, miket használnak, valamint less rá a Dassault CATIA V6 történetére, különös figyelemmel a Mercedes reakciójára és annak hatására!
-
Loha
veterán
NV_command_list működés közben: Command-List on CAD Models
-
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.
-
zsambor
újonc
Elojaroban, rengeteget utazom de beszoktam nezni a ph-ra. viszont ma regisztraltam es mar unalmasnak tartom reszemrol ezt a megfogalmazast/sugalmazast ha lehet ilyet irni. Most komolyan? Ennyit tudok reagalni erre a clikk magnet cikkre. Fiery meg par ember meglatasom szerint erti a lenyeget. Sokan masok viszont terelnek a cikkiroval egyetemben. Reszemrol ennyi,. Ami itt folyik mar egy jo ideje az mar kicsit sok.
-
Fiery
veterán
válasz
#06658560
#93
üzenetére
Abu szerint a jatekfejlesztok beleszolhatnak, es bele is szolnak a Mantle fejlesztesebe. Sot, tulajdonkeppen a jatekfejlesztok, foleg a zseni tipusok hatarozzak meg a Mantle alakulasat, fejlodeset. Ha az Intel vagy az nVIDIA implementalni akarja a Mantle-t, nem kell mast csinalnia, mint alruhas jatekfejlesztonek kiadnia magat
John Carmack maszk persze nem jo, hiszen tudjuk, hogy o mar nem ert semmihez, senki sem veszi ot komolyan ![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#06658560
törölt tag
1) Nem pont arról szól a cikk, hogy egy nem szabványos megoldást kapunk?
2) Mantle mennyire szabványos?
3) kompatibilitás nem csak keresztbe, hanem hosszába is. A régi rendszerbeli adatokhoz.Néha nem ártana elszakadnod attól, hogy mindent AMD/NV->programfejlesztők relációban vizsgálsz, sok piacot nem ez mozgat. Sőt, igazán a játékokon kívül egyet sem.
-
Jack@l
veterán
Azért mondtam hogy fordítva, mert amd-ben van 8 mag, de csak 4 teljes értékű, míg intelben 4 fizikai mag van csak.
A HT virtuálisan hoz létre 8 szálat, de a 8 szálon csak 4 mag dolgozik, a két szál közötti ugrálás van csak felgyorsítva magon belül a szoftveres szálváltáshoz képest. -
#90
Fiery
veterán
antikomcsi
#89
Fiery
veterán
válasz
antikomcsi
#89
üzenetére
En meg amondo vagyok, barcsak eljonne az a korszak vegre, amikor tenylegesen, minden teljesitmeny orientalt szoftverben (es jatekban) ki lehetne hasznalni minden rendelkezesre allo eroforrast, minden CPU-magot, a teljes rendszermemoriat, stb. Onnantol kezdve vegre el lehetne felejteni azt, hogy hany magos es milyen orajelu egy proci, csak az szamitana, hogy milyen a teljesitmenye. Abban a szep uj vilagban az AMD-nek is konnyebb dolga lenne, hiszen csak bele kellene raknia a tokba par plusz magot, ha a standard kiepites (2 modul / 4 mag) nem versenykepes
-
Laja333
őstag
Nem lelkesedünk, csak elmondjuk a tényeket. Aztán jön az ellentábor, és érzelmi alapra helyezik a témát. Jól megsértődnek, mert beletaposnak a lelkükbe, majd fellengzősen, lesajnáló hangsúllyal próbálják palástolni bukásokat, mert hogy a tényekkel már megbuktak.
Én is csak mosolygok, amikor a tények szembesítése után a másik fél csak makogni tud és látszik a komment mögül, hogy majd szétveti a düh, mert a sziklaszilárdnak hitt bizonyítékát fél pillanat alatt lepöckölik. ^^
Jack@l nem fordítva ülök, csak hátra felé nyilazok. Mint a szittya magyarok.
-
Fiery
veterán
A problem csupan az, hogy az Intel folyamatosan magnak hivja a magot, es sosem hivja rendes magnak a virtualis HyperThreading szalakat. Mig az AMD folyamatosan magnak hivja a magot, es sosem hivja magnak a modult. Ebbol pedig az jon le, hogy az emberek azt hiszik, 4 magos az i7, es 8 magos az FX. Amivel nem is lenne gond, ha az FX duplaolyan gyors lenne, mint az i7
Egyebkent meg maradjunk annyiban, hogy az FX 8 magos, csak epp a legtobb esetben a szukos eroforrasok miatt megfelel a teljesitmenye egy 4 magos Intel processzornak. Hasonlokepp ahhoz, mint anno a PR jeloles a K5, K6 procikon: neha hozta azt, ami ra volt irva, de legtobbszor inkabb a valos orajelnek megfelelo teljesitmenyt
Az FX is egy furge 4 magos proci, es egy nagyon lassu 8 magos -
pakriksz
őstag
hát igen mint ahogy írták ilyen alapon az i7 is 8 magos, hiszen 4 mag plusz HT ami több mint négy, a FX 8 magja pedig nem 8 teljes mag.
Te azt látsz amit szeretnél, de attól még nem lesz igaz. De ha a HT-t levennénk azokból a magokból, akkor levághatnál a magokból egy jókora részt.
Egyébként ez hogy is jön ide? A játékok mag használatáról volt szó, és te most jó fanboyként intel felsőbbrendűségi kiselőadás felé tereled a dolgot
@Jack@l: keresd meg, talán 1-2 hete volt itt a hír arról, hogy 4 szál alatt fekete képernyőt ad az fc4, ami egy mesterséges korlátozás. Ha jól emlékszem te is benyögtél oda pár "okosságot".
-
pakriksz
őstag
-> draw call téma. Éppen az a probléma hogy 1 szál a rajzolás amit nem lehet többre szétosztani a jelenlegi grafikus apikban, korlátozza az egész játék teljesítményét, ezért számít az 1 szálas teljesítmény. A többi mag meg csak részterhelést kap, tehát lényegében egyenlőtlen a magok terhelése. Meg lehet nézni, minden cpu korlátos játékban az 1 szálas teljesítmény számít, pont ezért.
Az a 4 mag használat a fentin kívül amúgy is úgy szokott kinézni hogy leírják a készítők hogy az 4 magot használ... aztán általában nem használ, vagy csak ritka esetekben, esetleg mesterséges korlátozásokat raknak be mint az fc4-nél
Ha olyan kiválóan sok szálúak lennének a játékok, hasonló eredmények jönnének ki amd fx és core ix procik között mint a sokszálú teszteknél (render, video kódolás stb), de nagyon nem így van. -
#70
pakriksz
őstag
cipofuzo87
#23
pakriksz
őstag
válasz
cipofuzo87
#23
üzenetére
"de ezt már 10 éve tudja minden fejlesztő, éppen ezért kevéssel dolgoznak, végeredményben ugyanazt a látványt/fps-t lehet érni."
Legalább is rálátás nélkül ezt hiszed...
-látótáv korlátozások szinte kizárólag emiatt vannak (mert ha rendesen lodolják a modelleket, a távolban lévő pár poligonos lodok már úgy sem terhelik a gpu-t nagyon).
-kevés draw callra optimalizálni egy modellt szintén nem egyszerű dolog, és nem is egy pillanat műve, tehát nem is olcsó, ha magamból indulok ki, kevés draw callra való optimalizálás nélkül kb feleannyi idő alatt összehoznék egy azonos részletességű textúrázott modellt.
-a fenti igaz a játékmotor programozására is, a draw call kötegelés, és instancing elkészítése nem egyszerű dolog, a debugolása meg főleg nem.
-nem csak erős procival szeretnénk játszani, én örülnék ha a low level apiknak köszönhetően csak a gpu számítana, cpu meg kb tökmindegy lenne, és elég lenne mondjuk 10 évente cserélni... mert manapság a játékok miatti cpu cserék szükségessége csak a draw callok api overheadjának köszönhető. -
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.
-
Fiery
veterán
A Mantle es DX12 vedelmeben azt azert el kell mondani, hogy mas lesz a helyzet, ha majd egy adott jatek motort kifejezetten ugy fejlesztenek, hogy Mantle es DX12-n szebb legyen a latvany, bonyolultabb legyen a scene, stb. Akkor a DX11 vasakon benabban fog kinezni, es nem is lehet majd direktben osszevetni a modern API-s verzioval, de siman lehet(ne) 100%-os teljesitmenybeli kulonbseg. Mas kerdes, hogy a DX12 mennyivel fog gyengebben muzsikalni a 2016-2017 tajekan piacra kerulo jatekokban, mint a Mantle, arra en magam is nagyon kivancsi leszek.
-
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.
-
-
Fiery
veterán
"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"
Ez szivuk joga, es termeszetesen siman igazuk lehet, minden szempontbol. A kerdes csupan az, hogy ha mondjuk a DX11-gyel elerhetsz 50 FPS-t egy adott engine-nel, a DX12-vel mondjuk 100-at, a Mantle-lel pedig 110-et (azaz csupan 10%-ot nyersz a DX12-hoz kepest, ez szerintem realis atlag lehet majd a gyakorlatban is, de cafolj meg nyugodtan, ha rosszul sejtem), akkor mennyire van ertelme a Mantle-lel molyolni. Amennyiben persze nem az AMD penzeli a Mantle port fejleszteset, vagy nem kerul nagyon kicsi meloba (es azzal egyutt penzbe ugyebar), valamint minimalis validalasi overheadbe a Mantle tamogatasa. Ha a DX12 mondjuk 95%-ban ugyanugy mukodik, mint a Mantle, akkor megerheti a keves plusz melot beletenni a Mantle portba, de ha ilyen nagy (lenne) az egyezes, akkor meg a ketto kozotti teljesitmeny kulonbseg sem lehetne szamottevo, akkor pedig megint nem eri meg foglalkozni a dologgal -- kiveve ha az AMD-hez fuzi a jatekgyartot valamilyen specialis kotelek.
Az 1.0-s verziot pedig a publikalastol szamitott 14 honap alatt igazan osszelapatolhatta volna az AMD. De majd talan jovore
Mondjuk nem nez ki tul jol a helyzet, hiszen me'g mindig v0.08 (nem pedig v0.8) es hasonlo verzioknal jarnak abban a release-ben, amit nem szegyellnek egyes fejlesztoknek odaadni -
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.
-
Fiery
veterán
Oke, de ott (lesz) a DX12, ergo nem kell (nem kotelezo) a Mantle-lel molyolni mindenkinek. Ha a DX12 nem lenne kepben, akkor nyilvan teljesen mas lenne a helyzet, akkor a Mantle elleneben keszulne hasonlo API az Intel es az nVIDIA boszorkanykonyhajaban is. Amiket nyilvan szinten a sajat hardverukhoz terveznenek es igazitananak, es persze amik nem lennenek nyiltak.
-
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.
-
Fiery
veterán
-
Fiery
veterán
Ha az API nem befolyasolhatja a teljesitmenyt, ha egy API-hoz nem kell optimalizalni a hardvert, ha egy API-t nem a meglevo es varhato hardverek ismereteben kell megtervezni, akkor miert nem jo manapsag a DX11, miert kell nekunk DX12?
"Már most mondom, hogy lesz egy új API-juk."
Miert kell uj API, ha a regi API barmilyen hardverrel optimalis?
A GCN utani AMD vashoz megse olyan franko a Mantle? Akkor miert kene hogy optimalis legyen a nem-GCN Intel es nVIDIA GPU-khoz?"Nem azért mert a mostani rossz, hanem azért, mert jobb shader nyelvet akarnak a fejlesztők."
Ahhoz nem kellene uj API... A Mantle hivasokba nincs beleegetve a shader nyelv.
Es tovabbra se azon rugozok, hogy lehet-e valamit implementalni. Nyilvan lehet, ha megfelel a vas az API altal tamasztott kovetelmenyeknek. De mas kerdes valamit futtatni, es valamit igazan jol futtatni. Ha 3 db Mantle API hivassal lehet valamit optimalisan megoldani GCN-en, az tok jo, de lehet hogy Maxwellen 2 db hivassal is meg lehetne oldani, ha az adott hivasok kicsit mast csinalnanak Maxwellen. Ha pedig Maxwellen kenyszerusegbol 3 db hivast kell hasznalni, maris van egy overhead, amitol nem lesz a Mantle optimalis a Maxwellhez. Ez nagyon sematikus pelda, de talan ez alapjan Te is erted, hogy mire akarok kilyukadni. Amugy meg tok mindegy, hogy kinek van igaza, a Mantle-t semmilyen mas gyarto nem fogja implementalni, ergo sosem tudjuk meg, van-e ertelme mas vason is hasznalni.
-
Laja333
őstag
De gondolom az NV módosított opengl megváltja a világot dolgot egyből bekajáltad, pedig még azt se látod sehol. Csodadriverüket is legendákba magasztaló marketing övezte, amivel elv felvették a versenyt Mantle-el. Gyakorlatban meg néhol visszalépés volt az előző verzióhoz képest is. Vizet prédikálás...
-
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.
-
Fiery
veterán
Nem, en nem azt mondom, hogy az AMD rosszindulatu, sot. De naivsag azt hinni, a Mantle-t azert tettek (ill. majd teszik, mert most me'g nem az -- ezt is szeretik egyesek elfelejteni) nyiltta, mert azt szeretnék vagy azt varjak, hogy majd mas hardvergyarto is implementalja. Senki sem fogja. Ha pedig nem implementalja senki mas, akkor mi is a kulonbseg koztuk es az nVIDIA kozt? Az, hogy az nVIDIA jol felfogott erdekbol (= ne masolja le senki azt, amit ok kitalalnak, amibe penzt es idot fektetnek) nem teszi nyiltta a sajat IP-jet. Az ido es a gyakorlat pedig eddig az nVIDIA-t latszik igazolni. Az nVIDIA joval fiatalabb cegkent is joval erosebb manapsag, mint az AMD.
Azt sem mondom, hogy egy nyilt Mantle ne lenne tok jo a fejlesztok szamara. De -- szerintem -- osszessegeben me'g ezzel a nagy nyiltsaggal egyutt sem fognak tudni messzire jutni, egyszeruen el fogja a Mantle-t taposni (sajnos) a DX12.
Es me'g annyit, hogy a joindulat es a profitorientalt mukodes nehezen fernek meg egyutt. Ha belefektetsz valamibe par (tiz)millio Ft-ot es 1-2 ev munkat, es aztan az eredmenyen mulik adott esetben a ceged jovoje, Te sem fogsz jofejkedessel kockara tenni mindent, ha siman megtarthatod magadnak a megalkotott IP-det. Az IP-d megnyitasa jofejkedes, de a nem megnyitasa nem rosszfejkedes, hanem teljesen termeszetes hozzaallas.
-
Laja333
őstag
Mint ahogy a cikkben írt openGl módosítás és dx12 várás nv oldalról sem jött volna el, ha nincs Mantle.
Fiery értem, hogy foggal körömmel akarod bizonyítani, hogy az AMD tök önzőségből készített egy nyílt valamit, de áruld már el NV mit tett le az asztalra csupa jóindulatból. Ők még ráadásul direkt akarnak kibabrálni a többiekkel. Akkor honnan ez az anyai ösztön nálad?
Sosem tudom megérteni mi az NVseknél ez az álandó vágy, hogy bebizonyítsák az AMD tök rosszindulatból akar bárki számára hozzáférhető technológiát használni. Az NV meg csupaszív használja az NV-only featureöket, csak hogy elősegítse az ipart.
-
Fiery
veterán
Egy dolog implementalni valamit, es egy tok mas dolog optimalisan kihasznalni egy API-val a hardver altal biztositott eroforrasokat. Ennyi erovel barmelyik ARM SoC-on lehetne az x86 "API"-t implementalni, csak rohadt lassu lenne... A Mantle ugyanannyira jol mukodne VLIW5-on, mint GCN-en? Ugyanannyira frankon ki lehetne hajtani egy masik AMD-s architekturat is? Ha a GCN utan jonne egy XYZ AMD-s architektura, amit a Mantle ismerete nelkul terveznenek, azzal is tokeletesen es optimalisan hasznalhato lenne a Mantle? Ketlem... A GCN es a Mantle kez a kezben jar, ez teljesen termeszetes, de ne probald mar meg ugy eladni, mintha az AMD azert tervezte volna a Mantle-t, hogy aztan minden GPU-gyarto felhasznalja. Ha lazabbra terveztek is az API-t, hogy ne kotodjon teljesen a GCN-hez, annak csupan az az oka, mert nyitva akartak hagyni maguknak a lehetoseget arra, hogy a GCN utan is lehessen egy uj GPU architekturajuk, es ahhoz ne kelljen teljesen uj API-t fejleszteni.
-
Thrawn
félisten
Igen, profitálhatok belőle, de ha van egy egyetemes, speciális hardverek nélkül is működő megoldás, akkor miért használjak egy olyat, ami kábé ugyanazt tudja, viszont drágább, kell hozzá egy spéci VGA és egy spéci kiegészítővel felszerelt monitor? Az is agyrém volt, hogy a monitort már előre megvehetted, hogy aztán otthon nekiállhass szétborítani csavarhúzóval fűrésszel, fogóval, kalapáccsal, hogy egy panelt beletuszkolhass. Jó, tudom, most már előre beszerelik, de ez akkor is agyrém volt.
A G-Sync ára a kialakítása miatt nem tud annyit mérséklődni a FreeSync megjelenésének hatására, hogy valaha is megforduljon a fejemben, mint lehetséges választás. -
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. -
Sinesol
veterán
Értem az okát, de ez nem javít azon amit tapasztalunk. Persze el lehet készíteni az dokumentációkat, de ha már lesz vagy 10 fajta Gcn, akkor vajon hány fejlesztő fogja venni a fáradtságot? Van egy olyan érzésem, hogy elég lesz ha jó legújabbon, a többiek meg ugyis vesznek uj vga-t. by Ubisoft
Persze a low fpst látva tudni fogom mi az oka, de a tudat nem ad folyamatos játékélményt az a baj -
TTomax
félisten
Nekem azt elég nehéz elhinni,hogy majd egy éve kiadott játékoknál patch fog érkezni a frissen megjelent vgak-hoz...
(#42) Abu85
Aham,hát az dicséretes,de majd a 490X-hez is fog jönni 2016-ban amikor a BF5 kinn lesz,és közben a BF6-on dolgoznak?Pontosan ami az előnye az egyben a hátránya is a low levelnek...Naná a gyártók meglovagolják mert rövidtávon profit realizálódik,ez érdeke egy fogyasztói társadalomnak.. de nekünk semmiképpen nem lesz pénztára barát hosszútávon... -
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.
-
TTomax
félisten
A frissen kitalált technológia éppen kilenc éves,a freesync se lesz "free" ott is meg lesz fejelve az árával a monitorra akasztott árcédula,és amint kapható lesz a G-sync ára is mérséklődni fog,még azt is meg merem kockáztatni hogy nem is lenne olyan fontos ha nem jött volna a G-sync,tehát valahol TE is profitálhatsz belőle...
(#37) Thrawn
Pontosan ott ahol most!Ezért is annyi a G-sync amennyi!!! -
Thrawn
félisten
-
Fiery
veterán
Az nVIDIA ezzel a hozzaallasaval, feleannyi ido alatt nagyobb es erosebb cegge valt, mint az AMD. Szerinted akkor ki csinalja jol es ki csinalja rosszul?
Persze tudom en, hogy az AMD csak es kizarolag az elnyomo Intel miatt nem tart az nVIDIA szintjen, sot, me'g a szemet nVIDIA is nyomja oket....."Egy API-t nem lehet architektúrára optimalizálni."
Dehogynem lehet.
-
Fiery
veterán
Hiaba nyitsz megy egy API-t vagy specifikaciot, ha semmilyen realis esely nincs arra, hogy mas gyarto is hasznalhatja a sajat hardverehez. Ez nem Linux kernel, hogy forkoljak, aztan majd Android neven mindenki jol jar vele... A Mantle AMD-only, es az is marad. Ez persze nem baj, de ne allitsuk mar be ugy az AMD-t, hogy mindenki szamara talalta ki a Mantle-t. Sajat maga szamara, a sajat GPU architekturajahoz igazitva alkottak meg a Mantle-t, ennyi. Kompromiusszumokkal, kiegeszitesekkel talan lehetne hasznalni mondjuk Maxwellhez vagy Gen8-hoz, de ugysem fog megtortenni.
Ha pedig ezzel osszevetjuk az nVIDIA-fele megoldast, akkor nem gondolnam, hogy egyik vagy masik annyival gagyibb lenne. Ki mibol tud fozni. Az nVIDIA reszerol, a DX12 potencialis debutalasat figyelembe veve, teljesen felesleges lett volna cca. 1 eve nekiallni egy sajat fullos low-level API-nak. Egyszerubb takolni az OpenGL-t es implementalni a DX12-t. Sot, az nVIDIA siman lehet, hogy jobb utat valasztott ezzel: majd a piac fogja eldonteni, milyen sorsra jut a Mantle. Siman lehet, hogy mar a felfutas elott el is foldelhetjuk szepen
-
#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.
-
Thrawn
félisten
AMD - Mantle -> bárki használhatja (te írtad)
NV - OpenGL_NV_mod -> NV onlyNem ez az első és gondolom nem az utolsó eset sem, hogy valamit kitalál az NVIDIA ami szép is, jó is, hasznos is lehet, de azt akarják, hogy csak nekik legyen jó, ezért zárt szabvány lesz, ami végülis senkinek sem jó igazán. Vagy felajánlják más számára is, de csak ha szépen kiperkálod érte a licenszdíjat, mint ahogyan az alaplapgyártók fizetnek az SLI-támgatásért.
(#25) Sinesol: Egy API-t nem lehet architektúrára optimalizálni.
-
#27
Laja333
őstag
cipofuzo87
#26
Laja333
őstag
válasz
cipofuzo87
#26
üzenetére
Na meg ugye az a baj, hogy nektek az FPS az egyetlen mértékegység. Ettől van jóval fontosabb tényező, amiben a Mantle jobb dx-nél. De ugye amíg az emberek csak az fpst ismerik, addig "nekem nem hozott semmit a mantle".
-
#24
#65675776
törölt tag
cipofuzo87
#23
#65675776
törölt tag
válasz
cipofuzo87
#23
üzenetére
Rajzolási parancsok számában mondjuk pl pont elérhető akár a 100x-os növekedés is.
-
#23
cipofuzo87
tag
cipofuzo87
tag
"Ennek megfelelően a ma megvásárolható hardverkonfigurációk nagyságrendekkel többre képesek, mint ami reálisan kihozható belőlük az OpenGL 4.5 vagy a DirectX 11 használatával."
A nagyságrendek azt jelentik, hogy 10x, 100x többre lennének képesek, de ez nem igaz, ez nagyon bántja a szememet a cikkben. Mantle-lel a teszteredmények szerint erős CPU-s gépen alig hoz valamit, szóval hagyjuk a hülyeséget. Tény, ha valami direkt rosszul van megcsinálva, tehát az alkalmazás nagyon sok draw callal dolgozik, akkor nagy az API overhead, de ezt már 10 éve tudja minden fejlesztő, éppen ezért kevéssel dolgoznak, végeredményben ugyanazt a látványt/fps-t lehet érni. Ettől függetlenül jó, hogy ez a réteg is fejlődik, de butaság azt várni, hogy 10x-100x javulás várható ezen a területen, mint ahogy nem is lett több mint 10%
-
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.
John Carmack maszk persze nem jo, hiszen tudjuk, hogy o mar nem ert semmihez, senki sem veszi ot komolyan ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Aranyos 
de nem történt ilyen.
Új hozzászólás Aktív témák
Hirdetés
- Formula-1
- Kerékpárosok, bringások ide!
- Android alkalmazások - szoftver kibeszélő topik
- Vélemény: nem úgy tűnik, de Lip-Bu Tan most menti meg az Intelt
- Luck Dragon: Asszociációs játék. :)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Samsung Galaxy S23 Ultra - non plus ultra
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Építő/felújító topik
- Zyxel NAS326
- További aktív témák...
- Bomba ár! HP EliteBook 840 G4 - i5-7GEN I 16GB I 256GB SSD I 14" FHD Touch I Cam I W10 I Garancia!
- Xiaomi Redmi Note 13 256GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! Gigabyte B550M R7 5700X 32GB DDR4 512GB SSD RX 7700 XT 12GB DeepCool CC560 Seasonic 650W
- Azonnali kézbesítés az év bármely pillanatában
- Telefon felvásárlás!! Xiaomi Redmi Note 13, Xiaomi Redmi Note 13 Pro, Xiaomi Redmi Note 13 Pro+
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest