- Minden fejlesztőnek kipróbálható a Microsoft DirectSR API
- Feltűnt a dél-koreai hitelesítésen a PlayStation VR2 PC adaptere
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- A manapság optimális specifikációkra törekszik az MSI QD-OLED monitorja
- Felpörög az asztali CPU-piac a következő pár hónapban
- Milyen videókártyát?
- Notebook hibák
- Projektor topic
- A manapság optimális specifikációkra törekszik az MSI QD-OLED monitorja
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
- Fejhallgató erősítő és DAC topik
- AMD GPU-k jövője - amit tudni vélünk
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Milyen asztali (teljes vagy fél-) gépet vegyek?
Hirdetés
-
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! :)
-
Feltűnt a dél-koreai hitelesítésen a PlayStation VR2 PC adaptere
ph A Sony közel lehet a starthoz, így a VR headsetjük hamarosan PC-vel is használható lesz.
-
Kávézaccból készülnek a Tecno Camon modellek
ma Pontosabban a bőr hatású hátlap, amit kizárólag napenergia felhasználásával, kemikáliák nélkül állítanak elő.
Ú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
- MSI RTX 4060 Ti Ventus 2X Black 16G OC újszerű VGA, gar 21 hó, Áfá-s számla
- Sapphire RX 5700 XT Nitro+ Special Edition 8gb Videokártya MPL csomagautomata az árban!!!
- Új - SAPPHIRE AMD Radeon RX 7900 XT Nitro+ Vapor-X Gaming OC 20GB GDDR6 - 2027ig bolti garancia
- Eladó GTX 950 2GB
- MSI Armor RX 590 8gb
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen