- Melyik tápegységet vegyem?
- Azonnali VGA-s kérdések órája
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Milyen notebookot vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen egeret válasszak?
- Gaming notebook topik
- Fél tucat Core Ultra CPU jöhet az asztali piacra
- Nem indul és mi a baja a gépemnek topik
- LG C4 tévé, a népszerű OLED-sorozat legfrissebb tagja
Hirdetés
-
Huawei Watch Fit 3 - zöldalma
ma Megnéztük, hogy tényleg okosóra lett-e a Huawei fitnesz karperecéből.
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
LG C4 tévé, a népszerű OLED-sorozat legfrissebb tagja
ph Leteszteltük az OLED evo paneles, 4K felbontású, mélynyomókkal is felszerelt, 65 hüvelykes televíziót.
Új hozzászólás Aktív témák
-
asaca
tag
Magyarul? Az nv megint kavar?
[ Szerkesztve ]
BF3: aSaca-Hun
-
Nem lenne erre megoldás, hogy a közjó érdekében az NV újraírná a szaros effektjeit? Úgy, hogy ne kelljen megint miatta szívnia másnak?
[ Szerkesztve ]
„A kerékpározás első szabálya, hogy szenvedned kell, és senki más nem teheti meg helyetted. Semmilyen számítógép vagy edző által kitalált program nem tudja elérni, hogy kevésbé fájjon.”
-
#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ó.
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
Elolvastam, mit értettem félre?
Azt sem ártana tisztázni, hogy a fejlesztők miért kényszerülnek hibás kódok megírására NV esetén, és AMD esetén miért nem. Nem vagyok szaki, szóval lehet félreértettem. Nem is akarom tagadni.[ Szerkesztve ]
„A kerékpározás első szabálya, hogy szenvedned kell, és senki más nem teheti meg helyetted. Semmilyen számítógép vagy edző által kitalált program nem tudja elérni, hogy kevésbé fájjon.”
-
#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...
[ Szerkesztve ]
-
-
válasz #52815360 #15 üzenetére
Mert azt hittem, hogy az Nvidia zárt effektjeinél probléma ez (mivel, hogy az AMD nem lett említve). Nem kellett volna írnom inkább semmit. Nem gondoltam volna, hogy ez egy többrétű probléma.
„A kerékpározás első szabálya, hogy szenvedned kell, és senki más nem teheti meg helyetted. Semmilyen számítógép vagy edző által kitalált program nem tudja elérni, hogy kevésbé fájjon.”
-
#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.
-
válasz #05364992 #17 üzenetére
Akkor igazából a programozóknak kellene ezeket a megoldásokat elhagyniuk? De gondolom mivel nincs előre definiált működés, és a kód helyessége sem látható előre akkor ez szinte lehetetlen lenne nem? Mi lehet a megoldás?
„A kerékpározás első szabálya, hogy szenvedned kell, és senki más nem teheti meg helyetted. Semmilyen számítógép vagy edző által kitalált program nem tudja elérni, hogy kevésbé fájjon.”
-
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.
Ryzen 9 5900X / 64GB@3.2XMP / Asus TUF 3080Ti / 2x1TB RAID0 NVMe SSD / AW2721D / HyperX Alloy Elite 2 / Razer Basilisk V3
-
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. -
Duck663
őstag
nTrollék ismét alkotnak! Gratulálok hozzá! Inkább a nem szabványos kódok szabványosítását kellene elősegíteniük, és nem azok átvitelét! De hát tudjuk a zavarosban lehet jól halászni és a zavart nTrollék igyekeznek minél jobban előidézni!
Igen-igen, még mindig Win7-et használok, és ha így haladunk még 2030-ban is így lesz.
-
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 : ) -
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.
Resistance Is Futile. You will be assimilated!
-
-
És mit eredményezne az, hogy ha a Vulkan API fejlesztői azt mondanák, hogy állj. Vége ezeknek a kódoknak. Nagyságrendileg ez mit eredményezhetne? Bár gondolom az Nvidia is támogatja őket a fejlesztés során, szóval elképzelhetetlen ez a forgatókönyv ugye?
„A kerékpározás első szabálya, hogy szenvedned kell, és senki más nem teheti meg helyetted. Semmilyen számítógép vagy edző által kitalált program nem tudja elérni, hogy kevésbé fájjon.”
-
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
-
Zanik
addikt
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?Origin/Steam: PaJKoS PSN: PaJKoS82
-
#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.)
-
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.Ryzen 9 5900X / 64GB@3.2XMP / Asus TUF 3080Ti / 2x1TB RAID0 NVMe SSD / AW2721D / HyperX Alloy Elite 2 / Razer Basilisk V3
-
É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?
„A kerékpározás első szabálya, hogy szenvedned kell, és senki más nem teheti meg helyetted. Semmilyen számítógép vagy edző által kitalált program nem tudja elérni, hogy kevésbé fájjon.”
-
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.
Resistance Is Futile. You will be assimilated!
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
válasz #85552128 #41 üzenetére
Ne zavarjatok össze, most akkor csak kilyukadunk a GW effektekhez amire én az első hülye hsz-em alapoztam?
„A kerékpározás első szabálya, hogy szenvedned kell, és senki más nem teheti meg helyetted. Semmilyen számítógép vagy edző által kitalált program nem tudja elérni, hogy kevésbé fájjon.”
-
Hiftu
senior tag
F*ck you nVidia. Már megint belesz*rtak a fazékba.
Ha tiszta lapról indulna az egész az nagyon fájna, mi?Tessék mondani, lehet itt hazudni? - Kaszt: Decker, Faj: Troll, Működési Terület: Prohardver
-
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
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.)
-
#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.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Melyik tápegységet vegyem?
- Diablo IV
- iPhone topik
- Büszke apukák és anyukák topikja
- DIGI Mobil
- Azonnali VGA-s kérdések órája
- Honor 90 - modellalkat
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Visszavonta az Intel és a Qualcomm Huawei-hez kiadott exportlicencét az USA
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- ASUS DUAL RTX 2080 SUPER
- BESZÁMÍTÁS! Bontatlan Sapphire PURE RX 7800 XT 16GB videokártyák számlával 3 év garanciával
- NVIDIA Dell RTX 2060 SUPER 8GB GDDR6
- MSI GeForce RTX 3060 8GB GDDR6 Ventus 2X OC /újszerű/gyári/csavarmatricás/ (BESZÁMÍTÁS)
- Gainward RTX 4070 Ghost 12 GB felbontott videókártya, 36 hó garancia, Áfá-s számla
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs