- Milyen videókártyát?
- Melyik tápegységet vegyem?
- Milyen billentyűzetet vegyek?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Micro Four Thirds
- AMD Navi Radeon™ RX 6xxx sorozat
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Vezetékes FEJhallgatók
- AMD GPU-k jövője - amit tudni vélünk
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Akkor röviden. Van maga az API. Annak le vannak írva a speckói. Most mindegy, hogy publikus vagy privát formában. Erre a gyártók írnak egy implementációt, ami lesz az API forráskódja. Majd erre lesz egy driver.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
LordX
veterán
Én is azt gondolom, hogy ez így hülyeség.
Az API egy specifikáció, ami alapján minden gyártó csinál egy saját implementációt. Azt ugye csak nem gondolod, hogy az AMD, nVidia, Intel, Qualcomm, ARM stb. OpenGL implementációja mögött ugyanaz a kód lenne? A neve is ezt mondja: Application Programming Interface, és mint olyan, egy interfésznek nincs forráskódja, csak a mögötte levő implementációnak. Hacsak nem arra gondolsz, ami a C header fájlban van (mármint ha egy C API-ról van szó, mint pl az OpenGL); de ez csak erős jóindulattal mondható kódnak, és ha nem publikus, akkor nem lehet publikusan használni; egy nyílt szabványnál ennek ismét nincs értelme.
-
Abu85
HÁZIGAZDA
Az tévhit, hogy egy API-nak nincs forráskódja. Valószínűleg az adja ennek a legendának az alapját, hogy az OpenGL forrása nem publikus, de ettől még még van írva csak a gyártók nem hozzák nyilvánosságra az implementációt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szoftver. Ugyanúgy megvan a forráskódja, mint minden másnak, csak jellemzően nem publikus. Még az OpenGL-nek sem.
De ha kíváncsi vagy arra, hogy egy API hogyan működik, akkor a Mesa3D oldalon vannak forráskódok a MesaGL-ből.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Sir Ny
senior tag
"ők a legkisebb közös többszörös"
legnagyobb kozos oszto? Mar ha a legfejletttebb, mindenki altal tamogatott API-ra gondolsz.
A legkisebb kozos tobbszoros minden valoszinuseg szerint a Kepler, abban minden benne van, ami a tobbiben elofordul. (na jo, Kepler+NanoGL a legkisebb kozos tobbszoros)
-
-
vicze
félisten
Te a HW szintet jobban tudod, azt már képtelen vagyok fejben tartani miben mi van, szóval csak a SW szintet "látom".
Mivel az OpenGL mind mobil fronton, mind desktop fronton jelenleg bedőlni látszik várható, hogy lesz egy új API, mert nem csak mobilon, de desktopon is. Csak hát az még 2év legalább.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Egyrészt a PowerVR Rouge skálázható. Van egy rakás sematikus dizájnja, amit lehet rendelni. Az egyik minimalista, míg a másik tesszellátorral és egyéb funkciókkal kiegészített. És ezeket ugyanaz a név rejti.
Másrészt a low-level API szempontjából ez lényegtelen. A compute, a tesszellátor és még miegymás egy fícsőr, míg a parancspufferek előállítása, a hazardok kezelése, a memóriakezelés, illetve az állapotváltások hatékonysága nem igényel fícsőröket. Ezek szoftveres funkciók. Nem befolyásolja őket a működésüket a hardver tudása.Szerintem a félreértést az adja, hogy a Mantle az egyetlen API, amit látunk, de attól, hogy egy API hatékony legyen még nem szükséges olyan funkciókat kínálnia, mint a Mantle-nek.
Ha a Metal mintájára készülne egy API Androidra, akkor az bőven jó lenne bárkinek.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vicze
félisten
Ezt OK.
Itt PowerVR-nél arra gondoltam, hogy kevesebb featuret támogat mint, mint a többi. DX10 vs. DX11 stb., így az egységesség megvalósításnál ők a legkisebb közös többszörös, amire a fejlettebb többi gyártó azért morogna megint, főleg nV, nekik ez ugye nagyon fontos androidon, hogy a HW képességeit a lehető legjobban kihasználják, mivel azzal ők vezetnek. Az egységes low level API-nak ez a rákfenéje ilyen sok HW-n, hogy mi legyen a minimum. Persze tudom a megoldás, hogy nem jelenik meg az effekt, csak akkor megint ott van a fejlesztő ahol a part szakad, max. gyorsabb lesz itt ott.Akkor az android se kell rohanjon, ha csak 2016. 2017-re lesznek játékok is hozzá.
Te jó ég addig mobil fronton még 2 GPU generáció fog kijönni.
-
Abu85
HÁZIGAZDA
Semmi probléma nincs az architektúrák eltérésével. Az API az egy szoftver. Amit akarnak a fejlesztők, hogy függetlenítve legyen a parancspufferek előállítása. Párhuzamosan annyit állítasz elő, amennyit akarsz. Akár több, akár egy listából jut el a parancspuffer a GPU-ba az attól futni fog. A gyors állapotváltásokra valami előre lementhető state objektum kell, ami szintén betölthető minden hardverre. A hazardok kezelését a fejlesztőknek kell adni. Minden driver csinálja ezt, mindegyik ugyanúgy. A fejlesztő is ugyanazt fogja tenni csak hatékonyan, a hardver meg futtatja a programot.
A DirectX 12 a Windows 9-cel jön. Az 2015 vége.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vicze
félisten
Igen csak az nV rettentessen (érthető okokból) ragaszkodik az androidhoz, így kínkeservesen küzdenek hogy jó minőségű játékokat hozzanak rá. Eléggé biztos vagyok benne hogy AEP miattuk került bele totál értelmetlenül. Itt a Kepler és minden játék OpenGL ES 2.0 döcög.
Amúgy alacsony szintű API-nál a PowerVR és Adreno/Mali/Kepler közti elég nagy difi a fő probléma, sőt ugye már a 6-os PowerVR-en belül is nagy a szakadék XE és XT között.Na meg ugye a DX12-t a XBox One-nak köszönhetjük, és azért számomra még elég kérdéses, hogy mit fog produkálni nV HW-n. Amúgy kiadás mikorra várható egyáltalán?
WP-n meg még nincs HW, ami támogatná a DX12-t majd csak a Adreno 4xx, az meg majd még 1év mire elterjed vagy több. iOS-en ősztől lesz 6 eszköz, ami a Metalt támogatja szóval ezzel Apple elég nagy lépés előnyben van.
-
Abu85
HÁZIGAZDA
Úgy ahogy a DirectX 12-t létrehozták. Vannak igen apró kompromisszumok benne a Mantle-höz és a Metalhoz viszonyítva, de így is felkínálja azokat az alapvető előnyöket, amire a fejlesztők vágynak. Most az, hogy a DirectX 12-ben néha létrehoz a kernel driver egy szerver szálat, ami apró korrekciós feladatokat végez teljesen elfogadható.
Az OpenGL ES 3.0-nal és az újabbaknak az a baja, ami az OpenGL 4-nek is. Ki akarják használni az extrákat, de nem lehetséges, mert vagy nincs hozzá működő profilozó, vagy eltérők a gyártók implementációi, ami ellen a Khronos nem tesz semmit.
Az AEP-re is ezért nem ugrott rá a Unity. A 3.0 is gázos, nemhogy a 3.1. Majd le lesz butítva a grafika. Aki minőséget akar majd vesz WP-t és iOS-t.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vicze
félisten
DX12 2 jó estben majd 3 GPU architektúrát fog támogatni.
Androidon kapásból 6-ot tudok, amiken belül szintén óriási a fregmentáció, és biztos hogy akad még pár, szóval nem éppen ugyan az a kettő.A DX12 ráadásul létező architektúrákra épít, Androidon pedig teljesen új kéne mindenkitől, úgy hogy már 1évre előre megvannak az IP-t tehát csak valamikor 2016 végére lehetne váltani...
De mondhatjuk úgy is hogy megvalósítható csak kicsit távlati terv.[ Szerkesztve ]
-
-
vicze
félisten
Ettől a kérdés még nem lesz megválaszolva.
Hogyan lehet egy nem fix HW-s platformon alacsony szintű API-t létrehozni, sőt hogyan lehet bármilyen nem szabványos API-t létrehozni? Tök mindegy milyen.Szóval a kérdés marad, hogyan lehet egy sok GPU HW-val rendelkező platformon ezt meglépni.
Ugye a válasz igen egyszerű...
Itt felteszem a költői kérdést, hogy hány OpenGL ES 3.0-ás játék létezik Androidra Store-ban? Csak mert 1éve támogatott. Na pont ennyi Google AEP-es játék lesz 2év múlva...
Ezt az egészet az nV tolja ezerrel, hogy egyáltalán valamivel el tudják adni azt a szerencsétlen Tegrát, ez annyira látszik, hogy borzalmas.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nem ezzel van a baj, hanem azzal, hogy túlkoros az API, sok a legacy funkció, nem úgy működik, ahogy a modern hardverek, a kiterjesztések bizonyos függvényekkel nem kompatibilisek, nincs egységesítve a shader fordítás és mire ezek mellet írsz egy működő komplex rendert, addigra minden hardver esetleges saját API-jára is megírhattad volna a programot.
Most ezzel az AEP-vel csak azt éri el a Google, hogy xy iOS vagy Windows Phone port nem, vagy csak butításokkal fog megjelenni Androidon. Ez olyan, mint a SteamOS esete. Hiába van ott az OpenGL 4.x-ben a funkció, ha nem lehet kihasználni valamilyen probléma miatt. A játék megjelenik, csak butított grafikával, aztán lehet lázadni a fórumokon, hogy biztos az Apple meg az MS van a háttérben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
smkb
őstag
" A legtöbben a Microsoft és az Apple alacsony szintű hardverelérést biztosító törekvéseit tekintik jó iránynak"
... és ezt egy olyan egztikus SoC-ekkel agyonfragmentált piacon (Android eszközök) ugyan hogy kellene megvalósítani, ahol annyiféle gpu van, mint égen a csillag, egész eltérő architektúrákkal még azonos cég esetén is (többéves generációk élnek virulnak egymás mellett, és kerülnek implementálásra a mai napig)? Azért ezen a piacon ilyet várni is elégg naiv dolog... indoknak persze jó lehet a fejlesztőknek, ha szarul fut a program.
-
#3
Cathulhu
addikt
cipofuzo87
#2
Cathulhu
addikt
válasz
cipofuzo87
#2
üzenetére
Kérdés, hogy egy cross-platform címnél veszi-e bárki is a fáradtságot, hogy csak az Android kedvéért android specifikus dolgokat használjon pluszban, vagy egyszerűen megelégszik azzal a grafikai szinttel, amivel teljesen kompatibilis marad. Tippre elenyésző lesz az előbbi opciót használók száma. Az igazi hit játékok amúgy is a vérgagyi kategóriából kerülnek ki androidon, nem kell oda semmilyen spec extension.
Ashy Slashy, hatchet and saw, Takes your head and skins you raw, Ashy Slashy, heaven and hell, Cuts out your tongue so you can't yell
-
#2
cipofuzo87
tag
cipofuzo87
tag
Arról van ugye szó, hogy nem olyan rég jelent meg az OpenGL ES 3, és ez az új API is csak olyan (egyébként nem túl sok) újítást hozott, amiket a DirectX 9 is tudott már jó pár évvel ezelőtt. A hardver ma már sokkal többre képes annál, mint amit az "új" OpenGL ES API-val ki lehetne használni.
A gyártók eddig is támogathattak mindenféle OpenGL kiterjesztést, amivel a fejlett funkciók mégiscsak elérhetőek voltak, de ezek a szabványosítás előtt mindig GPU gyártó függőek, egymással nem kompatibilisek, ami megakadályozza a magas költségek miatt, hogy a fejlesztők használják is őket (minden GPU-ra külön megoldás implementálása). A gyártói megoldások megjelenése után szabványosítják ezeket, de még mindig előfordul, hogy egy egy fejlett dolgot támogat egy adott GPU, másikat meg nem, emiatt a fejlesztési költségek továbbra is magasak. A Google most egy csokorba szedte azokat a szabványosított kiterjesztéseket, amik a legfontosabbak és leghasznosabbak, amikkel a legtöbbet lehet nyerni (közel DX11-es szint). Mostmár a top csapatok venni fogják a fáradságot, hogy egy játékot megcsináljanak OpenGL ES 2-re, ES 3 támogatása esetén használni fogják annak az újításait (ez nem nagy meló), de ha támogatja az AEP-et is, akkor pedig egy jóval nagyobb minőségi szintet is el tudnak érni. A GPU gyártók pedig támogatni fogják az AEP-et. Mindenki boldog, és a Google számára is minimális befektetést jelent a dolog.[ Szerkesztve ]
Új hozzászólás Aktív témák
ph Az új Android L operációs rendszer OpenGL ES 3.1-es kiterjesztése zömében EOS és EXT kiterjesztéseket tesz elérhetővé.
- EVGA GeForce GT 740 4GB Superclocked - FOXPOST az árban!
- ASUS Gtx 1650 OC 4GB DDR5
- ZOTAC RTX 3080 Ti AMP Holo 12GB - GARIS
- Pcie 5.0 ATX 3.0 12Pin - 16Pin Moduláris Kábelek És Adapterek 12VHPWR 12v2x6 Egyedi Harisnya Nvidia
- BESZÁMÍTÁS! Gigabyte GAMING GTX 960 4GB videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: Marketing Budget
Város: Budapest