Új hozzászólás Aktív témák
-
válasz
#06658560
#95
üzenetére
Az, hogy minden rossz opengl kodot ujrahasznosithatnak a fejlesztok nem sokat fog segiteni a pc portok minosegen. Ugy altalaban gyakorlatilag azert fizetnek, hogy a konkurencia hardveren rosszabbul fussanak a jatekok (gameworks) es a fejlodesben is leginkabb visszatartjak a piacot.
-
válasz
sad_Vamp
#101
üzenetére
Engem nem zavar, ha Wine kell, de az igen, hogy a Wine még mindig csak dx9-ig megbízható. Próbálkoztam nem is olyan régen béta állapotban lévô dx11-es támogatást ígérô verziójával is, de felsült. Ahogy eljut a Wine arra a szintre, hogy futni is fognak vele a dx11-es játékok is, mégpedig stabilan, megbízhatóan, nem lesz többé szükségem Windows-ra. De a Wine még nem érte el ezt a szintet.
A legjobb meg az lesz, mikor már lesz Wine és Vulkan is - Androidon. Ez kb. 1-másfél év.
-
sad_Vamp
őstag
" A játék katalógus már most is jelentős (1800 játék) és dinamikusan bővül. "
Bevallom, nincs steamem, de ahogy én tudom/hallottam ezen játékok durván nagy százaléka csak WINE-n keresztül fut, vagy vlmi saját bullshit emulátorral, és amúgy rettentő kevés a NATíVAN linuxra(is) írt cím.
Amúgy nem hiszem, hogy akkora para lenne megkenni a 2(! úristen, 2!!!) grafkártya gyártót, hogy adjanak már külön extra támogatás 1-2 kiválasztott kártyára.... úgy szint kell pár támogatott alaplap és 2-3 jól megkent fejlesztő csapat kizárólagos exkluzivitással. Persze sok pénz kell hozzá, de nem kivitelezhetetlen... csak hosszútávó befektetés (viszonylag nagy rizikóval).
És igen, ilyen a mai világban valszeg nem jöhet és nem is fog létrejönni..... sajnos a játékiparban nem igazán történik más, mint hogy pakolgatják a ganét egyik kupacról a másikra és vice versa.
-
solasola
csendes tag
> Már más fórumokban is többször leírtam, hogy mennyivel jobb lenne, ha létezne egy INGYENES gamerOS amin csak a játékok futnának semmi más.
> (Valami olyasmi mint amit a valve is akart csinálni, csk éppen befektetett munkával, és aktuális APIkkal, meg mindennel ami a játékokhoz kell. Nem egy átskinezett linuxot, hanem egy teljesen új rendszert ...nem okvetlen linux alapokon.)
---
Egy teljesen új, gamer OS-t írni eszetlen méretű költség és generálisan nagyon rossz a logisztikája (pl.: ilyen képességű rendszerfejlesztők beszerzése). Azaz, hatalmas fejlesztési kockázatú vállalkozás, amit még egy giga-konszern is kétszer meggondolna. Nem véletlen, hogy a Valve is úgy döntött, hogy a platformját Linuxra építi, mert ez az egyetlen olyan általános célú OS, ami rendelkezik elfogadható szintű hw támogatással és nyitott annyira, hogy a Valve játék célokra jelentősen testre szabhassa. Relatíve könnyű hozzáértő rendszer és distro fejlesztőket találni hozzá mert nagy a fejlesztői közössége. Ugyanez mehetne még BSD alapon, de ott a hw támogatás már sokkal szűkebb és a fejlesztői közösség is sokkal vékonyabb.Egyébként a Valve szerintem nagyon jól halad a SteamOS-el és a Vulkan kihozása után 1-2 évvel már komoly ellenfele lehet a Windows-nak. Ahhoz képest mindenképpen, hogy szemre milyen keveset költöttek eddig rá (zéró reklám-kampány, zéró hw-subsidy, zéró exklúzív játék). A játék katalógus már most is jelentős (1800 játék) és dinamikusan bővül.
Ráadásul folyamatban van már a Linux-os grafikus stack megújulása is (Xorg -> Wayland), ami további teljesítmény növekedést eredményez majd. -
solasola
csendes tag
> A Frostbite mint Vulkan támogató biztos, hogy nem GLSL kódokat fog használni. HLSL 5.1, HLSL ext. és OpenCL C++ kódokban gondolkodnak. Hosszútávon főleg az utóbbiban. A legtöbb nagy fejlesztő ír majd saját SPIR-V fordítót és ennyi.
> A kicsik kiszámíthatatlanok. Ha engem kérdezel nekik a DX12 jobb. A Vulkan úgyis csak annak éri meg, akit érdekel az Android.Nem csak annak éri meg, akit érdekel az Android. Először is DX12 csak és kizárólag Win10-re lesz, (aminek a terjedése még nagyon erősen kérdéses), azaz DX12-vel nem tudsz fejleszteni Win7, Win8, Win8.1-re, amik jelenleg nagy részét teszik ki az installációknak.
Az már most nagyon erősen látszik, hogy az új Nintendo konzol rendelkezik majd Vulkan támogatással és nem lenne nagy meglepetés, ha a Sony is adna rá lehetőséget a Playstation-ön. Egyébként az Android-os támogatás már önmagában is elég erős érv a Vulkan mellett.
Azaz a Vulkan mindenképpen sokkal-sokkal jobban adja magát a multi-platformos fejlesztésre, mint a DX12. Inkább az a kérdés, hogy van-e annyira jó a DX12, hogy megérje vele külön vesződni a Vulkan mellett. Szerintem nem (de mondjuk játék fejlesztésben nem vagyok otthon)
-
Sir Ny
senior tag
válasz
#06658560
#95
üzenetére
pedig benne van a cikkben: "Ez egyértelműen léket jelent a rendszerben, amire Matías N. Goldberg, az Ogre3D motorprogramozója szinte azonnal felhívta a figyelmet."
És az utolsó része még kattintható is, egy twitter beszélgetés közepébe visz.Ha szerinted mégis fasza, akkor illene linket adnod, mondjuk az nv-tõl, vagy, egy nevesebb elemzõtõl.
-
sad_Vamp
őstag
"Jelentkezzen az a gamer aki nem win környezetet használ?"
hát én pl. nagyon ráuntam a win-re és ha csak lehet kerülöm.
Már más fórumokban is többször leírtam, hogy mennyivel jobb lenne, ha létezne egy INGYENES gamerOS amin csak a játékok futnának semmi más.
(Valami olyasmi mint amit a valve is akart csinálni, csk éppen befektetett munkával, és aktuális APIkkal, meg mindennel ami a játékokhoz kell. Nem egy átskinezett linuxot, hanem egy teljesen új rendszert ...nem okvetlen linux alapokon.)
Szerintem egyből meg lehetne nézni, hogy hány háztartásban lenne továbbra is "létszükséglet" a win...Még kivitelezhető is lenne! Miért ne lehetne valami csekély royalty-t elkérni egy játék árából (persze nem annyit mint konzoloknál) hogy a gamerOS gyártója életben maradhasson, fejlődjön és legyen support.
-
do3om
addikt
Elég érdekes szemléletek vannak (ph nagyban rásegít).
Jelentkezzen az a gamer aki nem win környezetet használ?
Ki az aki szerint az AMD az uralkodó a piac jelentős része felett és ezért őt kel figyelembe venni?
Ha egy kisebbség folyton saját megoldásokkal áll elő (sokszor nem követi az elterjedd szabványt) de nem tesz semmit annak érdekében hogy el is érjen vele valamit csak dobálózik a marketingszavakkal olyankor ki kavarja a szart? -
Raysen623
addikt
Akkor most megkérdezem: ki fejleszti a Vulkan API-t? Khronos group vagy NV? Ha az előbbi, akkor miért nem sz@rják le az NV okoskodását és követelik meg ahogyan az MS is?! Megint szétgányolnak mindent, aztán nem térünk majd magunkhoz adott játék erőforrás igényeit látva...
-
RyanGiggs
őstag
Inkább használok egy "félkész" Win-t (amiből én még egyáltalán nem érzékeltem semmit), mint egy undorító csempés ocsmányságot. De ízlések és pofonok! Én nem érzékeltem semmit az MS erőszakosságából, mivel nyáron már frissítettem. Első látásra "beleszerettem", miután belegondoltam, hogy a 8-as milyen kinézetű. Tehát lassan fél éve használom a 10-est, és eddig még semmi problémám nem volt vele. Se fagyás, se kékhalál, olyan se volt hogy nem indult el egy játék... Driver problémám se volt, sőt meglepődve tapasztaltam, hogy a 9 éves hangkarimhoz még a Creative csinált friss illesztőprogramot.
-
lenox
veterán
Melyik kerdesre valaszoltal igennel a negybol?
arra is megadja az engedélyt, hogy egy specifikus kiterjesztéssel ez a kód valós időben legyen fordítható, vagyis akár a magas szintű shader nyelv is szállítható az adott alkalmazással.
Hogyan tudja barmilyen api megmondani, hogy a kodot, amit odaadsz neki azt valos (futasi amugy leginkabb, de mindegy) idoben forditottak, vagy nem? Szerintem sehonnan. Akkor pedig az egesz felvetesnek mi ertelme van?
-
válasz
RyanGiggs
#84
üzenetére
Én a 8.1-et szerettem, de ezt a 10-et nem nagyon veszi be a gyomrom, a Microsoft erőszakoskodását meg főleg nem.
Ez így ebben a formában a lehető legrosszabb, ami csak lehet. Bugos szar, és ha ez még nem lenne elég, mellette még erőltetik is az emberekre, ahelyett, hogy inkább a javításával foglalkoznának.
Sir Ny: Látom a színvonal megvan...
Szaby59: világos. De a DX12 csak Win10-en fut, magyarán az abban írt játékok kötik az embert a Win10 használatához.
Nyilván akinek beveszi a gyomra egy ilyen félkész vackot, azt nem zavarja a dolog, de mást meg annál inkább. -
#85552128
törölt tag
Volt már róla szó, hogy Windowsból is a 10-es lesz az "ajánlott" a WDDM 2 extrái miatt még Vulkanhoz is, de ettől még elfutna W7/8-on is.
(#81) Abu85: ez mondjuk elég nyilvánvaló, hogy nem a PC-sek miatt csinálták, de a Mantle meg egy esetleges más API mellett (Vulkan ugye...) nem mehettek el szó nélkül ők sem úgyhogy megcsinálták PC-re is, legalább a W10-nek is lesz +1 előnye...
-
válasz
RyanGiggs
#80
üzenetére
Pl. az, hogy a DX12 Win-only, sőt, azon belül is Win 10-only.
Ezért is lenne jó egy versenyképes alternatíva, ami nem csak a legújabb Winfoson fut el, hanem régebbieken is, plusz Mac-en és Linuxon is.
Pl. aki Win7-et, vagy 8-at, vagy Mac-et vagy Linuxot használ, és a háta közepére nem kívánja a Win10-et, az nem lenne ily módon rákényszerítve a használatára. -
Abu85
HÁZIGAZDA
válasz
#85552128
#79
üzenetére
Az biztos, hogy átgondoltabb a Vulkan, mert ezt nem az Xbox One-hoz tervezték, ahogy a DX12-t. Nincsenek benne tulajdonképpen értelmetlen követelmények, mert az az Xbox One-nak jó. Emiatt nem csak a GCN-en lehet például hatékony az aszinkron compute, hanem Kepleren, Maxwellen és Gen9 architektúrán is. Azért ez elég komoly előny. Az OpenCL C++ kódok használhatósága pedig a másik nagy dolog benne. Jelen formában semmi kétség afelől, hogy a Vulkan a jobb API, mind átgondoltságban, mind a fontos fícsőrök tekintetében. Persze afelől sincs kétség, hogy a Microsoft a DX12-t az Xbox One-hoz tervezte és ahhoz végtére is jó.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#85552128
törölt tag
Te miről beszélsz mond már ? Elkapott a zöldhate ? Semmi köze a fakeworkshoz, meg a GPU-k dokumentálásához meg úgy egyáltalán semmihez amit állítasz... Benne van a cikkben, hogy egy lehetőség lesz. (Ha ezt az AMD csinálta volna már menne a magasztalás, hogy poor AMD ott segít a kicsi fejlesztőknek ahol csak tud...) A fejlesztő ettől az elképzeléseit ugyanúgy megvalósíthatja szabványos formában, sőt hosszú távon csakis így lesz érdemes.
"Itt pedig arra próbálják késztetni a fejlesztőket, akik persze roppant kényelmesek, hogy a korábban megírt amúgy sok esetben nagyon tré és nem szabványos kódokat átvigyék az új API-ba, és egy nagy katyvasz legyen az egészből, mert ezzel a saját gyengeségeiket elfedhetik. "
Nem, nem késztetnek senkit, de ha "csak szabványos GLSL kódokból történhet meg, amelyből kis túlzással kevés van a fejlesztőknél." akkor akár az is lehet, hogy más lehetőség híján a teljes újraírás helyett a legtöbb fejlesztő inkább skippeli az egész Vulkan sztorit mert Windowsra/Xboxra úgyis ott lesz a DX12 amivel a piac elég nagy része lefedhető - ez nyilván nagyon segítené a Vulkan terjedését
Az meg ugye megvan, hogy a Khronos Group elnöke egyben alelnök az nVidiánál is ? Meg úgy még jó pár más kisebb nagyobb/gyártó tagja a KG-nak. Tehát a "szabvány" kidolgozásában ők is legalább annyira részt vettek, ez nem olyan mint az MS a DX12-vel, itt azért több gyártónak van beleszólása a dolgokba és ezért akár egy jobb/átgondoltabb API is lehet...
-
Duck663
őstag
válasz
#85552128
#23
üzenetére
Épp ez az, hogy semmit se akarjanak a fejlesztők helyett, hanem hagyják őket dolgozni, hagyják hogy a fejlesztők az elképzeléseiket szabadon megvalósítsák. SZABVÁNYOS FORMÁBAN!!! De ezt minden áron és eszközzel igyekeznek megakadályozni. Ezért van FakeWorks, ezért nincsenek dokumentálva a GPU-ik, és ez a kiegészítés is ezért készül.
Nézzük már meg mennyit fejlődtek a grafikus vezérlők (már amelyik), és amennyit a játékok! Évekkel ezelőtt már bemutattak számtalan techdemót, amely a fizika szerves integrálását ígérte, ezek a játékok hol vannak??? Ahelyett, hogy az efféle fejlesztéseket segítenék elő, az információ korlátozásával igyekeznek akadályozni mindenkit. Itt pedig arra próbálják késztetni a fejlesztőket, akik persze roppant kényelmesek, hogy a korábban megírt amúgy sok esetben nagyon tré és nem szabványos kódokat átvigyék az új API-ba, és egy nagy katyvasz legyen az egészből, mert ezzel a saját gyengeségeiket elfedhetik. Mi ez ha nem trollkodás???
(#25) Peak: Gondold már végig mit írtam, és a cikket is olvasd el még egyszer.
(#26) xRagna: Rád is vonatkozik! Mi történik és mi lesz ennek a következménye! Miért ilyen nehéz ez??? Egyébként igen, mert ahol áthaladni tilos, ott igen ott piros fények, jobb esetben sorompók is vannak!
-
Igen, és ez a Vulkan API baja, hogy van erre lehetőség:
Megtudtuk, hogy a Vulkan SDK alapból tartalmaz egy olyan nyílt forráskódú fordítót, amely a szabványos GLSL kódokat SPIR-V-re fordítja, de a fejlesztők akár saját fordítót is írhatnak, amely persze más shader nyelvről is biztosíthatja a szükséges kódot. Ez eddig gyakorlatilag ismert volt, de érdekes fejlemény, hogy az API ugyan állandóan megköveteli a SPIR-V kódot, viszont arra is megadja az engedélyt, hogy egy specifikus kiterjesztéssel ez a kód valós időben legyen fordítható, vagyis akár a magas szintű shader nyelv is szállítható az adott alkalmazással.
A vastag betűs rész konkrétan a lék. Nem az, hogy valaki írt hozzá saját fordítót. A lehetőséggel van probléma. Csak valahogy itt az elején sikerült sátánt kiáltani, pedig ez tök független az NV-től, pontosabban annyi köze van hozzá, hogy ők használták ki először ezt a kiskaput.
-
lenox
veterán
-
A Vulkan egyik lényege az lenne, hogy csak szabványos kódot fogad el, mert az OpenGL jól láthatóan ebbe bukott bele. Erre jön egy cucc, ami ezt figyelmen kívül hagyja. S ez csak a kezdet, ha esetleg elkezdik gyártani mások is ilyesmiket, akkor ugyanúgy széttöredezik a vulkan is, aztán hello újra opengl fail.
-
lenox
veterán
Igen ez az OpenGL-nél is látszik, hogy így lesz.
Az opengl-nel is hogy lesz?
Csak egy driveres bugfix kelj hozzá, hogy a program ne induljon el.
Es ez a tobbi komponensre is igaz, hogy ha hibasan hasznaltad, de egy bug miatt jol futott, az egy bugfix utan esetleg nem lesz jo. Ki nem szarja le? Mi koze ennek a vulkan apihoz? Semmi...
De mostantól biztos, hogy az lesz, hogy a fejlesztők nem fognak hibás kódot írni csak azért mert a meghajtó azt is elfogadja, mivel ebben a pillanatban mindenki megvilágosult.
Mi ez a hulyeseg?
-
Abu85
HÁZIGAZDA
Igen ez az OpenGL-nél is látszik, hogy így lett. Csak egy driveres bugfix kell hozzá, hogy a program ne induljon el. De mostantól biztos, hogy az lesz, hogy a fejlesztők nem fognak hibás kódot írni csak azért mert a meghajtó azt is elfogadja, mivel ebben a pillanatban mindenki megvilágosult.
-
-
Abu85
HÁZIGAZDA
Nem. Az a baj, hogy az OpenGL fordításra vonatkozó problémáit ezzel a koncepcióval viszik magukkal a Vulkan API-ba, amitől a programfuttatás kis túlzással csak a szerencsén fog múlni, hiszen ki tudja garantálni, hogy mikortól mond a driveres fordító nemet az addig elfogadott hibás kódra.
Most van például az NV-nek egy hasonló ügye a 360-as meghajtóval. Egyszerűen befoltoztak egy bugot, és egy rakás program nem indul el. Hiába mondják, hogy a 360-as meghajtó működik jól, a hibás program a meghajtóban lévő bug nélkül nem fut. Ergo vissza kell tenni ezt a befoltozott bugot. -
-
#61
Abu85
HÁZIGAZDA
Meteorhead
#56
Abu85
HÁZIGAZDA
válasz
Meteorhead
#56
üzenetére
Jaja. Az Intelt ezért imádom amúgy. Simám visszabasszák a bugrepót, ha nem náluk van a hiba: "Tanulj meg programozni vazze!" ... Zseniálisak.
(#60) Kopi31415: Természetesen a szabványos kód. Ez az egyetlen dolog, ami életben tarthat egy API-t.
Jön egy meghajtó, ami befoltoz egy hibát, és a program máris működésképtelen. Aztán kihez fordulsz a javításért? Mi van, ha a fejlesztőt már rég felszámolták?
Az egyik leghíresebb hiba az OpenGL-ben a kiterjesztések beolvasása volt. Az AMD és az NV belefutott, és mindkét cégnél nagyjából háromnegyed évig működésképtelen volt egy rakás OpenGL-es progi, mert több kiterjesztéssel tért vissza a driver, mint amennyit a program be tudott olvasni.
-
Abu85
HÁZIGAZDA
A Vulkan API kiterjesztésében nincs fordító. A Vulkan SDK-ban van egy.
Ha valaki saját fordítót ír, attól a kódgenerálás még szabványos lesz. Vagy ha nem, akkor is minden meghajtó rossz kódot fog kapni, tehát gyorsan kiderül, hogy baj van. A fogyasztás így mindenképpen szabványosított.A driverbe épített fordító azért rossz, mert már a SPIR-V kódgenerálás is szét lesz választva a gyártók között. Ehhez persze kiterjesztést kell használni a Vulkanhoz, tehát maga az API önmagában ezt nem engedi meg, hála az égnek.
Az NV valószínűleg nem akar rossz dolgot, csak rosszhoz fog vezetni. Az ilyen lékek miatt van az az OpenGL-ben, hogy a rosszul megírt kód egy új meghajtóval nem indul el. Aztán csak nézünk, hogy a meghajtó csak javított egy hibát, amitől végtére is hibás kód futott.
-
#57
.LnB
titán
Meteorhead
#56
.LnB
titán
válasz
Meteorhead
#56
üzenetére
Jó csak a végfelhasználó meg mit fog ebből tapasztalni és leszűrni? "Ezzel a xar VGA-val meg villog a textúra, veszek inkább a másik gyártótól mert azzal nem"...
-
#56
Meteorhead
aktív tag
Abu85
#48
Meteorhead
aktív tag
Nekem sem tetszik hogy van ilyen, de nincs ezzel akkora baj, mint amennyire itt be van állítva (szerintem).
"De mi van, ha csak a kiterjesztésre írja meg a programot?" Akkor az éhen fog halni. Láttunk már gyenge konzol portokat, amiket nem vett be a PC-s piac gyomra, és Oszkár bácsi csak nem jött. Ha valaki gyenge OGL portot csinál Vulkanra, annak a játékát ugyanígy a kutya se fogja megvenni, és első napon elönti a flame dömping a fórumokat, hogy "ekkora xart hogy lehet kiadni", stb.
Intel eddig is nagyon szimpatikusan nagy ívben tett a játékok foltozására, ha azok helytelenül működtek a hardverén. Nincsenek kétségeim, hogy Intel fordítót és drivert jókat tud írni. Nem hibátlanok, de nagyon jók. Ha valakinek a játékában villognak a textúrák, az valószínűleg azért van, mert xarul használják az API-t. Félelmetes milyen hibákat utókezelnek driverből a pirosaknál és a zöldeknél. Intel szerencsére tesz rá magasról. Ha valaki CSAK ilyen kiterjesztésre fogja Vulkan idejében megírni a programját, az lesheti, hogy a konkurens gyártók utólag megpróbálják kezelni az inkompetenciáját meghajtóból. Késztetést sem fognak érezni, mert még csak nem is illenék támogatni ilyen kiterjesztést. Biztosan nem rajtuk fog csattani az ostor.
-
lenox
veterán
En azt a reszet nem ertem, hogy miert nem mindegy, hogy a Vulkan api kiterjeszteseben van a fordito, vagy az nv driverben. Mert ha jol ertem arra nem mondanal semmit, ha valaki egy zsebebol elohuzott forditoval forditana glsl-bol spir-v-t. Ellenben ha Vulkan kiterjesztesbe rakja, akkor baj? Nem ertem, mi a kulonbseg, hogy gyartospecifikus driverben van a fordito, vagy a vulkan api gyartospecifikus kiterjeszteseben, nem mindegy? Mindket esetben csak az adott gyarto hw/sw kornyezeteben fog ugy futni, ahogy ok akarjak, a tobbi gyartonel meg ahogy azok implementaljak/supportaljak.
-
általában három dolog miatt szoktunk gányolni:
1, idő. valamit megdrótozzunk, hogy menjen, aszt elfelejtjük, hogy csak meg van drótozva, és úgymarad, mert sosem lesz idő rendesen megcsinálni;
2, tudás. egész egyszerűen nem tudjuk szabványosan megcsinálni, hekkelni kell;
3, tudás. ha meg tudom írni úgy, hogy gyorsabb legyen, és a hardware/framework/környezet megeszi, akkor kit érdekel, hogy nem teljesen szabványos?
-
.LnB
titán
válasz
#85552128
#50
üzenetére
Gondolom ugyan azért építődik be a GW effekt egy játékba, mint amiért ez a kiskapu nyitva felejtődött a Vulcan API-ban.
(#52) Szaby59 A francba.. [link]
(#53) xRagna Naugye!
Na kiszállok az eszmecseréből, mert úgy se értek hozzá. De köszi a segítséget, hogy megpróbáltatok felvilágosítani.
-
#85552128
törölt tag
A probléma nem az opcionálisan választható kiegészítő effektekkel van, hanem azzal ha valaki hajlandó ezeket ilyen feltételek mellett beépíteni - a fejlesztők igénytelensége és a kiadók kapzsisága a probléma gyökere...
A GPUOpen meg hacsak nem ad egy pár milliós kezdőtőkét is az effektek mellé - ahogy feltehetőleg az nVidia promóban való részvétel is tesz - nem fog megoldani semmit, mert eddig sem azokért a "gyönyörű" effektekért sóvárogtak a fejlesztők, hanem a zsebpénzért (a kiadók) amit mellé adnak. Az, hogy ehhez be kell rakniuk valami "alibi" nVidia cuccot megint csak a marketing része.
-
#05364992
törölt tag
Igazából itt az a baj, hogy a szándék még talán jó is, de tudjuk mivel van kikövezve a pokol felé vezető út.
(pixeljetstream = Christoph Kubisch, ő írta ezt a blogbejegyzést, ahonnan emlékeim szerint a cikkben említett infó is ered. Az "NVIDIA’s Vulkan Driver" rész a lényeg itt most.)
-
#48
Abu85
HÁZIGAZDA
Meteorhead
#46
Abu85
HÁZIGAZDA
válasz
Meteorhead
#46
üzenetére
Itt a lehetőség megléte a probléma. Egyszer már eljátszották azt az OpenGL-lel, hogy ezt meg azt is elfogadjuk, holott nem szabványos. Ilyennek a lehetőségét sem szabadna biztosítani Vulkan alatt.
Ha valaki egyébként az SDK-ban lévő fordítót használja a SPIR-V-re, akkor eleve szükségtelen dupla munkát csinálnia. De mi van, ha csak a kiterjesztésre írja meg a programot?(#41) Szaby59: Nem akartam felhozni a GameWorksöt, de örülök, hogy látod a problémát.
-
#46
Meteorhead
aktív tag
Meteorhead
aktív tag
Csak én nem értem a problémát?
Vulkan egy nagyon szép tiszta API. Valaki írt hozzá egy kiterjesztést (most tök mindegy, hogy ki), amivel a régi kódok a régi betegségekkel átvihetők a szép és újra. Senki nem tart pisztolyt a fejemhez, hogy használjam ezt a kiterjesztést. Ha valaki mégis megteszi, akkor nekem, mint egy másik Vulkan implementációnak semmi kötelezettségem nincs arra, hogy támogassam a kiterjesztést.
Ha valaki el akarja kerülni, hogy a shader kódbázisát portolja, akkor megteheti ezt egy gyártó hardverén. A többi nem hajlandó a régit átmenteni az újba. Aki ilyen feltételek mellett kiad egy komoly projektet ezeken az alapokon, az vállalja a megszorításokat.
Ennyi.
DX-ben is vannak gyártó-specifikus kiterjesztések, Vulkanban is lesznek. Nincs ezzel semmi gond. Mindenki olyan szemetet pakol bele, amilyet akar. Senki sem emelte fel a hangját az OGL over Vulkan projekt kapcsán, ami egy OpenGL implementáció, ami Vulkant használ a motorháztető alatt. Picit hasonlít az ANGLE projektre, csak DX helyett Vulkan van alatta. Az is egy lélegeztető gépe a réginek, és senki nem fortyog azon.
-
Abu85
HÁZIGAZDA
A Frostbite mint Vulkan támogató biztos, hogy nem GLSL kódokat fog használni. HLSL 5.1, HLSL ext. és OpenCL C++ kódokban gondolkodnak. Hosszútávon főleg az utóbbiban. A legtöbb nagy fejlesztő ír majd saját SPIR-V fordítót és ennyi.
A kicsik kiszámíthatatlanok. Ha engem kérdezel nekik a DX12 jobb. A Vulkan úgyis csak annak éri meg, akit érdekel az Android.A GPUOpen azt a célt szolgálja, hogy például egy God Rays effekt a maximum minőségen ne járjon -30-40 fps mínusszal, úgy, hogy közben nem is látod a különbséget a minimum minőséghez viszonyítva. Szóval az arra van, hogy a fejlesztőknek ne kelljen mesterségesen magas gépigénnyel szállítani egy PC-s portot.
-
rudi
nagyúr
Azt eredményezheti, hogy a fejlesztőknek át kell nézniük a kódjaikat, visszamenőleg helyettesíteniük kell a nem szabványos részeket tehát csillió extra munka merülhet fel rég kiadott játékoknál is. Aminek könnyen lehet az a vége, hogy OK, akkor hagyjuk inkább a Vulkant és nyomuljunk mégis inkább DirectX-ben, ami sokkal sztriktebb. Ezt meg a Vulkan API fejlesztői nem igazán akarják.
-
.LnB
titán
És ez eredményezheti azt összegezve, hogy a Vulcan Api mégsem hozza meg a tőle várt megváltást? Értem, hogy a programozókon múlik. De mi lesz a tendencia? Megemberelik magukat? Vagy nem?
Esetleg, és most lehet, hogy megint a hozzá nem értésemet fogom kinyilvánítani. De az AMD féle GPUOpen kezdeményezés, nem szüntetheti meg ezeket a kódokat, a fejlesztők eszmecseréje során. Vagy az nem ezeknek a kódoknak a megvitatására van?
-
Peak
addikt
válasz
#06658560
#34
üzenetére
De gondolom azért az világos, hogy ezekért az ordító szarvashibákért, amit elkövetett az adott cég nem a driver gyártókat kell blamálni, nem? Legalábbis én józan ésszel erre tippelnék.
Az ilyen cégek helyében azt hiszem elgondolkodnék azon, hogy a súlyos pénzeket, amiket kifizettek, az megérte vagy sem. -
#05364992
törölt tag
Ahogy mondod, a programozóknak kellene leszokniuk az ilyen megoldásokról, de ez nem következik be addig, amíg erre nem vagyunk kényszerítve valamilyen módon. A D3D11-hez csinált az MS egy frankó kis hibakeresési réteget, amit ha fejlesztés közben bekapcsolunk, akkor az ilyen esetekben azonnal ránk üvölt, hagyja ugyan a programot tovább futni, de egyértelműen jelzi hogy gond van. Szvsz ez a megoldás az ilyen gondokat csökkenti jelentősen, ugyan fizikailag nem vagyunk akadályozva abban hogy hülyeséget csináljunk, de azért annyi szakmai önérzete szokott lenni mindenkinek, hogy olyan trógerolt vackot nem ad ki a kezéből, ami ugyan látszólag jól működik, de tudja róla hogy a háttérben meg ontja a hibákat. (Bár azt hagyjuk meg, hogy a nappali munkában webfejlesztőként már láttam "csodákat", ha a vezetésnek sikerül mentálisan leépíteni egy fejlesztőt annyira, hogy tegyen mindenre magasról, ott nincs mit tenni.) A másik dolog amit az MS ilyen téren "jobban" csinál, az az hogy a shaderes dolgokon is erősebben rajta van a kezük, amit az MS shader fordítója lefordít, annak mennie kell mindenhol, az helyes kód. (Mellékes megjegyzés: azért ez sem tökéletes, pont a 600-as szériás geforce-ok azok, amikre emlékszem hogy az alábbi pszeudo kódra is képesek voltak negatív értéket számítani: a = ha b < 0 akkor 0 különben b; A megoldás anno az volt hogy nem azt vizsgáltuk hogy b < 0, hanem hogy b < valami marha pici pozitív szám, így már működött az egész.)
-
De egy játékfejlesztőnek nem az az érdeke, hogy minél több hardveren hibamentesen fusson a program? Meg hogy könnyű legyen portolni konzolról PC-re?
Ha 2016-ban fejleszt valaki egy új játékot, akkor mi érdeke, hogy egy 2011-ben rosszul megírt GLSL kódot le tudjon fordítani SPIR-V-re?
Tényleg ennyire lusták lennének? Tényleg nem veszik észre, hogy ha maguk mögött hagynák a múlt hibáit, akkor sokkal könnyebb lenne majd pár év múlva jól megírt kódokat használni az új API-khoz? -
#30
kriszpontaz
veterán
kriszpontaz
veterán
Legalább olyan vasököllel kellene fogni a Vulkan API-t is mint a DX12-t a Microsoft.
Nem kellene már az elején engedni hogy elkurvuljanak. Ez az első kiterjesztés,, aztán majd jön a többi milliószámra és lesz egy új OpenGL megint, és a kutya nem fogja használni.
Kezdjenek mindent tiszta lappal és kezdjenek a béna fejlesztők megtanulni normálisan programozni. A DX12 sem kompatibilis visszafelé, nem is értem miért érdekes az hogy a régebbi kódok nem fognak futni a Vulkan API-n. Írják újra, szedjék rendbe szabványosan. -
Abu85
HÁZIGAZDA
Akkora gond ebből nem lesz, mert a többségnek eleve nincs GLSL kódja. Leginkább az Aspyr érintett, mert ők azok, akik natívan dolgoznak OpenGL-re.
Itt a probléma azzal van, hogy lesz egy kiterjesztés, ami szétgányolja a Vulkan API-t.
A legtöbb fejlesztő MS HLSL, AMD HLSL ext. vagy Sony PSSL kódot fog SPIR-V-re fordítani. Ezekre épül sok mai játék kódja. -
-
rudi
nagyúr
Könnyen lehet, hogy ezeknek a nem szabványos kódoknak a megszületése még arra az időre datálható, amikor az NVIDIA a saját jól képzett, fizetett kódereit küldte ki a nagyobb projektekben besegíteni. Nekik lehetett olyan szintű visszahatásuk egy-egy "hibás" kódra, hogy a drivert csináló NV-s csapat átengedje a rostán a működését. És mivel ezt évekig csinálták, bőséggel van a mai motorokban ilyen kód, ezeket le "tisztalapozni" nem lehet egy varázsütéssel, még ha az iparágnak jót is tenne a reboot. Lényegében pont ezért lehet nagyon ritkán sikeres újrakezdést csinálni akármilyen technikai területen.
-
#22
flashpointer
őstag
flashpointer
őstag
Vegul is talaltak egy megoldast a problemara : )
Pont mint a repulesiranyito rendszer az egyik repteren ami szarul volt megirva igy kb ket honap utan mindig osszeomlott. Azt ugy javitottak hogy beleirtak a kezikonyvebe hogy havonta ujra kell inditani : ) -
jerry311
nagyúr
Kihagytál egy részt.
Vannak a szabványban definiált módszerek, függvényhívások, stb., azoknak a kimenetele, működése dokumentált és mindig ugyanazt csinálja.
És vannak az olyan esetek, amikor a szabvány szerint egy adott függvény, utasítás, stb. nem használható, mert nem arra tervezték, nincs dokumentálva... Na ezek a programkódok vagy futnak és jó eredményt adnak, futnak és rossz eredményt adnak, nem futnak, attól függően milyen hardver, driver, stb van a gépben. A szabványnak megfelelő kódok viszont futnak mindenhol. Kis túlzással persze, mert hibák így is lehetnek, de ha a kód szabványos, a fordító szabványos, és mégsem úgy működik, ahogy le van írva, akkor nem a kódban van a hiba. -
Peak
addikt
válasz
#05364992
#17
üzenetére
Magyarul az eddig eléggé megengedő és hibatűrő nVidia meghajtó mostantól nem hajlandó megengedő és hibatűrő lenni a pongyola, rossz és slendrián módon összegányolt, szakmaiságot nélkülöző fércművekkel szemben, amit a hátulgombolós amatőrök firkálnak össze az IDE-kben. GG.
-
#05364992
törölt tag
Nem kényszerül, kényszer nélkül ír ilyen kódot. A programozás egy egyszerű folyamat ilyen téren, megírjuk egy funkcióhoz a kódot, lefordítjuk, kipróbáljuk, aztán ha működik és azt csinálja amit akartunk akkor konstatáljuk hogy az a kód jó. Vannak viszont olyan esetek mikor bizonyos hívások bizonyos környezetben a szabvány szerint nem definiált működéshez vezetnek (gyk. ha a programozó meghív egy függvényt egy adott környezetben, arra a hivatalos szabvány azt mondja, hogy gőze nincs mi fog történni, mert nem tudják megmondani a gyakorlatban mihez fog ez vezetni). A probléma sok esetben abból következik hogy az nV driverek ilyen esetekben hibátlanul működnek tovább, és azt is csinálják amikor a programozó számít, hiába elvi hibás a szabvány szerint a kód.
-
#85552128
törölt tag
"Ez abból a szempontból jó, hogy a fejlesztőknek nem kell úgymond szabványosítani több tízezer sorból álló GLSL kódbázist."
Általánosságban volt szó a kódról, függetlenül attól, hogy milyen HW-ról van szó. Az nVidia pedig kínál egy ilyen "megoldást" a fejlesztőknek. Nem kéne mindenbe rögtön AMD vs. nV-t látni...
Mondjuk ez az egész Vulkan arról szólt volna, hogy tiszta lappal indulnak, nem értem miért van szükség erre, lassan OpenGL lesz ez is csak más néven...
-
Sinesol
veterán
Nézőpont kérdése, hogy kavarás-e vagy hasznos.
Ha nincs ez a kiterjesztés, akkor nagyon sok mostani progi nem fog futni Vulkan alatt.
Annyiban viszont probléma lehet hosszútávon, hogy a programozók továbbra is lusták lesznek és lehet hogy továbbra sem szabvány szerint készítik el a dolgaikat, mert ugye ezzel a kiterjesztéssel az is jó lesz.Szerény véleményem szerint jóval nagyobb baj, ha hirtelen nem futnak a programok, szóval inkább hasznos.
-
#16939776
törölt tag
Vagy most jelzi a játékfejlesztőnek hogy x.y verziótól nem fog működni a játéka, vagy megy a drótozás össze vissza, és nem lehet majd látni, hogy milyen egyéb grafikai/teljesítmény béli hibákat okozott az "elnézés".
A fordítónál is meg lehet fogni a hibát, és ugyan úgy javítani kellene a fejlesztőnek, mintha az API dobná ki a kódot, csak gyorsabb lenne az indikáció.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ezek a forditott kodok gondolom csak geforce-on fognak ertekelhetoen futni...
Új hozzászólás Aktív témák
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Androidos tablet topic
- Formula-1
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- One otthoni szolgáltatások (TV, internet, telefon)
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- NIOH
- A fociról könnyedén, egy baráti társaságban
- Nintendo Switch 2
- Milyen okostelefont vegyek?
- További aktív témák...
- GYÖNYÖRŰ iPhone 12 Pro 128GB Pacific Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS2919
- Részletre elviheted akár 365 napra Bankmentes , azonnal elérhető Dell GAMER laptop G15 5530 165Hz
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 14 Pro 256GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3351
- BESZÁMÍTÁS! ASUS H510M i9 10900KF 32GB DDR4 512GB SSD RTX 3080 10GB RAMPAGE Shiva A-Data 750W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest