Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
otazka je, ci ostane moznost OpenGL
Pokud nezůstane, byl by to velmi odvážný krok. Ale když jde o Apple, tak bych takové možnosti i věřil.
Jen nechápu - když všichni uživatelé a tvůrci OpenGL jeho nadměrný overhead vidí, proč se tedy neshodli na nové verzi OpenGL?
Mozna je to tim, ze OGL je hrozne stary standard a tim padem si ssebou vlece hromadu funkci jen kvuli zpetne kompatibilite (je to jeste starsi rozhrani nez DirectX). A taky design API jako takovy vychazi furt nekde z 80 let.
Uz pres X lety byla snaha SGI s Microsoftem uklohnit nejake nove API, ale nakonec z toho nic nebylo.
No kazdopadne je fajn, ze se konecne ledy hnuly .... ale je celkem blbost mit 10 ruznych API, uvidime, co nakonec po par letech prezije a co skonci v zapomeni.
Já chápu, že to asi nebude jednoduché, možná ani možné, kvůli zpětné kompatibilitě. Ale už právě kvůli prevenci vzniku 10 různých nových api bych to klidně nazval třeba OpenGL10.0 (na předchozí verzi dodělával jen dalších 5 let nejnutnější záplaty) a začal fungl od znova.
A jak se z hlediska prevence vzniku 10 různých api liší od sebe Metal 1.0 nekompatibilní s OpenGL od OpenGL 10.0 nekompatibilního s OpenGL, protože začíná fungl od znova?
Že by to byl opět počin všech najednou dohromady? Žádné samostatné Mantle s Metalem a kdo ví čím, co se ještě chystá?
ale zhodli
DirectX a OpenGL chtějí dohnat Mantle, sníží overhead
26. 2. 2014 noX
Pokud se tvůrcům DirectX a OpenGL podaří realizovat stávající sliby, můžeme se těšit, že příští generace těchto API přinese některé výhody Mantle. Jde především o snížení nároků na procesor…
Pomineme-li výhody, které krátce uvedené API Mantle přináší a přinese majitelům kompatibilních grafik v nových hrách, zůstávájeden nepopiratelný přínos. AMD se uvedením vysoce efektivního rozhraní podařilo poukázat na nedostatky DirectX (resp. Direct3D) a OpenGL, o kterých se až dosud diskutovalo maximálně mezi herními vývojáři. Otevřená diskuse logicky na DirectX a OpenGL nevrhá nejlepší světlo (je ovšem třeba uznat, že OpenGL z toho vychází o něco lépe) a vytváří nemalý tlak na autory obou API.
http://diit.cz/clanek/directx-opengl-snizi-overhead
A co komercne sa zmeni bez externeho tlaku?
Intel, AMD, NVIDIA Working To Reduce OpenGL Overhead
Standards
Published on 26 February 2014 02:01 PM EST
One of the interesting GDC 2014 presentations is Approaching Zero Driver Overhead in OpenGL. "Driver overhead has been a frustrating reality for game developers for the entire life of the PC game industry. On desktop systems, driver overhead can decrease frame rate, while on mobile devices driver overhead is more insidious--robbing both battery life and frame rate. In this unprecedented sponsored session, Graham Sellers (AMD), Tim Foley (Intel), Cass Everitt (NVIDIA) and John McDonald (NVIDIA) will present high-level concepts available in today's OpenGL implementations that radically reduce driver overhead--by up to 10x or more.
http://www.phoronix.com/scan.php?px=MTYxNjI&page=news_item
Gaming
NVIDIA, AMD, Intel Explain How OpenGL Can Unlock 15x Performance Gains
With OpenGL, an open, vendor-neutral standard, developers can get significantly better performance – up to 1.3 times. But with a little tuning, they can get 7 to 15 times more performance.
http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/#sthash.6iDGUD5E....
Zda sa, ze ten litle-tuning nechcu urobit vyvojari openGL hier, tak tourobil Apple na nizsej urovni OS a nazval to Metal..
Edit:a nejake veci aj v openGL deju, ale su OS a dependent a open source driver related
Mesa Shader Compiler Cache Proposed, Reduces Game Start Times
Mesa Published on 02 June
Tapani wrote, "This series provides a disk cache for the shader compiler and is used to 'skip glLinkProgram' like GL_ARB_get_program_binary does but under the hood without api for the client...With the series I get 50% improvement for L4D2 startup (goes down from 30s to ~15s)
http://www.phoronix.com/scan.php?page=news_item&px=MTcwNzk
Určitě nepůjde o změnu, kterou by šlo realizovat ze dne na den. Už kvůli zpětné kompatibilitě musí zůstat podpora OpenGL zachována. Spíš se to bude týkat nových her a aplikací - pravděpodobně se Apple bude snažit dostat Metal i do benchmarků, aby ukázal příslušný náskok.
Já tedy nechápu proč by měla být zachována zpětná kompatibilita. Naopak, je to jediná šance těchto starších API - zapomenout na břemeno zpětné kompatibility 15 let nazpátek a začít víceméně od čistého stolu. Nebo být zpětně kompatibilní třeba na HW max 3 roky starý
Takže od určité verze iOS přestanou na mobilních Applích platformách fungovat všechny 3D aplikace, protože OpenGL přestane být podporované? Nebo jak si to mám představit? :-)
Pis si ze nezustane. Stejne jako iTunes nepodporuje MIDI...
Hlavne DirectX tlaci Apple, lol :-)
Zatial to ale vyzera ze Metal bude zalezitostout IOS a mobilnych zariadeni. O desktope/macbookoch nepadlo zatial tusim ani slovo, ci?
Inak to nieje moc dobry trend.Teraz bude platit co mobilna platforma to ine api.
Inak pre Epic to musi byt deja vu, prvy UT bola asi jedina rozsirena hra co podporovala oficialne MeTaL od S3.
Třeba je to tak, že Apple uvádí Metal a Epic přichází s novou verzí UT engine, která podporuje MeTaL. :-)
Ano Metal běhal solidně jen na Unrel enginu a bylo to první API s podporou S3TC komprese textur, U byl na 2 discích, ten druhej byl volitelnej s high ress texturama a ve své době to fungovalo jen na S3 Metal hehe. Takže to fakt musí bejt dejavu a dle mého názoru stupidní volba názvu od Apple. Jednak to nenázev neni tak daleko od Mantle, a drukak takové API tu už bylo a byl to propadák, protože se to rozšířilo defakto jen do Unrel enginu a ještě to jelo jen pod win9x S3 nikdy nebyla schopna udělat Metal pro NT platformu. Jednim dechem ale dodám že výkon byl solidní, oproti DX to na tehdejších S3 bylo nebe a dudy.
Dále je to nešťastné drolení API. Mantle které AMD zatím nevyvijí pro linux je pro win, konzole maj své API, Apple bude mít své + všichni držej kompatibilitu OGL + na win všichni držej DX a teď se ještě může sebrat Nvidia a vydat něco svého a bude tu větší chaos než v 90 tých letech.
Hej sa pametam ze ten balik textur mal cez 500MB. Inak mal som aj nejaku demo mapu, ktora demonstrovala prave na S3 kompresiu textur S3TC a tam mala mapa s texturami cez 100MB (bezna mapa do UT aj s vlastnymi texturami sa hybala v jednotkach MB max do 10MB). Tusim tam uz vtedy boli 1024x1024 a 2048x2048 textury. Inak podporovali to len S3 Savage a S3 Savage 4 (ten som mal). Vykon papierovo mal byt uzasny, Savage 4 mal prekonavat nVidiu TNT a tusim aj TNT2 (zakladne modely, ultru tusim nie) ale realne vdaka otrasnym ovladacom vela krat Savage4 nemal ani na starsiu nVidiu TNT. Jedine kde sa ukazoval vykon karty bol prave MeTaL.
Inak toto je bohuzial obraz dnesnej novinarciny. Cakal by som ze sa v tom autor trochu postura a skusi zistit ci je to fakt iba nahoda ze sa to API od Applu vola Metal alebo je za tym nieco viac - mozno zamestnali niekoho z byvalej S3 alebo ten navrh prisiel od Epicu.
No to delenie api je uz teraz. Ale Metal je zatial iba pre mobilne zariadenia - IOS. Zatial to vyzera ze IOS bude primarne Metal a v pripade potreby OpenGL ES2/3, Android OpenGL ES2/3 a Windows Phone DirectX. Dost nestastne riesenie. A na desktope sa to tiez nevyvyja najlepsie.
To je to nejhorsi reseni, co mohli vymyslet.
Uz vidim, jak zacnou vsichni portovat na jejich Metal.
Skoda, ze spousta lidi veri tem kecum o narocnosti OpenGL. Ano, kdyz se pouziva stare opengl, tak samozrejme. Ale OpenGL 4 je na tom uplne stejne, jako napr. DX 11. Nove OpenGL samozrejme pujde zase dal, stejne jako DX 12.
OpenGL je jedine API, ktere je opravdu multiplatformni, tedkom to Apple dost podelal.
Problemom OpenGL, teda podla prave developerov co sa ozvaly ale aj vyvjarov ovladacov, je ze sa da jedna uloha/problem riesit viacerimy sposobmi. Vecsinou je nejaka cesta/sposob cez stare a vo vseobecnosti neodporucane api/funkcie, potom nejaka aktualna odporucana a casto este nieco specificke v zavyslosti od extensions/karty/ovladacu. Dalej problem je ze je docela velky vykonnostny skok podla toho kedy sa ktora funkcia zavola, v ktorom bloku/kroku, v akom stave je aktualne GPU, tak isto ma na to docela vpliv od koho je GPU, ake su ovladace a tiez aj verzie medzi ovladacmi. A tie rozdiely su niekedy velmi velke. A dalsia velka bolest podla autorov clankov je ze OpenGL neni multithreadove. Tak isto ze GLSL sa parsuje v ovladaci a este sa robi aj staticka kontrola co vyvolava lag pri nacitavani shaderov, co moze byt neziaduce a moze to mat napriklad efekt zamrznutia hry na chvilu pri streamovani materialov/shaderov.
Je to sranda, zatímco v běhovém prostředí vlastního softwaru se na sebe vesele vrší vrstva za vrstvou, v grafice je snaha ty vrstvy oloupat na naprosté minimum a dojít k něčemu jako grafický assember. :-)
Ano, toto mě také vrtalo hlavou, asi je to pokus jak dosáhnout nutnosti časté výměny HW kvůli běžnému psaní textu, kdy to bude přetěžovat procesory, ale intra aby běželi s minimální spotřebou a náročností :)
Apple používá v MacBoocích grafiku od Intelu, resp. nVidie. Celý článek je na 99% o iPhonech a iPadech. Takže to vlastně ani žádná tragédie není :)
Otázka je, na jak dlouho. Stejně jako s iPhony přešel Apple na vlastní hardware, je jen otázkou času, než začne podobný trend tlačit i v noteboocích. Spekulace na téma vlastních ARM SoC přinejmenším v MacBook Air se objevují podezřele často na to, aby to byly jen spekulace. Je jen otázkou času, kdy se platnost článku rozšíří i na další produkty :-)
Iste testovacie modely maju na kadecom a urcite existuju nejake prototypy povedzme MacBook Air na ARMe ale pri stavajucom vykone by bola sebevrazda nieco podobne predavat. A Intel by sa tak isto len tak neprizeral. Nehovoriac ze nikto tu nespomenul ze v momente prechodu by Apple prisiel o Thunderbolt, ktory ma zatial ako jediny na trhu. Ostatne ani OpenGL na OSX z hladiska rozsahu a kvality implementacie sa nechyta na to co je vo windowse (rovnaka nvidia karta)
AMD dala nepřímo najevo, že pokud vyrobí dva procesory (ARM a x86) o stejném počtu tranzistorů a oběma bude věnovat stejný čas a úsilí, bude ten s ARM architekturou výkonnější. Pokud tomu budeme věřit (a nevidím důvod, proč by to tak nemohlo být), pak není nereálné, aby Apple navrhl procesor s výkonem srovnatelným s Core od Intelu.
To záleží asi jak ten výkon měří/odhadují. Na určité spefické operace je ARM rychlejší i s mnohem nižším taktem než x86. Ale na některé operace je zase extrémě pomalý nebo je neumí vůbec. Je to prostě tím počtem instrukcí, které ARMu chybí. ARM je RISC a to se asi nikdy nezmění. Osobně se domnívám (a určitě nejsem jediný), že ARM (stejně jako desítky dalších architektur, o kterých se už/ještě nemluví) nemá na desktopu šanci a o enterprise sféře ani nemluvě. Ale uvidíme, čím nás budoucnost překvapí :)
Na druhou stranu je to taky hodně o softwaru a pokud bude software pro ARM napsán kvalitně a dostatečně optimalizovaný, pak se bude určitě jevit rychlejší než kdejaký bazmek pro x86 :)
To je veselo - rázem jsou ze dvou rozhraní 4. Ještě může přijít nVidia se svým na truc AMD, pak ještě Valve si může vyvinout speciální pro SteamOS a bude to opět jako v devadesátých letech. Duch spolupráce se vytratil.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.