- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen videókártyát?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- Androidos tablet topic
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- VR topik (Oculus Rift, stb.)
- OLED TV topic
- Milyen egeret válasszak?
- 3D nyomtatás
Hirdetés
-
A személyre szabott reklám lehet a streaming következő slágere
it A jobb célzott hirdetések érdekében adatplatformot indít a Warner Bros Discovery.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
ph A megfizethető, szivacsokkal jól megpakolt modell ötfajta kapcsolóval és kétféle színösszeállítással/kupakprofillal szerezhető be.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Gondolod mások meg vannak vele elégedve? Mert a Mantle elérés igénylése majdnem az összes embedded és workstation szoftvercégtől nem ezt vetíti előre.
Mindenkinek baja van ezzel csak van aki nem ír róla blogot. Az embedded és workstation ISV-k helyzete annyiban könnyebb, hogy portolnak Mantle-re és FirePróhoz kötik a szoftvert. Nem történik igazán semmi. A konzumer piacon ennyire merev hozzáállást nem engedhet meg magának egy játékfejlesztő. Nekik azért ott van egy még egy rakás nem AMD júzer.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az ARM, az Imagination, a Vivante, a Qualcomm és a többiekre gondolt. Alapvetően az OpenGL ES 2.0 egy teljes fejetlenség. Az ES 3.0 javított, de a drivergondok megmaradtak.
Az cél lenne, hogy legyen egy teljesen modern, letisztult és nyílt forráskódú grafikus API. Az a kérdés, hogy ki kezdi el a fejlesztést, csatlakoznak-e hozzá, stb. Azért anyagilag egyedül ezt senki sem szeretné bevállalni, tehát valami konzorcium féleség is kellene közös tőkével, kezdetektől fogva a szabványosításra törekedve. Jelenleg az a helyzet, hogy mindenki a másikra vár és ezért nem történik semmi.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Úgy fogalmaznék, hogy a Mantle koncepciójának mintájára, de nem a strukturális működésének mintájára. Ilyen a DX12 is. És elsősorban azért mert ezt eleve játékfejlesztők dolgozták ki.
Az alacsony szintű elérésnél nem kell olyan dolgokra gondolni, amit évek óta nem tesznek meg a fejlesztők. Aki dolgozott konzolra (Xbox 360, PS3, PS4, stb.) annak teljesen ismerős lesz az egész. Ez lényegében csak azt jelenti, hogy a programod működésének minden részletével tisztában leszel. Ez képessé teheti az adott stúdiót a gyártók segítsége nélkül is AAA kategóriás játékok kifejlesztésére. Még drivert sem kell igényelned a startra. Ez nem jelent gépi szinthez közeli kódolást, sőt a programozás szintje igazából nem változik, csak megkapod a teljesítmény felett a kontrollt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#14
üzenetére
Publikusan ezt lehet megosztani: [link]
Majd később lesznek hivatalos bejelentések.
Csak azt számítsd bele, hogy OpenGL és OpenCL ide vagy oda, a SolidWorks így is tartalmaz FirePro exkluzív funkciókat. Értik, hogy Open platform, de így sem tudják megoldani az OIT-t a többi hardveren, pedig tök szabványos a kód. Aki SolidWorksöt használ így is úgy is FirePrót vesz, akkor meg már ott a Mantle és még több funkciót lehet kínálni. Ez nem az a piac, ahol a nem lehet az exkluzivításra törekedni. De ez csak egy példa.
A konzumer piac viszont más. Ott azért ilyet nem sok játékfejlesztő enged meg magának. Ha egy effektet nem tudnak megoldani minden hardveren, akkor az rossz effekt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem átütő sikert akarnak a fejlesztők csak azt, hogy a beírt kód gyorsan és stabilan működjön, de ha nem működik, akkor annak az okát tutira vissza lehessen keresni.
A játékfejlesztés időre megy, és ha nem találod a kódban a hibát, akkor elég kellemetlen, hogy újra kell írni az adott részt. Mi van ha következőre sem lesz jó? Újraírod megint? Nem tehetsz mást. Ezért akarják az alacsony szintű elérést sokan, mert nem akarják, hogy a driver varázsoljon. Ez ugyanis vagy sikerül vagy nem. És ha nem, akkor igen kicsi az esélyed, hogy kiderítsd miért nem sikerült.
Roppant kellemetlen egy elvileg két hónapos melót egy évig végezni, mert a driver és az aktuális API modell egy bazinagy feketedoboz, amire nincs rálátás. Hogy megcsinálják? Persze. De hogy örömmel dolgoznak? Kétlem.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Persze. Ha visszamehetnénk az időben akkor ezt meg azt lehetne tenni azért, hogy ne ide lyukadjunk ki végül ... de jelen pillanatban nehezebb időgépet építeni, mint új grafikus API-kat írni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az OpenGL állapota a lényeg, a driveres dolog csak extra. Az eredeti cikk azt is leírja, hogy az NV nem teljesen dolgozik szabványosan, így a legtöbb hiba az AMD-nél is ebből ered, mert ők meg követik a szabványt. Ez már eleve egy probléma, mert mindegyik drivercsomaghoz írni kell olyan leképzőt, ami stabil.
Mindenkinél fel van sorolva a negatívum és mindenkinél nagyon komoly. Az NV-nél például a segítségük nélkül nem tudod megírni a programot. Az AMD-nek van erre fejlesztőkörnyezete, de a driver miatt akkor is kell a segítségük. Az Intelre meg másfél év kell, mire írsz működő leképzőt.
Ez a teljes rendszer egy összekuszált összeomlott kódhalmaz. Rakjanak bele pénzt? Mégis miben segít az?Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
emvy (#30): Még annyit, hogy a fejlesztő szemével nézd. A helyzet fenntarthatatlan. A gyártók szemében erre vonatkozóan lehet, hogy stratégia van. Az NV-nek úgymond jó az, ha házon belülre viszik a program fejlesztését, és nem teljesen szabványos leképzőt írnak, amivel a többiek szopnak. De ezzel szopatják a játékfejlesztőket. Az AMD-nek is jó, ha félgőzzel mindenkit támogatnak, hogy fenntartsák a látszatot, de az OpenGL állapota annyira ramaty mindenestül, hogy jó eséllyel Mantle-t választja majd a piac. De ezzel szopatják a játékfejlesztőket. Az Intel meg Rich Geldreich szerint is leszarja, amivel szopatják a játékfejlesztőket.
Akarva vagy akaratlanul mindenki szívatja a piacot, és ez tény. Ez valahol a Khronos hibája is, mert az MS ezeket a gyártói érdekeket valahogy megfogja a DX-nél.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az OpenCL hibajavítás az régi dolog. Aki nem AMD partner az vár a bugfixre (sokat). A probléma az OpenCL-lel is ugyanaz, mint az OpenGL-lel. Csak itt az AMD viselkedik úgy, mint az NV. Egyszerűen magukhoz láncolják a szoftvercégeket és ráadásul nem is teljesen szabványos kódot írnak nekik. Aki nem partner annak lehet problémája az Orca stackkel, és ezeket sokára javítják, hogy legyél hamar partner. Ez persze szopatás, ami a gyártónak üzlet, mert ha megnézed, akkor hogy bejött nekik. Gyakorlatilag minden fontos szoftvercég AMD-re írja az OpenCL fejlesztéseit, aztán lesnek, hogy a többi hardveren nem fut. Ugyanez fordítva.
Ha az NVIDIA az OpenGL mafia, akkor az AMD az OpenCL mafia. Itt visszatértünk ahhoz, hogy a Khronos elég erős-e ahhoz, hogy az ilyen magánakciózásokat féken tartsa.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyeduralkodó biztos nem lesz, de annak bőven van realitása, hogy az AMD-re eleve nem írnak külön OpenGL leképzőt, hanem helyből csak Mantle-re dolgoznak. Ezzel időt és pénzt spórolnak meg. A gond itt az, hogy ma az egyetlen használható OpenGL debugger a GPUPerfStudio2. A többi nem tud debugolni akkora kódot, amekkora kell egy AAA játékba. Szimplán fagynak. A GPUPerfStudio viszont AMD hardverekkel működik jól, tehát mindenképp kell AMD-re is OpenGL kód. Ez megint szívatás level 9000.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Kevés játék támogat OpenGL-t. Az egész API láthatóan egy nagy átláthatatlan kódhalmaz.
Az API-n a driver újraírása nem javít. A core profile-ra gyors lett a driverük, de ennyi. Persze írtak jobb kiterjesztéseket, amelyek már szabványosak és amelyekre a GDC-s modern OpenGL előadások is épültek, de igazából ezek sem érték el a hatást.
A kérdés az, hogy meddig éri meg foltozgatni? A piac resetet akar. Innen pedig egy üzlet az egész, hogy minél tovább húzódik a reset annál többen fogják a Mantle-t választani. Lehet, hogy Graham odateszi magát amennyire tudja, de a vezetőségben meg felmerül, hogy miért is kellene ezt támogatni, amikor pont a mostani gondok viszik hozzájuk a fejlesztőket. Mafiamódszer? Valahol az, de amíg működik nem érdekli őket.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#49
üzenetére
A szememben a Khronos nem egy tökös és keménykezű szervezet benyomását kelti, és ezt évek óta vallom. Úgy gondolom még ha akarnák is a változást, akkor is túl puhapöcsűek hozzá. És ezt most nem bántásból mondom rájuk, csak egyszerűen nem működnek jól. Azt nem tudom, hogy ki ezért a felelős, de én a vezetőt már most kirúgnám, mert évek óta lemaradnak az újításokról, amikor pont azért fizeti a sok cég a tagságot, hogy a Khronos abból a pénzből mindenkinél hamarabb meglássa a jövőt. A gondok egy részéért biztos felelős a mostani vezető.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az alapoktól nem, de azok a kiterjesztések, amiket a cégek ehhez írtak, és amire lényegében épül a modern OpenGL nem teljesen kompatibilisek a régi OpenGL-lel. Ez azon segít, hogy az API többletterhelését csökkentsék a fejlesztők, így az eredmények közelebb lesznek a Mantle-höz és a DX12-höz. Azon viszont nem segít, hogy az API túl átláthatatlan (inkább ront rajta), és mindenképp kell egy-két külön path az egyes gyártókhoz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Minden gyártó magasról leszarja valamilyen módon a Linux tábort. Az NVIDIA nem segíti a nyílt driverprojekteket, ezért sok linuxos utálja őket. Az Intel segíti a nyílt driverprojekteket, de nem ad gyári támogatást ezért linuxos utálja őket. Az AMD segíti is a nyílt driverprojekteket és adnak is gyári támogatást, de mindkettőre csak félgőzzel figyelnek ezért linuxos utálja őket. A helyzet az, hogy minden cég a saját érdekeire rendezkedett be, és eközben a Khronos nem elég kemény ahhoz, hogy a háttérbe szoríttassa a cégérdekeket.
Ami közös ezekben a cégekben, hogy mindannyian tesznek rá, hogy ki mit gondol és arra is, hogy Linuxszal mi lesz konzumer szinten.(#53) Jack@l: A Windows nem azokat a drivereket kapja. Ott beépítenek FirePróhoz való rutinokat is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#61
Abu85
HÁZIGAZDA
PandaMonium
#58
Abu85
HÁZIGAZDA
válasz
PandaMonium
#58
üzenetére
A specifikációk implementációja térhet el. De ez az OpenGL velejárója.
A zárt driver nem baj, de az OpenGL specifikációja olyan felületes és szakszerűtlen, hogy bizonyos dolgokat simán megenged teljesen eltérő módon implementálni a driverben (leghíresebb az ES 2.0 pufferformátum botránya). A végeredmény az, hogy pár cég ugyanazt a fícsőrt eltérő driveres és hardveres implementációval támogatja, ami ahhoz vezet, hogy a kód csak az egyik terméken fog működni, holott elvileg szabványos minden. A nyílt driver pl. arra lenne jó, hogy minden driver ugyanúgy implementáljon dolgokat, így ugyanaz a kód mindenkinél működhet. Ma annyi történhet, mint az ES 2.0-nál, hogy a Khronos kijelenti, hogy mindenki szabványos, csak ugyanaz kód nem fog működni mindenkinél.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
ph Rich Geldreich blogjából megérthető, hogy miért nehéz manapság OpenGL-re fejleszteni.
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Stellar Blade
- sziku69: Szólánc.
- Google Chrome
- Luck Dragon: Asszociációs játék. :)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Star Trek
- Trollok komolyan
- Otthoni hálózat és internet megosztás
- EA Sports WRC '23
- További aktív témák...
