Opencl 1.0 goedgekeurd als standaard voor gpu-computing

De Khronos Group, een organisatie die diverse open mediastandaarden beheert, heeft bekendgemaakt dat de Opencl 1.0-specificatie tot standaard is verheven. Aan de standaard is een half jaar lang gewerkt.

Opencl is een open en royalty-vrije standaard voor parallel computing, en moet software-ontwikkelaars cross-platform-handgrepen geven om instructies door parallel rekenende processors af te laten handelen. Daaronder vallen niet alleen gpu's, maar ook dsp's en processoren zoals de Cell. De Opencl-specificatie bestaat uit een api voor het aansturen van parallele berekeningen en de C99-programmeertaal om de berekeningen te definiëren. Opencl kan daarnaast samenwerken met andere open standaarden, waaronder Opengl.

Het oorspronkelijk door Apple ontwikkelde Opencl kan uitgroeien tot een standaard in de gamewereld, maar ook de medische sector en de wetenschap worden als toepassingsgebieden gezien. Onder andere Activision, Blizzard, AMD, ARM, Broadcom, Electronic Arts, IBM, Intel, Nokia, Nvidia en Samsung hebben zich achter de specificatie geschaard. Microsoft ontbreekt echter in het rijtje. De softwaregigant hoopt hetzelfde te bereiken door compute shader technology aan zijn Directx-api toe te voegen. Deze techniek zal compatibel zijn met Vista, maar pas in Windows 7 aanwezig zijn.

Nu de kogel door de kerk is, heeft Opencl 1.0 een kleine voorsprong. De standaard zal zijn opwachting maken in de zesde versie van Apples OS X, beter bekend als Snow Leopard. De release van de nieuwe versie wordt in het begin van 2009 verwacht. Verder laat Nvidia weten Opencl volledig te ondersteunen; de standaard kan bijvoorbeeld worden aangesproken vanuit de Cuda-architectuur van Nvidia.

Reacties (100)

[Anoniem: 256595]

Misschien dat dit wel voor een grote doorbraak van Mac OS X kan zorgen! Het is niet een of andere leuke API van Apple, maar het wordt dus erg breed ondersteunt: eigenlijk doen alle belangrijke partijen (met uitzondering van MS) mee aan dit verhaal. Snow Leopard komt in het eerste kwartaal van '09 op de markt, misschien dat er dan in de loop van 2009 leuke software verschijnt. Windows 7 staat gepland voor eind 2009 (dat zal wel 2010 worden ), dus kan Apple proviteren van een flinke snelheidsboost t.o.v. Windows als de developers het een beetje snel gaan toepassen (denk aan PhotoShop, Final Cut Pro, etc... wow!)...

Iemand een idee hoe snel dit geïmplementeerd gaat worden in Linux?

[Umbrah]

De grote doorbraak van Mac OS X komt op den dag dat het niet gebundeld is aan Appl€ hardware (see what I did there?) Zonder gekheid, ik ben niet "voor" of "tegen" iets, maar ik denk persoonlijk dat OSX niet kán doorbreken zolang het Apple Exclusive is. Zelfde systeem als in de jaren 80-90 dat je ladingen 100% IBM compatible PC's zag verschijnen. Ladingen games die in de lijst systeemvereisten hadden staan "100% IBM PC or Compatible".

Daardoor is DOS groot geworden, en ook Windows.

[Anoniem: 128823]

Als je iets zou afweten van de historiek van Apple zou je zo'n onzin niet schrijven.

Apple heeft Mac OS jaren lang in licentie gegeven aan andere partners, en dit was een van de redenen dat Apple bijna bankroet was in de jaren 90. Toen Steve Jobs terug kwam als CEO was zijn eerste beslissing het terugtrekken van alle licenties, en dit heeft hen zeker geen windeieren gebracht.

[SG]

Mac bundeld de goeie eigen schappen van PC met Console.
Fixed hardware.
Geen hardware wild groei door derden. B- / C- merken.
Daarin tegen duur en nextgen hardware komt wat later.

Als gamer blijf ik bij Vista.

[Anoniem: 134818]

Ik denk ook niet dat apple dat wil. Ik denk dat ze wel blij zijn met hun, toch steeds groter worden, niche. Dat levert namelijk ook wel (relatief) veel geld op, maar je word niet (zo veel) beschuldigd van van alles en nog wat. Al begint dat wel steeds meer te komen.

[SG]

Maar kwa game communitie te klein en on intersant voor publishers. En apple doet ook geen moeite om MAC als game platform te promoten. Die effort komt puur van de Dev's.

[Anoniem: 69437]

Iemand een idee hoe snel dit geïmplementeerd gaat worden in Linux?

Ik neem aan dat het over een maand of 2 wel in de NVIDIA-drivers zal verschijnen. Ze ondersteunen OpenGL 3.0 ook al een tijdje.

[svenk91]

Met photoshop zal het nogwel duren tot CS5 gezien dit een vrij grote verandering zou zijn. Zo zal het bij de meeste software zijn. En als het nou pas zo'n beetje vast staat zullen de meeste softwareontwikkelaars die het al willen gebruiken er nou pas echt mee beginnen, dus dan kan je ookalweer een tijdje wachten.

Ook denk ik dat de meeste mensen niet denken: oeh, mac ondersteunt opencl 1.0, laat ik een mac kopen inplaats van pc.

[erikdenv]

Iemand een idee hoe snel dit geïmplementeerd gaat worden in Linux?

Kennelijk is het al bruikbaar onder Linux:

http://www.linux.org/apps/AppId_7998.html

[Balachmar]

Dit gaat helaas niet over hetzelfde ding. Dat was een open Cryptografie library die nu Botan heet.
http://botan.randombit.net/news/

[joho]

Dit is toch echt een andere openCL (Cryptography Library).
En is daarom hernoemd naar 'Botan'.
The OpenCL library has been renamed 'Botan', and the main site has been moved to http://botan.randombit.net. Your browser should take you there in a few seconds; if not, click the link.

[Reactie gewijzigd door joho op 23 juli 2024 16:54]

[Anoniem: 163856]

Uhm nee, dat is iets anders dat al langer bestaat - het heeft niets met deze standaard te maken, het heeft enkel de naam die op dezelfde manier wordt afgekort;

Zie ook: http://en.wikipedia.org/wiki/OpenCL

[alx]

Wat NV betreft zal het wel snel gaan, want als ik zo even door de specs heen fiets, lijkt het bijzonder veel op CUDA.
Gelukkig hebben de GPU fabrikanten dus toegezegd OpenCL te gaan ondersteunen en het model is ook geschikt voor Cell.
De grote vraag voor mij is, analoog aan OpenGL extensies, hoe uitbereidingen, al dan niet arch specifiek (liever niet), toegevoegd gaan worden. Via spec update ieder half jaar, extensies of, wat NV betreft, in Cuda. Wellicht helpt het wel dat MS ook geleerd heeft niet te veel optionele dingen (caps) in de DX specs toe te staan.

[Reactie gewijzigd door alx op 23 juli 2024 16:54]

[Antipater]

Ik denk dat AMD ook snel over de brug zal komen. Ze hebben al een tijdje geroepen dat ze zich volledig achter OpenCL zullen scharen en hun eigen initiatieven daarvoor zullen laten varen.

[SG]

Cuda is een door onwikkeling van Cg. Wat nV eigen idee is waar HSML al voor diende. Dus een standaard weer eens niet te volgen.

Cuda is een nV shader onwikkel omgeving met centraal hun nV SM4.0 Compiler voor nV shaders only.
Niks nieuws. OpenCL kan je zien als een nog breedere standaardiseren ook buiten windows HSML om. In DX11 worden die Compute shaders dus door HSML aangesproken.
ATI heeft ook zijn HSML variant Steam computing. Maar niet zo onnodig gemarket naar de consumenten markt. En is ook meer gericht op GPGPU. Daarvoor was het RenderMonkey.

Cuda is niks bijzonder dan 'n compiler met backend en wat low level libaries.
Maar ook ge market naar de consument als een feature.

Dus Cuda en SteamComputing zitten we niet op te wachten.
Als gebruike wil je hebben dat je progje op whatever hardware draaid.
IPV geforceerde hardware discriminatie.

Voorbeeld. Adobe CS4 ondersteund GPU. Maar ATI en nV. HSML
De beroemde plugin met nV erachter gebruikt Cuda en dus nV only.

Met cuda kan DX10 nV hardware door folfing home gebruikt worden.
ATI al langer met DX9 omdat hun DX9 hardware al branch krachtiger was dan nV Dx9.

Dus hoe bijzonder is Cuda. Cuda is niet de voorganger en moeder van alles. Waar je door nV marketing sowat gebrainwashed wordt. Maar een nV zij sprong om weer eens een standaard die er al langer was te bypassen. HSML. Misschien ter glory van hun TWIMTBP afdeling.

Wat brengt dit mee extra werk voor dev's die twee shader paden moet gebruiken als HSML performance of support brak is op nV als de hardware weer eens met nadruk op Cg of cuda gemaakt wordt. De GF FX nV30 drama SM2.0 performace volgens standaard HSML.
Konden Devs er even een Cg/cuda path er in patchen.

[Snoitkever]

Waar de f*ck heb je het over?
Er is gewoon zoveel mis met deze post dat ik haast niet weet waar ik moet beginnen.

Cuda is een door onwikkeling van Cg.

CUDA is een stukje GPU hard- en software die er voor zorgt dat de (NVIDIA) GPU in je systeem C code uit kan voeren. De C variant die voor CUDA gebruikt kan worden is een superset van C met daarin extra operaties voor onder andere synchronisatie en lezen en schrijven naar specifieke stukken geheugen.
Cg is een high level shader taal, die door een compiler naar DirectX shader(byte)code wordt omgezet. Deze machinecode kan op de GPU uitgevoerd worden. Ondanks het feit dat Cg een C-achtige structuur is heeft het verder niets met CUDA te maken.

Wat nV eigen idee is waar HSML al voor diende. Dus een standaard weer eens niet te volgen.

Ik neem aan dat je HLSL bedoelt, en Cg en HLSL zijn ongeveer gelijk ontwikkeld. Cg is in samenwerking met MS ontwikkeld, dus het is niet zomaar een afwijkende standaard.

Cuda is een nV shader onwikkel omgeving met centraal hun nV SM4.0 Compiler voor nV shaders only.

CUDA heeft helemaal niets met shaders te maken, shaders zijn stukken code die voor elke vertex of pixel worden uitgevoerd. Het is een specifiek onderdeel van de 3D graphics pipeline. CUDA staat volledig op zichzelf en kan C code parallel uitvoeren. Het heeft niets te maken met shaders, shadercode, SM4.0 of wat dan ook. Bovendien is het geen ontwikkelomgeving.

Niks nieuws.

CUDA is uniek omdat het de eerste mogelijkheid was om C (achtige) code uit te voeren op een GPU. Daarvoor had ATI een halfslachtige poging gedaan met het ASM based CTM, maar dit was niets vergeleken met de mogelijkheden die CUDA biedt. AMD, MS en Apple lopen wat dat betreft flink achter.

Maar niet zo onnodig gemarket naar de consumenten markt. En is ook meer gericht op GPGPU.

GPGPU is ook zeker op de lange termijn iets voor consumenten. Badaboom! en photoshop zijn nu misschien voorlopers, maar over vijf jaar zullen er meer dan genoeg programma's zijn die gebruik maken van de mogelijkheden van GPGPU. HEt wachten is vooral op een API die voor alle hardware beschikbaar is, en dat gaat DX11 brengen (en hopelijk OpenCL ook).
Daarnaast is CUDA nooit onnodig gemarket naar de consumentenmarkt. Het is voornamelijk een technologie die voor bedrijven interessant is. Het feit dat CUDA (omdat het vernieuwend is) zo vaak op websites als Tweakers te vinden is zegt meer over Tweakers en haar bezoekers (niet negatief bedoeld ) dan over waar het gemarket wordt. Heb jij ooit gewone consumenten over CUDA horen praten?

Daarvoor was het RenderMonkey.

Rendermonkey is een grafische shaderontwikkelomgeving van ATI en heeft niets met GPGPU te maken.

Cuda is niks bijzonder dan 'n compiler met backend en wat low level libaries.

En wat heb je verder nodig dan? Als je GPGPU applicaties wilt ontwikkelen heb je toch juist een compiler met backend en libraries nodig, of mis ik iets?

Dus hoe bijzonder is Cuda. Cuda is niet de voorganger en moeder van alles. Waar je door nV marketing sowat gebrainwashed wordt. Maar een nV zij sprong om weer eens een standaard die er al langer was te bypassen. HSML. Misschien ter glory van hun TWIMTBP afdeling.

Je moet duidelijk een keer je feiten op een rijtje krijgen. Zoals gezegd is CUDA de eerste mogelijkheid om GPGPU mogelijk te maken met C. ATI's CTM was er inderdaad eerder, maar is moeilijk te gebruiken en bijna niet gebruikt.
Er was bovendien geen standaard voor CUDA, want HLSL heeft helemaal niets met GPGPU te maken, en hoe je daar in hemelsnaam TWIMTBP bij weet te krijgen snap ik ook niet. Geeft een bedrijf als Shell ook maar iets om TWIMTBP? Nee! CUDA? Zeker.

Wat brengt dit mee extra werk voor dev's die twee shader paden moet gebruiken als HSML performance of support brak is op nV als de hardware weer eens met nadruk op Cg of cuda gemaakt wordt. De GF FX nV30 drama SM2.0 performace volgens standaard HSML.
Konden Devs er even een Cg/cuda path er in patchen.

Ik ga hier niet eens op in. Als je het bovenstaande leest zou je al in moeten zien dat er werkelijk niet een bewering uit deze zinnen klopt.

[Anoniem: 281203]

En zoals gewoonlijk sluit Microsoft zichzelf weer uit omdat ze denken dat ze het beter weten

Maar dit is een goede zaak voor veel software gezien zowel hardware als software fabrikanten achter deze mooie nieuwe standaard staan.

Van harte aan de ontwikkelaars van deze standaard en laten we er nog veel goeds van het mogen horen.

[mad_max234]

AMD en Nividia staan al tijden achter die van MS, compute shader technology staat al heel lang in de planning. Is standaard onderdeel van DX11 dus daar schaart AMD en Nvidia zich sowieso achter.

En op alle geupdate MS PC vanaf vista os kunnen straks de ontwikkelaar erop rekenen dat die de compute shader technology API heeft, dat is lijkt me beter dan via opencl via cuda, nog geen simpele standaard die standaard in MS pc zit.

Zit al lang te wachten op DX11 voor een grote standaard GPGPU API, en dan kan eindelijk GPGPU echt van start gaan, en word er tenminste iets leuks ontwikkeld, nou ja dat hoop ik.

[Countess]

openCL kan werken vanaf windows XP, en op linux en osx.... en op elke ander besturings systeem.
ATI en Nvidia bieden er straks ondersteuning voor in de drivers. of anders via een gratis update.

kijk als je software toch alleen onder windows wilt draaien is dx11 misschien beter (misschien!) maar openCL is veel flexibler, and bied ondersteuning aan veel meer hardware.

[blouweKip]

directx is een probleem voor portabiliteit, vanuit MS wel logisch (minder concurrentie = vendor lock-in = meer inkomen voor ms) maar voor de markt een regelrechte ramp

[SG]

Omdat AMD en nV met hun 3D consumenten produkten de gamers markt bediend.
En daar overheerst MS windows.
Bij de dev's is het niet anders de MS windows is hun maintarget. En hun Dev tools zijn vaak ook van MS. VC++ VS2005 VS2008 etc.
De sDK erbij. Dus dan heeft DX drivers al snel wat meer preoriteit.
AMD en nV geven beide API voldoende aandacht.
Game developers overwegend niet. Daar is het MS.

[YopY]

Nu nergens om, maar Direct3D is nog steeds mijlenver vooruit op OpenGL qua technologie, dus ja, wat dat aangaat weten ze het ook beter.

[blouweKip]

Direct3d heeft tot voor kort achtergelopen op Opengl, toch werd het toen al veel gebruikt dus de features/kwaliteit is schijnbaar niet zo van belang bij een 3d api

[Anoniem: 77640]

Tot voor kort?

De kwaliteit van de Direct3D drivers was al zeer vroeg beter dan die van de OpenGL drivers. En de oorzaak was precies dat OpenGL te hoge eisen had die enkel door dure workstationkaarten ondersteund werden. Microsoft heeft altijd goed overlegd met de makers van grafische kaarten voor consumenten om tot een specificatie te komen die goed ondersteund wordt. Het heeft geen zin om features te specifiëren die de kaarten van de consumenten niet ondersteunen.

Toen Direct3D uiteindelijk méér features kreeg dan OpenGL hebben ze die laatste massaal beginnen uitbreiden met 'extensions'. Die zijn lastig te beheren en iedere versie van OpenGL kreeg er weer nieuwe zonder de oude volledig te vervangen. Het duurde ook telkens te lang voor de extensions van verschillende kaartbouwers tot één standaardextensie gesmeed werden. Direct3D daarentegen zorgde dat verouderde features met iedere versie in een nieuw kleedje gestoken werden. Bovendien is de object-georiënteerde API van Direct3D vertrouwder om mee te werken in een krachtige taal als C++.

[SG]

Denk dat het eerder is dat de Gamer markt
Windows heerst en bij Developers de Visual studio developer tools heerst.
Op wat excotische devs na. Zoals IDsoft.
DirectX met directX3d voldoet en doet de task goed.
Dat openGL dat ook doet iets minder of beter is niet relevant.
Tenzij linux gelijk waardiger wordt. Kwa target market grote.Maar dan moeten eerst de Dev's overstappen naar 'n ontwikkel omgeving voor ook linux. Dus Crossplatform OpenGL.

[Anoniem: 117334]

uitganspunt van direct3d is voor microsoft zo snel mogelijk zo veel mogelijk nieuwe features implementeren terwijl opengl veel meer rust op stabiliteit.

De voorsprong heeft microsoft vooral te danken aan het gestuntel van de Khronos group, hier een mooi artikel erover

[Reactie gewijzigd door Anoniem: 117334 op 23 juli 2024 16:54]

[Anoniem: 77640]

uitganspunt van direct3d is voor microsoft zo snel mogelijk zo veel mogelijk nieuwe features implementeren terwijl opengl veel meer rust op stabiliteit.

Microsoft implementeert niks. Ze specifiëren enkel een API naar de applicatieontwikkelaars toe en een driverinterface naar de hardwareproducenten toe.

En er wordt ook niks "zo snel mogelijk" gedaan. Grafische kaarten en hun drivers zijn járen in ontwikkeling. De WGF specificatie dateert van zomer 2004, en de ontwikkeling van GPUs met die mogelijkheden startte dus reeds vroeger. Met andere woorden OpenGL heeft al ruim vier jaar geen antwoord op de evolutie van grafische kaarten. Rust en stabiliteit? Zeg maar vastgeroest.

[SG]

De nieuwe DX versie komen tot stand door samenwerking van.
API bakkers MS met GPU bakkers AMD nV iNtel en Top Developers.

De Game developer community hoort ook de API en hardware vendors bij.

MS weet hierdoor bij voorbeeld naar welke features vraag naar is en daarmee ook GPU vendors. Zodat Developer dat kunnen toepassen met de nestgen GPU DX en games. De triangle van overleg.

Het is natuurlijk zinloos om wat wild een nextgen GPu te onwikkelen terwijl MS onafhankelijk een API ontwikkeld. De een mist de API de ander de hardware.

[roy-t]

Pardon? De laatste openGL update die echt wat toevoegde que functies is uit 2006, sinds DirectX 8.1 loopt MS al zeker gelijk en ondertussen zijn we toch bijna 3 jaar en 2.5 standaard verder. 1 Triviale functie die door de meeste users nooit gebruikt gaat worden noemen om dan te vertellen dat OpenGL mijlenver voorloopt op DirectX vind ik dan een beetje vreemd.

Kijk maar naar de laatste OpenGL update van +- 3mnd geleden door deze zelfde groep, iedereen was teleugesteld waaronder veel aanhangers van OpenGL zelf, veel bedrijven die lange tijd bij OpenGL zweerden (Autocad e.d.) begonnen zelfs te vertellen dat ze op deze manier liever DirectX gebruiken.

Ook qua hardware support loopt OpenGL mijlen ver achter, doordat er niet consequent elk jaar een nieuwe versie wordt uitgegeven met nieuwe features ondersteunen nu ATI kaarten set1 van de nieuwe featuers, en Nvidia kaarten set2 van de nieuwe features (ondanks dat die nieuwe features beide ongeveer het zelfde doel hebben). Intel kaarten ondersteunen dan weer alleen de basis instructies set.

OpenGL is een ontzettende rotzooi aan het worden en loopt absoluut niet mijlen ver voor op DirectX het is eerder andersom tegenwoordig. (Het spijt me zeer).


Verder heeft MS een zeer groot aantal standaarden zelf geintroduceerd die succesvol zijn geworden, velen doordat ze meteen in het meest gebruikte software pakket zaten, maar ook velen omdat ze gewoon prima (cross platform) werken en MS duidelijke API's heeft waarvan alle functies netjes op het MSDN zijn terug te vinden zonder dat je je daarvoor hoeft te registreren of wat dan ook. Wat dat betreft is MS een erg open bedrijf. Trouwens zowel Ati/AMD als Nvidia hebben al hun eigen 'videokaart supercomputer code' geintroduceerd, dus nu alleen naar MS je neus ophalen omdat ze niet samen werken met een self proclaimed standaard van Kronos?

Trouwens zover ik weet is kronos toch geen orgaan zoals W3 of IEEE, maar gewoon de beheer en ontwikkel groep van OpenGL? Dus nu hebben ze de 'supercomputer' taal geinspireerd op hun eigen taal, ontwikkeld door oa leden van Kronos uitgeroepen tot standaard?

Wij van WC eend....

[PrisonerOfPain]

Het grote voordeel dat OpenGL heeft boven DirectX, voor mij als ontwikkelaar, is simpel weg dat ik, mits ik enkel de ARB en EXT extensions gebruik, helemaal geen last heb van vendor lock-in. Dat heeft voor mij veel meer te betekenen als wanneer het de aller nieuwste features in de allerlaatste versie heeft zitten.

Overigens zijn er inderdaad verschillen tussen video kaarten en diens fabrikanten met betrekking tot het ondersteunen van verschillende features, echter is het niet zo dat DirectX die problemen niet heeft. Daar ben je immers ook nog steeds device capablities aan het checken en fallback behaviour aan het implementeren ook al word het voor een deel in software opgevangen.

PS. Khronos is net zo goed een ontwikkel groep.

[newinca]

Daar ben je immers ook nog steeds device capablities aan het checken en fallback behaviour aan het implementeren ook al word het voor een deel in software opgevangen.

*Cough* DX10 heeft geen cap bits...*Cough* Daar is het alles of niets.

[Anoniem: 69437]

En nieuwe features sinds de release van DX10? OpenGL maakt die beschikbaar via extensies. Kan je die in DirectX 10 dan gewoon niet gebruiken?

[newinca]

En nieuwe features sinds de release van DX10? OpenGL maakt die beschikbaar via extensies. Kan je die in DirectX 10 dan gewoon niet gebruiken?

Daar dient DX10.1 voor. Een grote verbetering tov DX9 waarbij je voor elke mogelijke nieuwe feature een aparte versie kon uitbrengen (DX9a,b,c enz). Game developers vinden die zekerheid fantastisch tov vroeger.

De extenties van OpenGL zijn voor veel features vender specific en niet compatible.

[SG]

Ja er zijn nog altijd optionele DX10 feature. Maar daarvoor moet de Dev dan bewust kiezen. ipv zo'n grote stamboom aan Device caps. Is dat nog altijd beter.
In DX10.1 is veel wat bij DX10.0 optioneel was. Verplicht geworden.

[elmuerte]

Heb je ook een referentie waar die conclusie onderbouwd wordt?

[Anoniem: 282252]

Houw even in je achterhoofd dat :

- DirectX (wat for versie ook) is leuk voor Games
- OpenGL voor technische applicaties..


Dat wil zeggen dat de Open GL specificaties op alle platformen hetzelfde behoren te werken volgens strict specs. Dit is dus ideaal voor alle applicaties waar nauwkeurighoud van het model op het scherm goed is te voorspellen. Voor dat zoort applicaties kun je dus niet met DirectX om de hoek komen die bij elke minor/mayor versie nog wel eens anders werkt.

Zoals ook eerder is gezegd is dat je OpenGL via het netwerk kan benaderen, iets wat met DirectX niet mogelijk is. Dat wil dus zeggen zware machine ergens in het basement, en dan gewoon het model oversturen naar de desktop op de 3de vloer.

Je zult dus altijd zien dat OpenGL en DirectX blijven bestaan, elke voor zijn eigen doel.

Greats,
Ries

[newinca]

Houw even in je achterhoofd dat :

- DirectX (wat for versie ook) is leuk voor Games
- OpenGL voor technische applicaties..

Dat wil zeggen dat de Open GL specificaties op alle platformen hetzelfde behoren te werken volgens strict specs.

Ik hou vooral in mijn achterhoofd dat jouw stellingname complete onzin is.

De specificaties van OpenGL zijn een stuk losser dan die voor DirectX (vooral DX10 en later.) Microsoft kan het zich permitteren om stricte regels op te leggen, Khronos kan dat niet, omdat het afhangt van een concensus tussen verschillende partijen met tegengestelde belangen.

En veel belangrijker dan stricte specs (die uiteindelijk maar een hoop papier zijn) is het bestaan van stricte tests. Wat dat betreft staat OpenGL zo goed al nergens. OpenGL ES heeft een compliance test, maar dat is niet meer dan het controleren of de API volledig is. Microsoft heeft de WHQL tests, die dramatisch veel rigoureuzer zijn op het gebied van testing. Ten slotte komt daar nog bij dat de WHQL tests continue worden aangepast als er gaten ingevonden worden. Het is wat dat betreft veel meer een regression suite dan het schaamlapje dat OpenGL tentoon spreidt.

Dat OpenGL meer gebruikt wordt in technische applicaties heeft alles te maken met het feit dat veel van applicaties tientallen miljoenen lijnen code bevatten die soms al 10 jaar mee gaat en geen nood heeft aan de nieuwe GPU features. Veel van de allerduurste CAD programma's gebruiken nog steeds OpenGL 1.2. (!)

Je gelooft me niet? Lees dan even dit hier:

When we use OpenGL, we have found over the past many years (and still today) that we need to invest in a large, significant amount of QA that simply verifies that the OpenGL graphics driver supports the OpenGL API on the level that we use...

en

With Direct3D, our QA team can focus on testing _our_ code and finding defects in _our_ graphics code, instead of having to spend all their time just verifying that the graphics HW vendors have done their job correctly to produce an OpenGL graphics driver that actually works.

Stricte specs, mijn achterwerk...

Oh ja, en wat netwerk betreft: klinkklare nonsense. Er is absoluut niets in de OpenGL specs die het daar over heeft. Je verwart OpenGL met het X protocol.

[Reactie gewijzigd door newinca op 23 juli 2024 16:54]

[Anoniem: 77640]

Houw even in je achterhoofd

Doet zeer hoor, dat houwen.

[Reactie gewijzigd door Anoniem: 77640 op 23 juli 2024 16:54]

[Finder]

We praten hier wel over OpenCL geen OpenGL !

OpenCL moet gebruikt worden als render-unit binnen het OS en de applicaties NIET als grafische motor. Op dat vlak heeft het ook niets te maken met DirectX

http://nl.wikipedia.org/wiki/OpenCL

[Anoniem: 77640]

Dat hebben de meesten hier wel door hoor. Maar er is een directe link met DirectX 11 Compute Shaders. En hoewel die ook niks met grafische zaken te maken hebben is qua standaard OpenCL te vergelijken met OpenGL, waardoor ook weer de vergelijking met Direct3D kan gemaakt worden. Net zoals Direct3D over OpenGL domineert op Windows is het goed mogelijk dat OpenCL het zal moeten afleggen tegen DirectX 11 Compute Shaders. Het is afwachten of dat inderdaad het geval zal zijn, maar in tussentijd kunnen we er wel lekker over discussiëren door eerst nog eens OpenGL met Direct3D te vergelijken.

[SG]

Dat vind ik raar maar als OpenCL shader code is. Kan dat voor
Shader effecten maar ook voor GPGPU gebruikt worden. in ieder geval dat zou ik verwachten.
Of is OpenCL net als Steam computing in de pers komt meer gericht op GPGU.
En nV Cuda een oplossing voor beide. Meer zoals HSML lijkt te zijn.

[Anoniem: 8819]

hopelijk word deze standaart.

Vind namelijk dat microsoft met zijn directx al een monopolie heeft
Laat staan als er ook compute shader technology aan zijn Directx-api bij word gezet.

En ja ik weet dat er wine er is en open-gl.
Helaas hebben de meeste mensen toch windows en daar zit directx aangebonden.

[Umbrah]

De enige serieuze concurrent ooit was Glide, OpenGL bestaat niet en is gewoon obsolete en heeft een gebrek aan besluitvaardigeheid. Ik denk niet zozeer dat MS een monopolie heeft, ik denk eerder dat er een gebrek is aan een geschikte concurrent. Het hoeft niet "open" te zijn, als het maar op veel hardware draait. En dat doet DirectX. OpenGL ook, maar die hobbelen overal achteraan. Dat is qua besluitvaardigheid net de EU.

[link0007]

OpenGL loopt inderdaad iets achter (ook niet veel), maar dat is meer een kip-ei kwestie dan gebrek aan besluitvaardigheid.. Zolang iedere windows developer directX blijft gebruiken is er geen markt voor openGL, en omdat er geen markt is voor openGL word er niet al te snel aan ontwikkeld, waardoor het achterloopt en iedereen directX blijft gebruiken.

Zeker jammer, want kwa APIs vind ik openGL toch wel een tikkeltje fijner

[oeLangOetan]

d3d10 is een veel schonere API dan het misbaksel genaamd ogl3.0

ogl is kapot gegaan omdat CAD ontwikkelaars niet wilden dat de api grondig herzien werd

[SG]

Kip en ei.
De gebruiker heeft als enige invloed om ipv XP of Vista. 'n Mac of linux bak te pakken.
Je benadeel je dan wel kwa games. Als je Wine incompabiliteit wil mijden. En patches richten zich op windows.
Windows is dé main target. Dus als gamer ga je voor Windows. En noob's krijgen als OEM.

Dan bepaald de Dev of die voor Windows DirectX of OpenGL/AL gebruikt. Dus de Dev bepaald OpenGl of Direc3D. Want die hebben altijd de alternatief.
Maar de professionele markt zit aan MS Developmet tools. En daar komt DirectX vanzelf mee. Als SDK

[blouweKip]

Ook toen opengl beter was dan direct3d (dwz, voor direct3d 9) werd direct3d meer gebruikt, als consortium kun je nu eenmaal niet op tegen windows bundeling + zakken met geld voor developers (zie bij epic)

[mjtdevries]

Had niks met zakken geld te maken.

Nvidia is daar wel goed in, maar Microsoft maakt daar veel minder gebruik van.
Het punt is gewoon dat opengl niet op games gericht is, en directx wel.
Daardoor werd voor een game directx al snel interessanter dan opengl. (dat was al met dx7 het geval)

Voor CAD is directx juist weer niet interessant.

Dezelfde situatie kon hier ook wel eens gebeuren.
Opencl is niet specifiek op games gericht. Goede kans dus dat Directx11 in de praktijk veel handiger wordt voor games dan opencl, terwijl opencl handiger is voor bv "folding".

[tuXzero]

Ik denk niet zozeer dat MS een monopolie heeft, ik denk eerder dat er een gebrek is aan een geschikte concurrent.

Op 17 september 2007 heeft de Europese rechter bevestigd dat Microsoft een monopolist is. Dit was namelijk al zo op 5 November 1999. En daarom dus een feit.

Het hoeft niet "open" te zijn, als het maar op veel hardware draait.

"open" waarborgt dat het op veel platformen kan draaien. De vrij markt is geen perfect systeem en daarom zijn er wetten bedacht die de integriteit van dat systeem moeten waarborgen. Helaas is E.E.E. nog niet verboden. Maar gelukkig zorgen open standaarden en onafhankelijke testsuites (zoals de W3C validators) voor de integriteit en de beschikbaarheid van het standaard tussen concurrerende partijen.

Het bestaan van beide API's is een direct gevolg van een niet open standaard. Als Microsoft's Direct X API open was dan zou er geen noodzaak zijn om twee API's te hebben. Afgezien van structurele technische veranderingen in de API (Meestal bijgehouden d.m.v. de versie nummer).

Microsoft geeft de Direct X API nooit vrij als het aan hun lag omdat ze dan moeten concurreren om de beste implementator te zijn, net als de GPU bakkers. Microsoft moet dan meer innoveren dan ze nu doen (zijnde hun monopolie positie zijn ze verplicht te innoveren, they are watched!) en dan kan ook de prijs van Windows omlaag. Ze zullen dan ook op prijs moeten concurreren.

Of OpenGL nou beter is of niet. Als je water trappelt in het zwembad, en een andere trappelaar duwt je kopie onder. Dan sta je inderdaad onderaan. Maar is dat eerlijk?

Gelukkig zijn er momenteel genoeg instanties die aansluiten op het OSI en daarom de markt leven houden!

tuXzero pleit voor één open API en laat dan de strijd maar lost barsten voor de beste algoritmen en code schrijft (of hardware bouwt). Nu is Microsoft die grote jongen die de kleine onder water duwt, iets dat nooit goed kan zijn voor de markt.

[Fiander]

Op 17 september 2007 heeft de Europese rechter bevestigd dat Microsoft een monopolist is. Dit was namelijk al zo op 5 November 1999. En daarom dus een feit.

Of je geeft hier nu aan dat Ms geen serieuze concurent heeft, wat eigenlijks ook zo is, of je hebt je kader verkeerd staan, want het artiekel wat je quote gaat over windows, en niet over dx.

En waar duwt Ms iemand onder water dan ? Of bedoel je dat ze iets uitbrengen waarin ze iets maken wat al jaren terug door ze bekent gemaakt is, en ondertussen snel even in elkaar gezet is door iemand anders ?

[Reactie gewijzigd door Fiander op 23 juli 2024 16:54]

[tuXzero]

Of je geeft hier nu aan dat Ms geen serieuze concurent heeft, wat eigenlijks ook zo is, of je hebt je kader verkeerd staan, want het artiekel wat je quote gaat over windows, en niet over dx.

De enige die ik quote is Umbrah. En het artikel waar ik naar refereer (de eerste referentie) gaat over Microsoft, dus beter lezen.

En waar duwt Ms iemand onder water dan ? Of bedoel je dat ze iets uitbrengen waarin ze iets maken wat al jaren terug door ze bekent gemaakt is, en ondertussen snel even in elkaar gezet is door iemand anders ?

Microsoft duwt veel mensen onder water omdat zij de dictatoriale partij zijn op Windows. Het OS is een ecosysteem voor ISV's. In dit ecosysteem speel Microsoft de regie. Dat is een bewezen feit middels talloze rechtszaken.

Als je wilt weten hoe Microsoft mensen onder water duwt dan moet je eens wat lezen over E.E.E..

[SG]

OpenGL kan alleen concureren als de Mac en linux platformen elk een serieusere target markt uitgroeien gelijk waardig kwa grote aan Win PC.
En het mooie is Crossplatform is daar zelfs simpeler dan bij consoles.
Omdat de paltformen meer gemeen hebben voor games.

Muis keyboard.
Die zelfde GPU.
Mem variaties zelfde bereik.
Reken kracht variaties zelfde bereik.

Maar nu zijn die platfomen economish on interresant om geld te steken voor een te kleine afzet markt.

[Anoniem: 24417]

ik programmeer nog altijd opengl, en heb nog geen beperkingen kunnen ontdekken. denk dat die 'achterstand' meer gevoelsmatig is dan technisch.

bovendien, zolang dx niet werkt op andere platformen dan windows zal opengl niet doodgaan. zeker na dit nieuws niet meer

[mad_max234]

Opengl kan gewoon op MS pc, dus zitten niet vast aan DX als je MS os gebruikt, opengl loopt gewoon achter, en opengl is gewoon niet geaccepteerd door de ontwikkelaars, opengl geeft de ontwikkelaars gewoon geen reden om over te stappen.

Monopolist word je niet als je concurent gewoon niet goed genoeg is, dat is hier aan de hand, want op elke MS pc met ondersteunde opengl kaart kan opengl gebruikt worden, maar word gewoon niet gedaan, te omslachtig en kan minder.

[Anoniem: 69437]

Het is omslachtig vanwege de extensies (wat met Glee/Glew wel te verzachten valt), maar door die extensies kan je er wel evenveel mee als Direct3D, en soms zelfs meer. De Vista-only Direct3D 10-features kan je bijvoorbeeld onder Windows XP gebruiken met OpenGL-extensies.

Vista's nieuwe drivermodel maakte Direct3D 10 een stuk sneller dan Direct3D 9, maar OpenGL lift lekker mee op dat verbeterde drivermodel.

[SG]

Kan het niet eerder liggen aan de uitgebreide ontwikkeling omgeving die MS de Dev wereld mee voorziet en de hele IT. En in de professionele wereld vaak gebruik van wordt gemaakt.

[jj71]

Goed dat er een open standaard is voor GPU computing, dan hoef je je software niet meer specifiek voor een bepaald soort hardware te ontwikkelen (bijvoorbeeld een nVidia kaart met CUDA), wat goed is voor de ontwikkeling van GPU computing.

En wat typisch eigenwijs weer van Microsoft. Waarom blijft Microsoft toch altijd maar zijn eigen standaarden uitvinden en iedereen door de strot te duwen (wat ze vaak nog lukt ook omdat ze een monopoliepositie hebben)? Het wordt tijd dat Microsoft eens wat minder arrogant wordt.

[Anoniem: 175233]

Er is geen sprake van dat Microsoft eigenwijs is. Microsoft was al veel eerder met deze ontwikkelingen bezig, en is in veel opzichten de vader van deze technologie. De hele floating point shader business bestaat, omdat MS en ATI dat in DX9 zo hard gepushed hebben. Vrijwel gelijk vanaf dat moment is er al met de gedachte gespeeld om de GPU meer generiek in te zetten. Het wordt op dit moment allang gedaan op Windows, alleen nog niet zo mooi geintegreerd. De volledige integratie zit gewoon DX11, en komt dus zeer binnenkort. DX11 hoeft trouwens ook niet perse op Windows 7 te wachten... kan ook gewoon op Vista. Er zit daar geen koppeling.

Men heeft hier gewoon gebruik gemaakt van ontwikkelingen die eigenlijk compleet van het windows platform afstammen, en dan snel een standaard gefabriceerd om MS te snel af te zijn...

[Anoniem: 24417]

wat is een floating point shader?

[Anoniem: 77640]

Stukken code die op de GPU draaien die gebruik maken van reële getallen (vlottende komma) in plaats van enkel gehele getallen (vaste komma). Dit komt overeen met de rekenkundige bewerkingen die de CPU kan, en biedt veel hogere precisie. Aanvankelijk was dat een beetje 'overkill' voor grafische zaken maar intussen wordt het goed benut en hierdoor is de GPU ook soms geschikt om zwaar parallel rekenwerk van de CPU over te nemen.

[YaPP]

En wat typisch eigenwijs weer van Microsoft. Waarom blijft Microsoft toch altijd maar zijn eigen standaarden uitvinden

Microsoft heeft er *geen belang* bij dat ze iets leveren wat je vervolgens even makkelijk op een concurrerend platform kan gebruiken.

Of DirectX shaders nu beter of slechter zijn doet er hier niet toe. Het is belangrijk voor Microsoft om ontwikkelaars op het Windows platform te houden, en een mogelijke overstap niet makkelijker te maken. Klinkt misschien een beetje cru allemaal, maar commercieel gezien is de redernatie te begrijpen.

(of je het leuk vind is wat mij betreft een ander verhaal)

[Snoitkever]

En wat typisch eigenwijs weer van Microsoft. Waarom blijft Microsoft toch altijd maar zijn eigen standaarden uitvinden en iedereen door de strot te duwen (wat ze vaak nog lukt ook omdat ze een monopoliepositie hebben)?

Waarom zouden ze hier iets mee doen? Ze hebben hun eigen DX11 compute shaders, en NVIDIA en ATI brengen toch wel hun eigen OpenCL drivers en software uit voor Windows. Wat zou MS er dan precies mee moeten doen?

[Dutch2007]

hmm dit is wel leuk, als nvidia & AMD/ATI het ondersteunen..., miss dat je dan minder NVIDIA games krijgt

[ZpAz]

Zijn er dan games die alleen op een Nvidea kaart werken?

[Anoniem: 24417]

nee, maar wel een paar die voor nvidia kaarten zijn geoptimized

[koenderoo]

En waarom zou dat nu niet kunnen gebeuren? Games die voor Nvidia geoptimized zijn werken ws ook met DirectX. Dat doen de AMD/ATI kaarten dan dus ook.
Het verschil zit hem echt niet in DirectX of OpenCL. Het zit hem in de optimalisering voor de technologie in de kaarten.
M.a.w. stel dat Nvidia beter shader technologie heeft, dan wordt daar meer op ingezet (of andersom).

[SG]

Nee als dev's voor een feature kunnen kiezen uit 3 methoden.
Moeten ze voor die kiezen waar aTI allergies voor is of die nV de meeste voordeel geeft. Dit komt doordat de architectuur andere logic methioden gebruikt. Alles heeft zijn voor en nadeel. Zodat hardware toch anders kan reageren op verschillende software methoden.

[FluoDude]

ik verwacht dat openCL wel een kans maakt in GPGPU rekenkracht voor wetenschap en professionele apps. Maar voor games denk ik dat Directx 11 of physx meer kans maakt om door te breken als defacto standaard.

[SG]

Ja OpenCL professioneel aangezien dat ook vaker voorkomt op niet windows paltformen.
Voor games HSML DX11 maar OpenCL maakt daar ook kans.
Gezien physX nV is en hun al goed openGL en linux supporten. En OpenCL eerder uit is. Kan Cuda vervangen worden door openCL. Re compile na wat aanpassingen.
En aTI Get into the Game. Met physX door OpenCL.
nV beconcureerd met physX vooral iNTel CPU met Havok. En heeft ATI eigen nodig. Voor physX GPU hard te pushen.

[Pomp]

Dit biedt zeker veel voordelen, denk maar aan alle applicaties die wel intensief gebruik maken van de , zoals encryptie, compressie, emulatie en virtualisatie, maar geen gebruik maken van de grafische kaart. Eigenlijk is het tot nu toe zonde geweest om bij dat soort applicaties een krachtig stuk hardware als een grafische kaart links te laten liggen.

[SG]

Dat is niet de voordeel.
HSML Cg Cuda Steam computing doen dat ook al
OpenCL is een standaard groter dan Windows platform beperte standaard HSML
Het voordeel is dus Crossplatform buiten MS platformen.

[IStealYourGun]

Tot zover het argument van MS: "men mag mensen niet dwingen tot één standaard", die men luidkeels heeft zitten roepen bij OOXML.

[IStealYourGun]

Microsoft is lange tijd een bedrijf geweest dat enkel hun eigen 'standaard' steunde, zie maar naar de eerste browser wars. Eén van de argumenten voor OOXML tot ISO standaard te maken was dat men de mensen en bedrijven keuzen moesten geven tussen standaarden en men melde er toen bij dat "Microsoft die fout in het verleden wel heeft gemaakt" maar "dat men uit die fout heeft geleerd" (staat ergens op wikipedia/tweakers). Het heeft exact 1 standaard geduurd om die fout niet meer te maken.

Dat vindt ik jammer, Microsoft zou beter deze standaard ook steunen en parallel hun eigen standaard verder afwerken. Op vlak van programmeren is keuze een goed voordeel. Op vlak van communicatie minder.

[Anoniem: 77640]

Microsoft zou beter deze standaard ook steunen en parallel hun eigen standaard verder afwerken.

Microsoft hoeft deze standaard niet te steunen, het hoeft er enkel maar voor te zorgen dat het ook draait op Windows. Aangezien ook OpenGL op Windows draait en er ook een markt zal zijn voor OpenCL zie ik niet waarom ze het zouden boycotten. Steunen daarentegen, da's wat anders.

En waarom zouden ze ook. Als je denkt het zelf beter te kunnen waarom dan de specificatie van de concurrentie als dé standaard aanvaarden? DirectX 10 is ook een stuk beter dan OpenGL 3.0. OpenCL is nu een stap voor, maar het is niet ondenkbaar dat de kaarten snel anders zullen liggen na de release van DirectX 11.

Je zou je zelfs kunnen afvragen waarom Mac OS en Linux DirectX niet ondersteunen...

[koenderoo]

Simpele reden waarom Mac OS en Linux DirectX niet ondersteunen: het is niet open. Daardoor is het niet in te passen in MacOS en Linux.
Microsoft kijkt ook wel uit met het open maken van DirectX. Daarmee zouden een sterke troef uit handen geven voor de verkoop van Windows aan o.a. gamers.

[Anoniem: 77640]

Simpele reden waarom Mac OS en Linux DirectX niet ondersteunen: het is niet open. Daardoor is het niet in te passen in MacOS en Linux.

Dat het niet open is belet hen helemaal niet om het te implementeren. Hoe denk je anders dat Cider te werk gaat?

Microsoft kijkt ook wel uit met het open maken van DirectX. Daarmee zouden een sterke troef uit handen geven voor de verkoop van Windows aan o.a. gamers.

Nogmaals, die oplossing bestaat reeds. Direct3D is niet open in de ruime betekenis (vrije inmenging van meerdere organisaties), maar de specificaties van de API zijn tot in het kleinste detail gedocumenteerd en vrij te downloaden. Bij mijn artikel in het ShaderX3 boek lever ik zelfs het complete Direct3D 9 raamwerk op de CD (en DX10 is niet veel moeilijker).

Er zijn dus wel betere argumenten te vinden waarom Apple en Linux niet rechtstreeks Direct3D ondersteunen...

Mijn punt is dat Microsoft hier bekritiseerd wordt voor het niet deel uitmaken van het OpenCL committee, terwijl het wel degelijk zal draaien op Windows, en Mac OS en Linux doen alsof Direct3D niet bestaat. Ik denk dat geen van de partijen hier iets te verwijten valt.

[drahca]

Leef jij in een parallel universum waar Microsoft geen patenten heeft over DirectX? De enige reden dat Cider bestaat is omdat het op dit moment veel te klein is voor MS om zich druk over te maken. Mocht het ooit gebeuren dat een Linux distro volledige DirectX ondersteuning biedt, dan zal MS heel snel een rechtzaak beginnen. In de patent-deal tussen Novell en MS is er N.B. een uitzondering opgenomen specifiek voor technologieen zoals WINE, Cider en Crossover. Op dit moment zou een rechtzaak niks opleveren behalve een fikse rekening en slechte PR. MS heeft trouwens ook een heleboel OpenGL gerelateerde patenten opgekocht van SGI toen het erg slecht met SGI ging. De enige reden dat ze deze patenten hebben is als een dreiging: doe iets met DirectX en wij slaan hard terug.

Meer praktisch, waarom zou de FOSS gemeenschap een compleet gesloten standaard gaan ondersteunen terwijl er al een goede open standaard is in de vorm van OpenGL waar de ondersteuning al niet al te best van is. Of zou je soms willen dat nVidia en ATI in hun binaire drivers voor Linux DirectX ondersteuning gaan bieden? (hint: dat zullen ze nooit doen, zij bemoeien zich niet met politiek)

Mijn punt is dat Microsoft hier bekritiseerd wordt voor het niet deel uitmaken van het OpenCL committee, terwijl het wel degelijk zal draaien op Windows, en Mac OS en Linux doen alsof Direct3D niet bestaat. Ik denk dat geen van de partijen hier iets te verwijten valt.

Ja hoor, praat het maar weer goed. Waarom is het nodig dat wanneer ergens een standaard voor is, in dit geval OpenCL, MS met een 'alternatief' komt. Intern zal MS nooit OpenCL gaan gebruiken, hun libraries zullen DX11 gaan gebruiken waardoor OpenCL buiten de deur wordt gehouden, tenzij je dit expiciet wil gebruiken. In feit zoals nu al het geval is met OpenGL, dat langzaam naar de achtergrond is gedrukt.

[Anoniem: 77640]

Leef jij in een parallel universum waar Microsoft geen patenten heeft over DirectX?

Kan je mij zo'n patenten tonen dan?

Je kan geen patenten nemen op een specificatie, enkel op een implementatie.

Meer praktisch, waarom zou de FOSS gemeenschap een compleet gesloten standaard gaan ondersteunen terwijl er al een goede open standaard is in de vorm van OpenGL waar de ondersteuning al niet al te best van is.

Ik denk dat je m'n punt gemist hebt. Ik suggereer helemaal niet om rechtreeks Direct3D te implementeren in Mac OS noch Linux. Ik wil alleen maar duidelijk maken dat Microsoft net zo weinig reden heeft om OpenGL en OpenCL als standaard te aanvaarden. Daarmee zouden ze de concurrentie steunen met hun zelfverkozen "standaard".

Bekijk het even vanuit beide kampen en er zijn echt niet zo veel verschillen. Microsoft-bashing is hier dan ook niet op z'n plaats.

[drahca]

Het verschil tussen de twee kampen is dat het ene kamp bestaat uit een collectie van bedrijven en organisaties die samen tot een standaard proberen te komen terwijl het Microsoft kamp slechts uit Microsoft bestaat. De enige reden dat ze hier weg mee kunnen komen is omdat ze een marktaandeel hebben van over de 90%. Hierdoor kunnen ze als een dictator iedereen hun wil opleggen (inclusief Ati en nVidia). Ze doen dit niet voor hun klanten, maar puur voor zichzelf zodat ze d.m.v. "vendor lock in" hun toekomst zeker stellen. Als MS een veel kleiner marktaandeel zou hebben, zou niemand hier over zeuren. Maar feit is dat Computer Shaders uit DX11 de facto succes zullen hebben. Concurrentie is er gewoon niet. En dat is geen Microsoft bashing. Microsoft toont iedere keer weer aan dat ze niet geinteresseerd zijn in standaarden. In plaats daarvan verzinnen ze hun eigen "standaard".

Vraag jezelf eens af of MS dit gedrag vertoont voor zijn klanten of voor zichzelf? Developers stonden echt niet te springen om DirectX toen dit uitkwam, net zo min als dat de developers nu staan te springen om DX11 Compute Shaders.

[Anoniem: 77640]

Het verschil tussen de twee kampen is dat het ene kamp bestaat uit een collectie van bedrijven en organisaties die samen tot een standaard proberen te komen terwijl het Microsoft kamp slechts uit Microsoft bestaat.

Veel 'kleintjes' (waaronder giganten zoals IBM, Intel, NVIDIA, AMD, ...) die samenspannen tegen één grote. Plaats je in de positie van Microsoft en vraag je eens af wie er dictatoriaal overkomt wanneer OpenCL tot standaard wordt vernoemd. Laat me je verzekeren, ze zijn allemaal even veel op winst uit en dat Microsoft zich niet volledig achter OpenCL schaart is net zo normaal als dat die andere geen DirectX implementeren.

Ze doen dit niet voor hun klanten, maar puur voor zichzelf zodat ze d.m.v. "vendor lock in" hun toekomst zeker stellen. Als MS een veel kleiner marktaandeel zou hebben, zou niemand hier over zeuren.

Wat is dat voor onzin? Je hebt nog altijd de vrije keuze om OpenGL en OpenCL te kiezen. Niks vendor lock in dus. Ze hebben eerlijk hun concurrerende positie verdiend door een superieure API te ontwikkelen, goed met de IHVs te praten en uitmuntende support aan developers te geven.

Vraag jezelf eens af of MS dit gedrag vertoont voor zijn klanten of voor zichzelf? Developers stonden echt niet te springen om DirectX toen dit uitkwam, net zo min als dat de developers nu staan te springen om DX11 Compute Shaders.

Yeah, de anderen doen het echt wel voor de klanten. Trouwens, de klanten zijn hier de developers, en die kiezen de beste API niet de meest open. En ja hoor velen wachten met spanning op compute shaders, dat naadloos integreert met de rest van DirectX. Of dacht je dat Microsoft het door onze strot komt duwen?

[drahca]

Goed, we verschillen van mening maar misschien niet zoveel als je lijkt te denken. Je haalt er meteen complottheorieen bij en gebruikt woorden als "samenspannen" voor commissies. Niks houdt MS tegen om in deze commisies deel te nemen, alleen ze weten dat ze meer macht hebben als ze niet samenwerken met de rest van de wereld.

DirectX is op dit moment (en helaas waarschijnlijk voor langere tijd) een veel betere API dan OpenGL. Dit heeft MS gewoon goed aangepakt. De documentatie van DX is ook gewoon helderder dan dit voor OpenGL is, zeker in corner cases. OpenGL 3.0 had op DX10 moeten lijken, maar door inertie van de CAD mensen is het nu een rare mengelmoes geworden waarin ik niet met plezier ga zitten programmeren. Maar ja, als je met cross-platform software te maken hebt, is DX helaas geen optie. Ik zou ook liever hebben dat MS DX vrij zou geven om te gebruiken op andere platformen, zoals SGI destijds deed met IrisGL, maar dat gaan ze niet doen.

Je zegt dat ik de vrijheid heb om keuzes te maken tussen standaarden, maar het punt dat ik probeer te maken is dat standaarden er nou net zijn zodat je die keuzes niet hoeft te maken. Als MS voor OpenGL had gekozen ipv zijn eigen API maken had ik wellicht niet hoeven kiezen tussen OpenGL en DX. Dan was er maar een driver waar ik rekening mee hoef te houden. Niet een goede DX driver en een slechte OpenGL driver. Toepasselijke uitdrukking: "The nice thing about standards is that there are so many to choose from." Ik zou MS alleen maar toejuigen als het eens een keer standaarden ging ondersteunen, ipv alternatieve standaarden te bedenken.

Op dit moment ben ik bezig met CUDA. Ik ben van plan deze over te zetten naar OpenCL, zodat het ook werkt op ATI kaarten. Hopelijk zal de ondersteuning van OpenCL door de GPU makers goed zijn en krijgen we geen situatie zoals nu met OpenGL waar alleen de drivers van nVidia enigzins goed te noemen zijn.

[kidde]

De enige reden dat ze deze patenten hebben is als een dreiging

Nee, dat is natuurlijk gedaan om te voorkomen dat mensen die OpenGL gebruiken buiten de invloedssfeer van Microsoft vallen. Anders zou OpenGL zich buiten Microsoft om tot een beter platform kunnen ontwikkelen dan DirectX; nu kan Microsoft dat simpel tegenhouden.

[kidde]

Dat het niet open is belet hen helemaal niet om het te implementeren. Hoe denk je anders dat Cider te werk gaat?

Dat belet het hen wel; meestal gaan projecten zoals dit te werk via clean-room engineering. De ene helft kijkt wat de API doet en maakt hier een beschrijving van. Immers; dat Microsoft van het gebruik van die API documentatie geeft wil ten eerste niet zeggen dat die bruikbaar is om een implementatie te maken en ten tweede niet dat die info ook klopt.
De andere helft maakt van deze beschrijving een implementatie. Een heel erg omslachtig proces; wat minstens10x zoveel werk is als zelf een implementatie schrijven. Meestal is het resultaat niet al te best en komt maar zelden in de buurt van het origineel; zie maar eens hoeveel moeite het bij Wine gekost heeft.

Ga maa na: Jij gaat ook niet 10 jaar lang een boek over ShaderX3 uit het Farsi naar het Nederlands vertalen als je nog moet beginnen met Farsi leren; hetzelfde boek heb je waarschijnlijk in 1 jaar geschreven.

[Anoniem: 77640]

Dat belet het hen wel; meestal gaan projecten zoals dit te werk via clean-room engineering. De ene helft kijkt wat de API doet en maakt hier een beschrijving van. Immers; dat Microsoft van het gebruik van die API documentatie geeft wil ten eerste niet zeggen dat die bruikbaar is om een implementatie te maken en ten tweede niet dat die info ook klopt.

Geen nood aan clean-room engineering. De documentatie gaat tot in het kleinste detail. En fouten in die documentatie komen zeer snel aan het licht door de applicatieontwikkelaars, wat publiek gemaakt wordt in menig forum, waarna Microsoft de documentatie bijwerkt (gebeurt iedere twee maand). Ze hebben zelf baat bij een zo accuraat mogelijk documentatie en veel developer support in de vorm van tutorials, MSDN artikels en voorbeeldcode.

De andere helft maakt van deze beschrijving een implementatie. Een heel erg omslachtig proces; wat minstens10x zoveel werk is als zelf een implementatie schrijven. Meestal is het resultaat niet al te best en komt maar zelden in de buurt van het origineel; zie maar eens hoeveel moeite het bij Wine gekost heeft.

Dat is niet mijn ervaring. Toen ik met swShader (nu SwiftShader) voor de keuze stond een OpenGL of Direct3D interface te schrijven heb ik resoluut Direct3D gekozen omdat de documentatie zoveel beter was. In minder dan een jaar had ik in m'n eentje Direct3D 8 geïmplementeerd en een deel van Direct3D 9 (niet enkel het interfacegedeelte maar ook de aanpassingen aan de software renderer en SoftWire).

Dat het zoveel langer duurt voor een project als Wine is dan ook grotendeels te wijten aan de grillen van OpenGL en de bijhorende driver(s) die als onderliggende renderer gebruikt wordt.

Je kan dan ook onmogelijk stellen dat Microsoft het enigzinds moeilijk maakt om Direct3D te implementeren.

[Anoniem: 47200]

[...]

Het is net waar je van houdt, wie zegt dat MS straks niet DirectX 11 als uniek onderdeel in windows 7 verweeft. Dit is tenminste een open standaard, daar zou microsoft er veel meer van moeten implementeren. Als Microsoft het niet doet zou altijd nog een opensource project/thrid party vendor het kunnen implementeren. Dat is het voordeel van open standaarden en het nadeel van directx. Je kunt mij nog steeds niet uitleggen dat directx 10 echt enkel op Vista kan draaien...

[Anoniem: 77640]

...wie zegt dat MS straks niet DirectX 11 als uniek onderdeel in windows 7 verweeft.

De laatste SDK bevat reeds de volledige specificatie van de Direct3D 11 API. En net als alle vorige versies is het helemaal niet verweven met Windows. Dus wie zich geroepen voelt kan nu reeds beginnen aan een implementatie op Mac OS of Linux...

Als Microsoft het niet doet zou altijd nog een opensource project/thrid party vendor het kunnen implementeren. Dat is het voordeel van open standaarden en het nadeel van directx. Je kunt mij nog steeds niet uitleggen dat directx 10 echt enkel op Vista kan draaien...

Klopt. Dat kan perfect. Dat is echter veel werk en tegen dat je klaar bent is Vista al goed geaccepteerd. Bovendien valt er niks aan te verdienen dus wie verwacht je daarin te investeren? Alle spellen hebben nog steeds een DX9 renderer, die weinig verschilt van de DX10 renderer.

Microsoft zal ook blijven verzekeren dat OpenGL op toekomstige versies van Windows draait. Daarvoor is de bestaande markt van OpenGL-applicaties te groot. Ze bieden dus méér keuze aan dan Mac OS en Linux en dat kan je ze moeilijk kwalijk nemen.

[kidde]

Bovendien valt er niks aan te verdienen dus wie verwacht je daarin te investeren?

Bedrijven / overheden die verder kijken dan hun neus lang is; die wel begrijpen wat vendor-lock-in en patentdreiging is; die niet afhankelijk willen zijn van Microsoft en haar weigeringen bepaalde informatie openbaar te maken. En geloof me; die zijn er.
Ga maar na: Waarom heeft Microsoft in OOXML geïnvesteerd terwijl er aan de gesloten formaten van tot Office2000 veel meer te verdienen viel? De bovengenoemde reden is het antwoord.

[Anoniem: 77640]

Ga maar na: Waarom heeft Microsoft in OOXML geïnvesteerd terwijl er aan de gesloten formaten van tot Office2000 veel meer te verdienen viel? De bovengenoemde reden is het antwoord.

Wrong. Omdat ze door zowel de open standaard als hun eigen formaten te ondersteunen voor iedere markt iets bieden. Resultaat: nog minder reden om van Windows/Office weg te keren. Het is vergelijkbaar met het Direct3D + OpenGL verhaal. Windows ondersteunt beide. Je krijgt én de meest innovatieve API én de open standaard, waarmee Microsoft succesvol meerdere partijen lokt (game developers, CAD, adacemische wereld., ..). En dat zonder enige vendor lock-in want je hebt nog steeds de keuze om de open standaard te kiezen. Dat die voor sommige zaken inferieur is hebben de verantwoordelijke committees alleen aan zichzelf te danken.

[Neko Koneko]

MS heeft al toegezegd dat Dx11 ook voor Vista beschikbaar zal zijn. Na al het gezeik om Dx10 kijkt MS wel uit om dat dit keer niet te doen.

En als je nu nog steeds niet doorhebt dat Dx10 niet op XP kan draaien vanwege het driver model dan heb je gewoon een bord voor je kop.

[SG]

Tuurlijk kan dat maar dan breng je het voordeel van LPLP call performance hit weer terug. Het nieuwe drivermodel werkt efficenter je bent dan op aplicatie niveau bezig.
Daarnaast vereenvoudig dX10 call waardoor de souce code wat meer leesbaarderwordt.

Veel DX10 features zijn meer op eenvoud gericht. Men denkt dus ook meer aan de developer. Zoals de Devicecaps overboard. En 'n gegarandeerde featureset en wat optioneel.

Doet me denken aan C# vs C++

[Anoniem: 77640]

En als je nu nog steeds niet doorhebt dat Dx10 niet op XP kan draaien vanwege het driver model dan heb je gewoon een bord voor je kop.

Direct3D 10 kan perfect voor XP geïmplementeerd worden. Ook door derden. Dat het geen gebruik maakt van hetzelfde driver model is geen belemmering, al kunnen de prestaties verschillen.

[kidde]

Na al het gezeik om Dx10 kijkt MS wel uit om dat dit keer niet te doen.

Al dat gezeik en hun klanten interesseert Microsoft geen {gat in de onderrug}; het gaat erom dat nú niemand Vista wil wat de aandeelhouders niet fijn vinden, en als straks nog niemand Vista wil gaan de aandeelhouders morren. Het niet ondersteunen van Dx11 in Vista zou een extra reden kunnen zijn waarom mensen geen Windows Vista willen.

[J.J.J. Bokma]

Eh, de eerste (en enige) browserwar had aan de andere kant Netscape, die *precies hetzelfde deed*. BLINK element, anyone?

[koenderoo]

Het verschil tussen Netscape en Internet Explorer was destijds dat Netscape zich aan geldende standaard hield die niet door Netscape zelf bedacht was en Internet Explorer een eigen variant er op na hield.
Het grote probleem was dat Microsoft daarmee een "standaard" opdrong die niet overeen kwam met de geldende standaard. Iets waar browsers als Netscape zich altijd tegen verzet hebben.
Overigens was het niet alleen Netscape aan de andere zijde, maar ook Opera en tal van andere kleine/onbekende browsers stonden tegenover Internet Explorer in deze war.

[SG]

Microsoft heerste toen in de IT markt. maar liet internet nog linksliggen. Netscape founder investeerde 5mil en maakte die nestcape browser. Die een groot sucses was. Zonder invloed van MS. MS werd wakker en ging hun tegen aanval in, op nogal illigale manier. Het gratis bundelen. En Netscape software ging dood na 2 miljard winst.
Jammer MS is mij te aggressief en vaker ten koste van de consument. Monopool moet je sowieso niet hebben.

MS streef ook standaarden na maar alleen onder alles wat MS is. Daar buiten dus niet. OpenCL is Crossplatform op veel groter niveau.

Dat met netscape doet me denken aan MS frontpage en Server Extensions.
Dat zou nu met breedband meer kans maken.

[mjtdevries]

beetje geschiedvervalsing. Netscape hield zich maar aan 1 standaard. Namelijk hun eigen standaard.

Andere clubs (voor zover die er toen al waren) negeerde ze compleet.
Ik denk dat jij alleen het Netscape kent van de tijd dat IE al groot was?

Maar toen Netschape nog verreweg de grootste was, gedroegen ze zich net zo als Microsoft.