Microsoft geeft C++ AMP-specificatie vrij

Microsoft heeft de C++ AMP-specificatie vrijgegeven. Hierdoor kunnen ook niet-Microsoft-compilers Accelerated Massive Parallelism gebruiken om gpu's aan te spreken. Microsoft stelt dat AMP relatief eenvoudig is te leren.

Microsoft introduceerde C++ AMP in juni vorig jaar voor Visual Studio 11. Bij de ontwikkeling van de specificatie kreeg de softwaregigant input van AMD en Nvidia. Programma's die met behulp van AMP zijn geschreven, kunnen direct toegang krijgen tot de cpu en Direct3D-compatibele gpu's.

Met het vrijgeven van C++ AMP hoopt Microsoft dat ook andere partijen de specificatie gaan gebruiken in hun compilers. Bovendien zou AMP als voordeel hebben dat ontwikkelaars geen specifieke gpu-kennis nodig hebben om de grafische processoren in hun creaties te kunnen aanspreken, omdat het sterk lijkt op 'vertrouwde' C++-code.

Microsoft belooft in zijn Microsoft Community Promise license dat het geen restricties zal leggen op C++ AMP. Ook belooft het softwarebedrijf in de toekomst geen gerelateerde patentclaims te zullen maken bij partijen die AMP toepassen, behalve als een partij een patentclaim tegen Microsoft indient.

Reacties (38)

[kimborntobewild]

Ook belooft het softwarebedrijf in de toekomst geen gerelateerde patentclaims te zullen maken bij partijen die AMP toepassen, behalve als een partij een patentclaim tegen Microsoft indient.

"behalve als een partij een patentclaim tegen Microsoft indient."
Wat moet je je daar in vredesnaam bij voorstellen?

[ThomasG]

Stel jij hebt een bedrijf en maakt gebruik van de AMP techniek, vervolgens verkrijg of koop jij een patent waar Microsoft (mogelijk) inbreuk op zou maken. Jij klaagt Microsoft aan wegens inbreuk op dat patent, dan klaagt Microsoft jouw dus aan voor inbreuk op AMP.

Je moet dit zien als een soort voorwaarde. Je mag 'gratis' van deze techniek gebruik maken, dus zonder licentie kosten te betalen, mits jullie ons niet voor van alles en nog wat aan klagen met betrekking tot patenten claims. Vind ik op zich een eerlijke deal.

Als je als bedrijf van plan bent om dit te gebruiken, en ook van plan bent om in de toekomst Microsoft met een patentclaim aan te klagen, doe je er dus verstandig aan om een licentie te nemen, mits dat natuurlijk mogelijk is.

[Reactie gewijzigd door ThomasG op 23 juli 2024 09:11]

[the_shadow]

Sterker nog: je mag MS prima aanklagen over een niet gerelateerde techniek, maar als jij AMP gebruikt, en je gaat MS vervolgens aanklagen over een patent wat jij zou hebben binnen AMP, dan verlies je je rechten en zal MS een tegenaanklacht indienen. Je moet dus redelijk rare sprongen uithalen wil je problemen krijgen met het gebruik van deze licentie structuur.

Zie ook mijn post met een kopie uit de FAQ.

[Reactie gewijzigd door the_shadow op 23 juli 2024 09:11]

[Marijn_]

Of het echt een eerlijke deal is valt over te twisten. Ik mag dus AMP gebruiken zolang ik maar niet moeilijk doe over het feit dat Microsoft mijn patenten schendt, als ik dat wel een probleem vind dan kan ik helaas niet meer met mijn concurrenten meekomen omdat ik geen AMP meer kan gebruiken. Ergens klinkt dat toch niet helemaal eerlijk, alleen maar omdat Microsoft een patent van mij schendt en dat bij mijn concurrenten niet deed. (Puur hypothetisch natuurlijk.)

Hoe dan ook is er vrijwel geen technologiebedrijf ter wereld dat een patentoorlog met Microsoft zal willen riskeren, aangezien Microsoft een dusdanig patentportfolio heeft dat ze vrijwel zeker zouden winnen. Dat zal ook de hoofdreden zijn dat bv. Apple fanatiek achter Samsung aan zit om dingen als "bouncy effects", maar er geen probleem van maakt als Microsoft die gebruikt. Ze zouden in een patentoorlog geen enkele kans hebben. (Mogen we nog van geluk spreken dat Microsoft er niet hetzelfde patentbeleid op na houdt als Apple.)

[Niemand_Anders]

Heel simpel, als jij AMP gebruikt en twee jaar merkt dat AMP een patent van jouw schend en jij klaagt Microsoft aan, dan komen zij met een counter claim.

Microsoft start overigens zeer weinig rechtszaken zelf. Meestal zijn zij de gedaagde. Zelfs open source projecten mogen de patenten gebruiken op een soort van gedoog basis. Zodra iemand de open source probeert te verkopen, komt Microsoft in actie. Google past Android momenteel niet toe op commerciele basis. Zij bieden alleen het platform aan. Partijen als Samsung en HTC gebruiken Android op commerciele basis en worden daarom door Microsoft gemaand om licenties te betalen voor de licenties. Indien deze niet worden betaald, stap Microsoft naar de rechter.

DirectX is al meer dan 15 jaar het platform om games voor te schrijven. Er zijn alternatieven zoals OpenGL, maar ruim 95% van de games welke verschijnt op de PC is geschreven met behulp van DirectX.

Je zag ook toen NVidia problemen had om de overstap naar DirectX 10 te maken, ATI (nu AMD) snel markt aandeel wist te winnen. Met AMP kunnen game developers gemakkelijk taken verplaatsen van de CPU naar de GPU. Dat betekend dat game developers nog beter gebruik kunnen maken van de videokaart en games daardoor theoretisch een performance boost kunnen krijgen.

Ik zeg bewust theoretisch omdat het sterk afhangt van de beslissing welke delen van de code verplaatst worden naar de GPU. Net als dat multicore CPU's vrijwel nooit lineair schalen, zal vermoed ik, de performance winst in het begin minimaal zijn. Na enkele jaren zal beter zijn uitgekristalliseerd welke processen welke wel goed door de GPU opgepakt kunnen worden en welke minder. Developers welke al met Cude of ATI Stream hebben gewerkt zullen hier meer ervaring mee hebben. De balans tussen extra overhead (thread synchronisaties, locking issues, etc) en performance winst moet daarbij goed worden bewaakt..

Ook vraag ik mij af in hoe verre hoe groot de vertraging is tussen hoe kopieren van een data structure uit het GPU geheugen naar het CPU geheugen. Het lijkt mij dat vooral de PCI bus hier een bottle neck kan vormen..

[Wolfos]

Probleem met multicore voor renderers is dat je het gevaar loopt dat 2 processen tegelijk in dezelfde buffer gaan schrijven en zo de gehele driver crashen.

[wpoely86]

En wat is het voordeel van dit tegenover OpenCL of Cuda? Waarom zou je gebruik maken van iets dat DirectX en Windows-only is terwijl er open standaarden bestaan die dit ook allemaal kunnen? IMO, kun je beter een laagje boven OpenCL of Cuda gebruiken om exact hetzelfde te doen maar dan cross platform.

[casparz]

Ars Technica legt het uit: http://arstechnica.com/mi...u-c-amp-specification.ars

Samengevat, C++-amp is hoger level en meer native C++ dan OpenCL native C is.

[Reactie gewijzigd door casparz op 23 juli 2024 09:11]

[SG]

En meer integraal en dus toegankelijker.

[Verwijderd]

Dat is meer een kwestie van smaak...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:11]

[Verwijderd]

dit IS een laagje boven OpenCL (of nouja, misschien meer een laagje boven je gpu), en dit IS potentieel multiplatform: het is een standaard, dus andere compilerbouwers zijn vrij om het te gebruiken.

en het lijkt me niet dat dit directx-only is, zie niet echt in wat het er mee te maken heeft..

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:11]

[wpoely86]

Het werkt voor het ogenblik enkel en alleen met DirectX 11. Als het geen DirectX 11 vind, dan gebruikt het enkel de cpu.

Dit is een ideetje van Microsoft, geen standaard zoals OpenCL. Achter OpenCL zit Khronos, een non profit organisatie die de standaard beheerd.

Ik denk dat het wel mogelijk moet zijn om zonder een extra standaard te introduceren, dit te doen als een laag bovenop OpenCL.

[.oisyn]

Het werkt voor het ogenblik enkel en alleen met DirectX 11

Omdat al de AMP implementaties die momenteel bestaan (welgeteld 1, die van MS) nou eenmaal met DirectX11 werken. Het mooie van het vrijgeven van deze specicatie is dat iedereen het mag implementeren. Er kunnen dus best CUDA en OpenCL implementaties komen.

[Verwijderd]

en dit IS potentieel multiplatform:

en OpenCL niet?

[Verwijderd]

ja, maar dat is lastiger dan iets als AMP gebruiken, aangezien je in OpenCL meer zaken 'handmatig' moet doen

[SG]

Het voordeel is dat de defacto standaard ontwikkel tool die game studios gebruiken nu extra lib voor gpgpu gebruik hebben die gebruikt maakt van de compute shaders.

En dat is MS VS series.

Cuda is kut omdat je dan nV spul alleen ondersteund waardoor die feature op de helft van de gamers bijzonder goed loopd maar op de andere terug moet vallen op de CPU.
Open CL heefd dit probleem ook niet maar loopt net zoals DirectX compute shaders achter op CUDA.

Wat in houd dat je basis feature altijd beperkt is tot CPU only. En non gameplay extra op die ene helft van de target markt benut kunnen worden.

Wat dit inhoud is dat dev.s die delen van games die zeer parralel zijn nu wel vaker op gpgpu kunnen laten lopen omdat dit stuk toegankelijker is.
En GpU merk onafhankelijk.
En geen CPU only noodloop of feature reductie voor gameplay moeten beperken.

Het probleem in de industrie is dat.
Havok van iNtel is dus GPGPU niet gebruik mag worden en dus Havok FX gekilled is door iNtel. En PhysX Cuda afgeleide OpenCL ook blijf mijden. Cuda als nV gpu sales pusher.

Dus platform on afhankelijkheid doet er in de gameindustrie eigenlijk totaal niet toe.
Windows met Directx heerst daar. Wat wel belangrijk is tools die GPU merk onafhankelijk zijn.

Die enkele uitzonderingen met OpenGL gaan dan voor OpenCL.

[the_shadow]

Ik zou zeggen: lees de Community Promise eens door. Daarin staat dat het gaat om een 'irrevocably promises', dus nee, ze kunnen die belofte niet opeens terugtrekken. Uit hun FAQ:

Q: Is this CP legally binding on Microsoft and will it be available in the future to me and to others?
A: Yes, the CP is legally binding upon Microsoft. The CP is a unilateral promise from Microsoft and in these circumstances unilateral promises may be enforced against the party making such a promise. Because the CP states that the promise is irrevocable, it may not be withdrawn by Microsoft. The CP is, and will be, available to everyone now and in the future for the specifications to which it applies. As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding a Microsoft implementation of the same Covered Specification. This type of “suspension” clause is common industry practice.

Dus, als je de CP gebruikt, dan kan dat, maar op het moment dat jij MS gaat aanklagen over een patent kwestie die betrekking heeft op het product wat je gebruikt. Met andere woorden: je kan de verschillende taalspecificaties gebruiken, maar als jij Microsoft gaat aanklagen dat de betreffende specificatie inbreuk maakt op een patent, dan verlies je het recht om de specificaties te gebruiken en wordt je om die reden aangeklaagd door MS.

[MSalters]

Klinkt mooier dan het is. Stel dat Microsoft begint met jou aan te klagen over een ongerelateerd patent. Veel grote bedrijven reageren dan door eens met de stofkam door hun eigen patentportfolio te gaan, om te kijken of Microsoft misschien een van hun patenten overtreed. Dan kun je namelijks stilletjes wederzijds schikken.

Met deze "Community Promise" vergroot Microsoft de patentstael indirect. Na jouw tegenactie op hun eerste rechtzaak kan Microsoft opeens de Community Promise vergeten, en nog veel meer rechtzaken aanspannen. Die zijn dan ineens niet meer te schikken. Bedrijfsjuristen zijn minder onder de indruk van dit soort beloftes.

[humbug]

Tsja, dan kun je als bedrijf de patenten niet gebruiken die betrekking hebben op die "Covered Specification". Je kiest er echter wel zelf voor de door Microsoft gepatenteerde techniek te gebruiken. De logica is simpel: "Maak je er gebruik van, kun je ons niet aanklagen voor de onderliggende techniek". Net als Microsoft jou kan aanklagen voor het gebruik van andere patenten, kan jij Microsoft gewoon nog aanklagen voor andere patenten.

Even afgezien van de situatie waarbij Microsoft stilletjes jou patenten gebruikt in nieuwere versies van het product (die volgens mij onder een andere "covered specificatiën" zouden moeten vallen) is hier niets mis mee. Ja, er zitten restricties aan het gebruik maar dat lijkt me niet meer dan logisch.

[arjankoole]

Ik beloof dat ik je niet zal vervolgen. Neen echt. Beloofd. Of wacht. Ik heb me zonet bedacht. Ik ga je toch maar vervolgen.

Dat kan dus niet. als Microsoft bij de rechter komt met de mededeling: ik heb me bedacht, dan zegt de rechter: dat is jouw probleem, Microsoft. Opdonderen uit m'n rechtzaal.

[mad_max234]

[...]


Dat kan dus niet. als Microsoft bij de rechter komt met de mededeling: ik heb me bedacht, dan zegt de rechter: dat is jouw probleem, Microsoft. Opdonderen uit m'n rechtzaal.

Zo werkt dat niet, maker van de code blijft gewoon alle rechten houden en ook het recht om toekomstige toestemmingen te weigeren. Rechter zal dan zoiets hebben je heb geluk gehad dat je het voor tijdje heb mogen gebruiken maar je hebt verder geen recht om iets af te dwingen want je niet de rechthebbende van de code en je hebt geen contract getekend met da makers.

[humbug]

De licentie van software kan je niet achteraf wijzigen. Je kan wel een update uitbrengen met een andere licentie maar gebruikers die die update niet toepassen houden alle rechten die men had. Zou een mooie boel worden als licenties achteraf eenzijdig gewijzigd kunnen worden. Een licentie is namelijk gewoon een contract.

[FireDrunk]

Dus jij als klein ontwikkelbedrijfje van 10 man, gaat dat risico lopen om tegen een van de grootste bedrijven ter wereld te staan in de rechtzaal?

Precies....

[Mellow Jack]

Een rechtszaak is zo duur als je het zelf maakt. Op het moment dat jij aan de hand van een licentie of voorwaarde kan aantonen dat jij volledig in het recht staat ben je maar een X aantal juridische dagen kwijt zonder dat je extreme kosten hoeft te maken.

Ga je het gebruiken zonder licentie of voorwaarden (of met voorwaarden die eenzijdig veranderd kunnen worden) dan ga je tegen flinke kosten aanlopen en gaat het jaren duren voordat je een resultaat hebt

[LeVortex]

Er staat toch al een duidelijke if statement in het artikel?? Dus alleen als je een patentclaim indient tegen Microsoft krijg je een claim terug. Wat is daar mis mee? Duidelijk omlijnd dacht ik zo?

Zie het voordeel niet echt trouwens, misschien mensen die geen visual studio gebruiken, maar ik zou niet weten waarom je geen visual studio gebruikt (tenminste voor mezelf)

[Verwijderd]

/me mompelt iets over multiplatform

[humbug]

Aangezien het gebruik maakt van DirectX kun je dat vergeten. Ook is het helemaal niet interessant voor Microsoft om software multiplatform uit te brengen. Maar ik gok dat je dat wel begrijpt.

Belangrijker is de vraag of je wel alles maar multiplatform wil hebben. Het is voor ontwikkelaars (veel) meer werk en multiplatform applicaties kunnen niet 100% gebruik maken van de features van de verschillende OSen. Je krijgt dus vaak een saaie middelmatige applicatie die net niet lekker werkt. Ik kan ontwikkelaars die kiezen voor een bepaald platform en daar hun applicaties voor optimaliseren dan ook goed begrijpen.

[Verwijderd]

valt nogal mee, als je multiplatform libraries gebruikt is het nauwelijks extra moeite om multiplatform te compileren (heb hier ervaring mee). optimaliseren kost wellicht een beetje moeite, maar het valt echt nogal mee..

en dat de enige AMP implementatie die er nu is gebruikt maakt van dx wil niet zeggen dat dat zo blijft

[Zoijar]

Zie het voordeel niet echt trouwens, misschien mensen die geen visual studio gebruiken, maar ik zou niet weten waarom je geen visual studio gebruikt (tenminste voor mezelf)

Ik snap die opmerking niet helemaal. Zeg je nou dat iedereen eigenlijk visual studio zou moeten gebruiken? En is dat dan alles inclusief compiler, of alleen de IDE? Want brakke en late C++2011 support zou al een rede zijn om niet de microsoft C++ compiler te gebruiken. De volgende, aankomende VC11 komt op dat gebied niet in de buurt van de huidige GCC bijvoorbeeld.

Verder als dit alleen op windows zou draaien (visual studio) dan zal het nooit aftrek vinden in de wetenschappelijke wereld, juist het toepassingsgebied bij uitstek voor dit soort parallellisatie -- dan houdt iedereen het wel bij OpenCL of CUDA.

[John_Glenn]

Met een beetje meer tekst en uitleg bij je rant zou je misschien niet zo hard weggemod worden... http://www.softwarefreedom.org/resources/2008/osp-gpl.html

Microsoft makes its promise “irrevocably,” but upon careful reading of the entire OSP, this promise is weakened considerably in the definition of Covered Specifications. In that provision, Microsoft clarifies that: "New versions of previously covered specifications will be separately considered for addition to the list."

[Reactie gewijzigd door John_Glenn op 23 juli 2024 09:11]

[humbug]

Ik zie dat toch anders. Het feit dat nieuwe versies onder een andere licentie vallen betekent dat bedrijven bij inbreuk op hun patenten Microsoft kunnen aanklagen zonder hun rechten op de oude versie te verliezen. Ook geeft dat Microsoft de mogelijkheid haar beleid in de toekomst te wijzigen.

Daarnaast: Je krijgt dus het recht op versie x maar niet automatisch op versie y. Is de essentie van de software industrie nu juist niet dat je voor elke nieuwe versie een nieuw contract moet afsluiten? Dus wat is hier zo bijzonder en slecht aan?

[John_Glenn]

Het is denk ik niet slecht in de zin van "evil"; uiteraard is het MS' goed recht om met nieuwe versies te doen wat ze willen.

Maar het is wel een slechte zaak als je gebruiker van deze standaard wil worden, en je graag wil werken met een GPL-compatibele implementatie ervan (even veronderstellend dat die er zou zijn). Dat betekent namelijk dat:

• jouw team een (waarschijnlijk aanzienlijke) investering doet om goed met AMP overweg te leren kunnen - wat de optimale idiomen zijn, welke valkuilen (die elke toolkit heeft) je moet vermijden, en ook gewoon: de functienamen in je hoofd stoppen...
• je straks met een hele rits broncode zit die niks waard is zonder AMP
• je vervolgens het risico loopt dat MS, en dus het grootste deel van de desktop-wereld, doorgaat naar versie zoveel maar daar geen vrije licentie meer op geeft, en jij dus achterblijft bij een oude versie, die misschien wel problemen heeft, of niet meer zal werken op nieuwere GPUs, of... noem maar op.

...dan had je je tijd vast beter in een ander GPGPU-pakket kunnen steken? Vandaar de waarschuwing.

[MtC]

Het wegmodden is wss gewoon een oh-iets-negatiefs-moet-wel-een-fipo-zijn reactie, en begrijp ik ook wel. Alleen jammer dat mensen niet de moeite nemen om zich even in te lezen en eens even kritisch na te denken.
Aan iedereen die zegt "jamaar, er staat dat het niet kan wijzigen": Licenties/EULA's/policies wijzigen nooit he?

[.oisyn]

Een goede reactie is onderbouwd en verwacht niet van de lezer dat hij zich eerst inleest alvorens hij de reactie op waarde kan schatten. In dat opzicht is het gewoon niets meer dan een ongefundeerde rant (score: 0). Gooi daar wat krachttermen in en je wordt al snel (terecht) gedownmod (score: -1).

[Paul - K]

Waarschijnlijk zodra iemand iets commercieels ermee gaat doen

[Verwijderd]

prima concept, maar ik hoop ook dat het ondersteund gaat worden door gnu c++.. lijkt me wel fijn als we multiplatform kunnen gpu coden!

lijkt me wel duidelijk dat er vraag is naar het concept; het is echt een pain in the *ss om de hele tijd handmatig stukjes geheugen over en weer te sturen van c++ naar openCL. zou fijn zijn als dat transparanter kon, en als ik het goed begrijp is dit waar AMP voor bedoeld is

[Reactie gewijzigd door Verwijderd op 23 juli 2024 09:11]

[Verwijderd]

Ondersteund dit ook interops met OpenGL?