- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen TV-t vegyek?
- Nikon DSLR topik
- Házimozi haladó szinten
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Amlogic S905, S912 processzoros készülékek
- Projektor topic
- Sony MILC fényképezőgépcsalád
- Dell notebook topic
- Hogy is néznek ki a gépeink?
Hirdetés
-
Robotkart irányított a majom a kínai Neuralink agyi chipjével
it A mindezt lehetővé tévő Neucybert a Neuralink kínai riválisa, a Beijing Xinzhida Neurotechnology fejlesztette ki.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Érkezőben a Poco M6 4G
ma 5G-s és 4G-s Pro modell már van, hamarosan lesz Poco M6 4G-s alapváltozat is.
Ú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
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Luck Dragon: Asszociációs játék. :)
- MG4 menetpróba
- Samsung Galaxy A54 - türelemjáték
- Nintendo Switch 2 vagy amit akartok (találgatós topik most még)
- Okos Otthon / Smart Home
- Milyen TV-t vegyek?
- Harold Halibut teszt
- Kerékpárosok, bringások ide!
- Yettel topik
- További aktív témák...
- PALIT RTX 3070 8GB GDDR6 GameRock OC Eladó! 125.000.-
- PowerColor RX 6700 XT 12GB GDDR6 RED DEVIL Eladó! 105.000.-
- eMag GARANCIA! ZOTAC Trinity RTX 3080 10GB OC GDDR6X Videokártya! BeszámítOK
- ZOTAC RTX 3070 8GB GDDR6 Twin Edge OC Eladó! 118.000.-
- BESZÁMÍTÁS! Gigabyte AORUS MASTER RX 6800XT 16GB GDDR6 videokártya garanciával hibátlan működéssel