AMD wil Mantle-code in OpenGL Next laten opnemen

AMD hoopt dat zijn nauwe samenwerking met de Khronos Group, verantwoordelijk voor standaarden rondom OpenGL, het mogelijk maakt dat er onderdelen van Mantle in de nieuwe low-level cross-platform-api OpenGL Next worden opgenomen.

De Khronos Group heeft eerder deze week aangegeven dat het werkt aan een nieuwe api als opvolger van OpenGL. De 'OpenGL Next'-api moet, net als AMD's Mantle-api en Microsofts DirectX 12, het mogelijk maken om de gpu directer aan te spreken. Dit ontlast de cpu en kan zorgen voor betere prestaties.

Omdat OpenGL Next van de grond af opgebouwd zal worden, wil AMD zijn invloed en kennis aanwenden binnen de Khronos Group. Richard Huddy van AMD laat aan Techreport weten dat het de ontwikkelaars van de Khronos Group volledige inzage heeft gegeven in Mantle. Bovendien mag kosteloos elk deel van de code hergebruikt worden voor OpenGL Next, zo beweert Huddy.

Het is nog onduidelijk hoeveel code OpenGL Next zal 'lenen' van AMD; het project staat nog in de kinderschoenen en onduidelijk is nog hoe lang het traject tot de eerste specificatie zal zijn.

Huddy laat ook zijn licht schijnen op DirectX 12 en de toekomst van Mantle. Volgens de AMD-medewerker is DirectX 12 direct beïnvloed door de release van Mantle. Ook laat hij weten dat 75 ontwikkelaars bij AMD werken aan het aanpassen van speltitels voor Mantle. Verder stelt Huddy dat AMD's api niet zal wegzakken als Microsoft DirectX 12 uitrolt. Zo zou AMD veel sneller Mantle kunnen updaten om nieuwe gpu-features te ondersteunen, terwijl DirectX gemiddeld pas elke 4 à 5 jaar een grote update krijgt. Ook ondersteunt Mantle Windows 7, terwijl nog onzeker is of DirectX 12 dat zal doen.

AMD wil met Mantle nog een extra stap zetten door binnenkort ook een release voor workstations uit te brengen. Zo moeten ook FirePro-videokaarten via Mantle aangestuurd kunnen worden. Een aantal niet nader genoemde softwarefabrikanten zou al hebben toegezegd de api te zullen ondersteunen.

Reacties (97)

[Verwijderd]

Grappig om te zien hoe er nu een wirwar aan API's ontstaan om de graphics hardware op een lager niveau aan te sturen dan voorheen (Apple Metal, OpenGL Next, Microsoft etc). Terwijl het er in de praktijk op neerkomt dat Gamestudio's gewoon een renderengine van een derde partij pakken. Deze renderengines zullen dan geporteerd moeten worden naar deze nieuwe low level API's lijkt me.

[player-x]

Die wirwar is vooral ontstaan omdat MS weer eens op zijn handen was blijven zitten met DX11, net zo als bij IE6, en dan op een gegeven moment is de maat vol bij velen, en beginnen vele aan iets te werken, en in dit geval is AMD echt de voortrekker.

Ik hoop dan ook ten zeerste dat de Khronos Group zoveel mogelijk van Mantel over nemen, het liefst 1 op 1, daar AMD dit imho gewoon verdient,door altijd open standaarden te ondersteunen.

Ook is het een goede afstraffing voor zowel MS als nVidia, MS vooral omdat ze gewoon weer lui zijn geweest, en nVidia omdat ze de concurrentie buiten willen houden door alles met eigen standaarden af te schermen.

Daarnaast zou het voor game ontwikkelaars een plus zijn als cross platform standaard als OpenGL een echt alternatief word om games voor te ontwikkelen.

Wat ik me wel afvraag is of deze trend juist voor meer of juist minder videokaart merk afhankelijke titels zal zorgen.

[Reactie gewijzigd door player-x op 23 juli 2024 18:39]

[Verwijderd]

Wat een ongelooflijke geleuter. Typische MS bashing zonder enige kennis van zaken.

DirectX is gewoon heel erg up-to-date wat betreft de hardware. Maar het is een standaard voor alle hardware, en dus kan het nooit zo snel ontwikkelen als een proprietaire standaard die maar op één merk hardware werkt.

De voordelen van Mantle zijn nogal overtrokken... Ja, het levert een betere communicatie tussen cpu en gpu, waarbij vooral de cpu onlast wordt. In de praktijk is de cpu echter helemaal de bottleneck niet, maar de gpu. Daarom dat Mantle in de praktijk ook maar heel weinig prestatie winst levert. Alleen mensen met relatief oude cpu's, maar moderne gpu's zien daadwerkelijk winst. Iemand met een up-to-date cpu ziet nauwelijks winst. De cpu's zijn sneller en goedkoper dan de gpu's nodig hebben.

Natuurlijk is het fijn wanneer zaken nog sneller gemaakt kunnen worden... maar andere zaken in DirectX hadden veel grotere prioriteit, zoals bijvoorbeeld het verbeteren van de multi-threading.

DirectX is sowieso geen pure Microsoft aangelegenheid. De ontwikkeling van DirectX wordt in zeer nauwe samenwerking met hard- én software fabrikanten gedaan. Je kunt dus niet de schuld aan Microsoft geven wanneer je vindt dat DirectX niet snel genoeg ontwikkeld.

[player-x]

Wat een ongelooflijke geleuter.

Wat een vriendelijke omschrijving van mijn post, maar goed je mag je mening hebben, net zo als ik die heb over jouw post.

Typische MS bashing zonder enige kennis van zaken.

Ooo.. Oke.. , een kritische mening hebben over wat MS soms doet is dus meteen bashing.

DirectX is gewoon heel erg up-to-date wat betreft de hardware.

Zeg ik ergens dat DX dat niet is, wat ik zeg is dat de manier hoe de API werkt achterhaald is, blijkens met de komst van Mantle en de reacties daar op, MS ook weer werk is gaan steken in vernieuwing in hun eigen API, ipv het min of meer door ontwikkelen van de oude DX11 techniek.

De voordelen van Mantle zijn nogal overtrokken... Ja, het levert een betere communicatie tussen cpu en gpu, waarbij vooral de cpu onlast wordt. In de praktijk is de cpu echter helemaal de bottleneck niet.

Ik geloof dat je ze behoorlijk onderschat zelfs, de meeste mensen spellen games niet op een i5 4690K of i7 4790K en een 290X of 780Ti (CF/SLI), maar op veel goedkopere en/of oudere hardware.

DirectX is sowieso geen pure Microsoft aangelegenheid. De ontwikkeling van DirectX wordt in zeer nauwe samenwerking met hard- én software fabrikanten gedaan. Je kunt dus niet de schuld aan Microsoft geven wanneer je vindt dat DirectX niet snel genoeg ontwikkeld.

Dus wat jij zegt is dat AMD Mantle geheel uit zich zelf heeft ontwikkeld zonder eerst MS zijn medewerking te vragen?

Ik kan daar voor natuurlijk geen tegen bewijzen vinden, maar ik betwijfel het hard dat AMD is begonnen zonder eerst samenwerking te vragen van Microsoft.

Zo als ik het zie is dat MS weer echt werk in vernieuwing is gaan stekken, pas nadat andere niet meer wouden wachten op MS, en op zich zelf waren begonnen met het ontwikkelen van nieuwe API's.

Als jij dat ongelooflijke geleuter en typische MS bashing zonder enige kennis van zaken vind is dat jouw mening.

Want hoewel ik zeker geen fan van MS ben, ben ik nog minder een MS hater, en heb zeer verschillende meningen over MS producten, van uitstekend (WP8.1 W8, Metro en 2012R2 server), tot zeer matig (Metro op de desktop), en heb geen problemen met het kopen van MS producten.

Op geheel persoonlijke mening vind ik jouw post dus toch meer naar fanboys gedrag ruiken, dan dat ik de mijne als bashen bestempelen, maar dat ik die wel zeker als kritisch bestempel.

[Verwijderd]

Dus wat jij zegt is dat AMD Mantle geheel uit zich zelf heeft ontwikkeld zonder eerst MS zijn medewerking te vragen?

Ik kan daar voor natuurlijk geen tegen bewijzen vinden, maar ik betwijfel het hard dat AMD is begonnen zonder eerst samenwerking te vragen van Microsoft.

AMD werkt sowieso samen met Microsoft. Ze zitten immers allemaal in de DirectX-commissie.

De reden dat AMD toch op eigen houtje Mantle is gaan ontwikkelen zou bijvoorbeeld kunnen zijn:
1) DX12 gaat in een richting die niet gunstig is voor AMD, dus voelt AMD zich genoodzaakt om zelf met een alternatief te komen.
2) DX12 komt pas eind 2015 op de markt, AMD kan dus een voorsprong nemen door nu al ongeveer hetzelfde te leveren voor hun eigen hardware.

Vooral qua marketing is Mantle op dit moment een enorm succes: iedereen heeft het over AMD en Mantle. Om die reden alleen al zou AMD het gedaan kunnen hebben.

Zo als ik het zie is dat MS weer echt werk in vernieuwing is gaan stekken, pas nadat andere niet meer wouden wachten op MS, en op zich zelf waren begonnen met het ontwikkelen van nieuwe API's.

Dat lijkt mij zeer onwaarschijnlijk, omdat MS binnen iets van 2 maanden na AMD's eerste Mantle-release al kwam met werkende demonstraties, nota bene op hardware van nVidia ipv AMD.
Microsoft en nVidia kunnen echt niet zo snel reageren. Er gaat maanden overheen voordat ze een beetje een goede API hebben afgesproken, en daar goede drivers voor zijn, en dat er daadwerkelijk iets als 3dmark of Forza naar geport kan worden.

[SG]

Ik denk eerder dat MS deze API op meerdere platformen dus ARM en X86 en X86-64 en naast NV intel en AMD ook mobile Soc en hun GPU moet ondersteunen zo ook al hun OS API voor alle hun platformen. En een API voor alle.

Ik denk dat enkele Dev dat mogelijk vonden dat dat te lang zou duren. En misschien wel gehoor hadden. In wat voor tijd span AMD zelf een API zou uitbrengen maar veel eerder. Kan zo een tot twee jaar schelen.

[Verwijderd]

Ik denk eerder dat MS deze API op meerdere platformen dus ARM en X86 en X86-64 en naast NV intel en AMD ook mobile Soc en hun GPU moet ondersteunen zo ook al hun OS API voor alle hun platformen. En een API voor alle.

Dat lijkt mij ook. DirectX 11.1 was al 1 API voor de desktop, tablet, smartphone en game console. De opvolger zal natuurlijk ook compatible moeten zijn met al die platforms.

Ik denk dat enkele Dev dat mogelijk vonden dat dat te lang zou duren. En misschien wel gehoor hadden. In wat voor tijd span AMD zelf een API zou uitbrengen maar veel eerder. Kan zo een tot twee jaar schelen.

Ja, wat dat betreft denk ik dat AMD het een beetje heeft onderschat. Ze hebben gezegd dat Mantle 'mogelijk' nog dit jaar beschikbaar wordt voor ontwikkelaars buiten het gesloten beta programma.
Microsoft heeft ook al aangekondigd dat DX12 later dit jaar in een technology preview beschikbaar wordt.
Als beiden rond hetzelfde moment beschikbaar worden, heeft Mantle eigenlijk al verloren. Ontwikkelaars weten sowieso zeker dat DX12 eind 2015 voor iedereen beschikbaar is. Dus alle games die een release rond die tijd hebben, kunnen alvast ontwikkeld worden met de vroege DX12-versie die later dit jaar komt.
Het heeft dan geen nut om ook nog tijd in Mantle te gaan steken.

[Vayra]

Waar halen mensen toch dat fabeltje vandaan dat de CPU geen bottleneck is of kan zijn?

Speel een willekeurige MMO, speel een sim of bouw-game... je kunt nog steeds talloze (ook nieuwe) releases vinden die zwaar CPU bound zijn. Daar heb je op een leeg speelveld 240 FPS en na twee uurtjes bouwen of het inladen van een drukke area zit je onder de 60 en met pech onder de 30 fps. Zonder dat lagere grafische settings daar ook maar 1 FPS aan gaan toevoegen. En juist bij cloud-based en online gaming wordt er ook een wissel getrokken op de CPU, veel meer dan eenzelfde game in singleplayer. En dat is dé groeimarkt voor elke publisher.

Bovenstaande is ook exact de reden dat voor gaming een Intel zoveel meerwaarde heeft. We hebben nog STEEDS te maken met overwegend single threaded games, zeker binnen de Indie-wereld, en DX11 begint ook daar nu door te sijpelen, en ook daar zie je dat men tegen problemen aan loopt en dat optimization veel hindernissen herbergt. Lagere CPU overhead is voor AMD dus een directe performance boost op hun APU's en CPU's voor gaming, wat past bij de positie van de A4-A10 procs bijvoorbeeld. Al met al heeft AMD dus meer belang bij het reduceren van CPU overhead dan Intel.

Met betrekking tot Mantle / DX12 geloof ik niet zo in dit complotdenken of de gedachte dat MS de boel traineert. Ze zijn nota bene console en game fabrikant, kom op zeg, en ze hebben een marktaandeel dat bijna dwingt tot het in stand houden van zo'n API.

Ik denk dat het gewoon zo is, zoals dat met bijna elke innovatie gaat, dat meerdere mensen rond hetzelfde moment op dezelfde ideeen kwamen, of dat techniek, de tijdsgeest of de situatie op de markt op of rond hetzelfde moment nieuwe wegen opent. En dat is ook niet toevallig. Soms heb je maar één woord nodig om een briljante vinding te doen die misschien al jaren voor je neus bungelde als 'the obvious way forward'. En meestal moeten de neuzen een bepaalde kant op staan voordat vindingen opeens wél als rendabel worden beschouwd.

Tot slot: de gedachtegang dat het één het ander uitsluit is ook niet realistisch. Iedereen is gewoon leentjebuur aan het spelen en onderaan de streep is het allemaal hetzelfde met een ander labeltje. Dat weet ik omdat de markt dat zal afdwingen. Mark my words.

[Reactie gewijzigd door Vayra op 23 juli 2024 18:39]

[SG]

Nou het gaat om de overhead van de render anstractie laag en niet optimaal ondersteuning van multi treaded. Eigenlijk mijden de devs dag gezien het nogal tegen valt. Maa dat is puur de rendering.

AI Physics en grote aantallen objecten of game entitys gaat dit niet over.
Maar uiteraard wel belangrijk voor gamers. Is je game van nature al extreem CPU afhankelijk dan ga je voor krachtige CPU.

Zo deed ik dat ook voor de novalogic voxel engine bases software renderer games ik had toon PIII 450Mhz daarvoor gekocht.

Maar de gross van de games leunen meer of het grafische en online is meer lag gelimiteerd dus ik zou die Haswell E eerder halen om weer 5 a 10 jaar met cpu update klaar te zijn. Geen geld een AMD APU A10 7850K doet ook met midrange gkaartje en dan is optimale API wel mooi meegenomen.

Ten eerste moeten die dev sowieso rekening houden met een grote mainstream target platform. Dus zo extreem zal het niet worden.

[Caelorum]

Die wirwar is ontstaan omdat MS weer eens op zijn handen was blijven zitten met DX11, net zo als bij IE6, en dan op een gegeven moment is de maat vol bij velen, en beginnen vele aan iets te werken, en in dit geval is AMD echt de voortrekker.[...]

De rest van de industrie was anders ook niet echt super bezig. Er waren nog geen andere API en Khronos was ook nog niet echt geweldig bezig met openGL.

[player-x]

Is dat niet wat ik zij?

en dan op een gegeven moment is de maat vol bij velen, en beginnen vele aan iets te werken, en in dit geval is AMD echt de voortrekker.

Iedereen liep te klagen, en iedereen was balletjes aan het opgooien, maar het was AMD dat echt de bal aan het rollen bracht, door gewoon Mantel ook echt uit te brengen.

[Caelorum]

Nee, je liet het overkomen alsof het allemaal de schuld van Microsoft is, maar de rest van de industrie die gezamenlijk aan OpenGL bijdragen deed ook niet echt veel. Ja, AMD was uiteindelijk de eerste die iets openlijk uitbracht, maar de hele situatie is niet alleen doordat MS weinig deed.

[player-x]

maar de hele situatie is niet alleen doordat MS weinig deed.

Sorry maar imho als PC gaming leider met een bijna 100% marktaandeel, was het juist wel MS's taak om voor meer innovatie te zorgen.

En ook de komst van de Win 8 Xbox Live and Windows Store was niet echt een motivatie voor veel ontwikkelaars.

[Verwijderd]

Je kunt niet voor iedere zucht een nieuwe API uitbrengen.
Het kost ontwikkelaars veel tijd om een engine voor een nieuwe API te ontwerpen en implementeren. Ook GPU-makers hebben hun drivers niet altijd meteen goed op orde. Daarom is het nogal belangrijk dat een API een tijdlang zonder grote wijzigingen bestaat.
MS heeft wel degelijk twee keer een kleinere update aan de API gedaan, namelijk met D3D11.1 en D3D11.2.

Maar een rigoreuze stap als met DX12, dat kun je niet zomaar even doen. Dat moet je goed met alle partijen afstemmen.

AMD heeft het wat dat betreft een stuk makkelijker: Mantle draait maar op een klein aantal GPUs, en wordt maar door een paar ontwikkelaars gebruikt. Dan kun je sneller stappen maken, maar dat vertekent het beeld natuurlijk wel.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[player-x]

Dat APIs niet jaarlijks moeten veranderen is natuurlijk correct, maar als top ontwikkelaars als Carmack en Romero al jaren geleden vroegen om een betere API die dichter bij de hardware zit, ben je imo gewoon laks bezig, en als AMD niks had gedaan, was er nu nog steeds niks veranderd.

AMD heeft het wat dat betreft een stuk makkelijker: Mantle draait maar op een klein aantal GPUs, en wordt maar door een paar ontwikkelaars gebruikt. Dan kun je sneller stappen maken, maar dat vertekent het beeld natuurlijk wel.

Nee hoor Mantle is gewoon een open API, die nVidia ook kan gebruiken, en Intel zelfs wil gebruiken.

Het was juist andersom een stuk gemakkelijker, om voor MS DX12 te ontwikkelen, daar als ik het goed zie, Mantle en DX12 nog veel meer afhankelijk zijn van de driver en de game ontwikkelaar, en MS vooral de API frame-work moet omschrijven.

[Verwijderd]

Dat APIs niet jaarlijks moeten veranderen is natuurlijk correct, maar als top ontwikkelaars als Carmack en Romero al jaren geleden vroegen om een betere API die dichter bij de hardware zit, ben je imo gewoon laks bezig, en als AMD niks had gedaan, was er nu nog steeds niks veranderd.

Carmack? Die kerel kletst enorm uit z'n nek. Hij heeft nooit serieus iets gedaan met Direct3D, dus waar hij zijn meningen op baseert, weet ik niet.
Wat ik wel weet is dat veel van zijn uitlatingen de laatste jaren echt nergens op sloegen. Klonk echt alsof hij sinds D3D9 niet meer naar de API heeft gekeken, en de dingen die hij als argumenten aanvoerde, waren in D3D10/11 al lang opgelost.

Daarnaast is Carmack sowieso niet geloofwaardig, want ironisch genoeg was de eerste versie van Direct3D *juist* een low-level API zoals waar we nu weer naartoe gaan met z'n allen.
Carmack ging toen huilen dat de super high-level OpenGL API veel makkelijker te gebruiken was dan D3D. Dus heeft MS op aanraden van oa Carmack zelf D3D meer high-level gemaakt, en meer op OpenGL laten lijken.

Nee hoor Mantle is gewoon een open API, die nVidia ook kan gebruiken, en Intel zelfs wil gebruiken.

Ja, net als Cuda... tuurlijk!
Verder, Intel wil dat helemaal niet gebruiken. Baseer je dat op die ene prive-tweet van Andrew Lauritzen? Wat een onzin.

[Sando]

Best wel felle woorden voor iemand met zo weinig bronnen. Just saying. Het enige wat voor Tweakers die iets verder van de technische details weg staan duidelijk wordt uit jouw post is dat je nogal fan bent van Direct3D, en niet van Carmack. Misschien terecht, misschien niet, feitelijk blijft dat in het midden. Nu heeft het iets weg van een mening, en dat kan op zich wel iets vriendelijker.

[Reactie gewijzigd door Sando op 23 juli 2024 18:39]

[Verwijderd]

dat je nogal fan bent van Direct3D, en niet van Carmack.

Ik ben niet zozeer fan van Direct3D, maar de uitlatingen van Carmack werken nogal als een rode lap op het ongeinformeerde publiek. Die hebben jarenlang ten onrechte met OpenGL gedweept omdat meneer Carmack dat zei.

en dat kan op zich wel iets vriendelijker.

Mwah, Carmack heeft meerdere malen behoorlijk fel uitgehaald tegen Microsoft en Direct3D, wat vrij onterecht was.
Maargoed, als je een bron wil, wat vind je hiervan? http://www.alexstjohn.com...arly-direct3d-com-opengl/
Alex St John is zelf een DirectX-ontwikkelaar van het eerste uur.

[player-x]

Carmack? Die kerel kletst enorm uit z'n nek. Hij heeft nooit serieus iets gedaan met Direct3D, dus waar hij zijn meningen op baseert, weet ik niet.

Sterke menig van iemand die in tegen stelling van Carmack totaal geen aantoonbare ervaring heeft.

En daarnaast zij ik niet Carmack maar:

maar als top ontwikkelaars als Carmack en Romero al jaren geleden vroegen om een betere API die dichter bij de hardware zit

Ik had het dus zeker niet alleen over hem maar ook over andere ontwikkelaars.

Ik heb een jaar of 5 geleden een interview gelezen waar Carmack, Romero en Sweeney aan het discuteren waren, en een van de dingen waar ze het alle drie over eens waren was dat APIs meer low level moesten worden.

Ja, net als Cuda... tuurlijk!

Cuda is nVidia only, waar Mantle voor en door iedereen te gebruiken is, en hebben trouwens helemaal niks met elkaar te maken.

Verder, Intel wil dat helemaal niet gebruiken. Baseer je dat op die ene prive-tweet van Andrew Lauritzen? Wat een onzin.

Of ze het ook gaan gebruiken is natuurlijk niet geheel zeker, maar er is iig wel interesse binnen Intel

[Reactie gewijzigd door player-x op 23 juli 2024 18:39]

[Verwijderd]

Ik had het dus zeker niet alleen over hem maar ook over andere ontwikkelaars.

Ik ben niet bekend met uitspraken van Romero, dus daar kan ik weinig over zeggen.

Ik heb een jaar of 5 geleden een interview gelezen waar Carmack, Romero en Sweeney aan het discuteren waren, en een van de dingen waar ze het alle drie over eens waren was dat APIs meer low level moesten worden.

Dat heeft Microsoft dan ook gedaan. DX10 was een flinke stap ten opzichte van DX9. De hele pipeline is eruit gegooid, en alles werd 100% shader-based. DX10 en nieuwer doen weinig meer dan buffers en shaders naar de GPU sturen.
DX12 zorgt er voornamelijk voor dat je nu flexibeler kunt omgaan met die buffers.

Cuda is nVidia only, waar Mantle voor en door iedereen te gebruiken is, en hebben trouwens helemaal niks met elkaar te maken.

nVidia heeft anders al tijden geleden de compiler voor Cuda opengegooid: http://www.computerbase.d...-alle-auch-amd-und-intel/
https://developer.nvidia.com/cuda-llvm-compiler
Iedereen is dus vrij om zelf Cuda te implementeren voor hun hardware.
Ze doen het alleen niet, net als met Mantle.

Of ze het ook gaan gebruiken is natuurlijk niet geheel zeker, maar er is iig wel interesse binnen Intel

Nee, er is geen interesse binnen Intel. Lauritzen handelde niet in naam van Intel. Verder werd hem de informatie geweigerd door AMD.
Intel heeft nota bene zojuist een DX12-demonstratie gegeven: nieuws: 'DirectX 12 kan energieverbruik halveren of fps met de helft verhogen'
Die zijn echt niet met Mantle bezig.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[SG]

Het zijn kleine group engine builder ontwikkelaars die er over zeuren. Wat niet de algehele game industrie vertegen woordigen.
Ik denk dat de majority van de devers de doorslag geeft. De meeste dev's hebben te maken met strakke deadlines. En kunnen niet zoals die primadonna's veel R&D doen en paar Jaren besteden door iets uit te vogelen.
Daar geld time to market. De hardware moet toegankelijk zijn en dat de grootste taak van DX om bij het met grote verschil leidende platform. Dmv abstractie. Dev zorgen voor hardware ondersteuning hun uit handen te nemen.

Uiteraard zijn er lieden die direct met hardware willen stoeien.

Ik denk eerder dat de software architectuur van kernel tot driver model tot driver. Een engineering method toepast die niet multithreaded optimal is. Naast de overhead.

Nu 8 cores en tot 16 treads beschikbaar komen. Is een naast low level eerder een zeer concurrent friendelijk abstractie dunne lag nodig. Om goed door te kunnen schalen.

[goarilla]

Ook is het een goede afstraffing voor zowel MS als nVidia, MS vooral omdat ze gewoon lui zijn, en nVidia omdat ze de concurrentie buiten willen houden door alles met eigen standaarden te beschermen.

Maar je richt je wel specifiek op MS. Er zat altijd een behoorlijke tijd tussen directx releases. AMD probeert gewoon er wat meer vaart achter te zetten omdat ze hun graphics afdeling broodnodig hebben. Zeker nu dat ze alles hebben ingezet op hun APU's.

[Reactie gewijzigd door goarilla op 23 juli 2024 18:39]

[player-x]

Maar je richt je wel specifiek op MS.

Is dat ook niet terecht, MS is gewoon zeer laks geweest met het veder ontwikkelen van DX, iets waar game en hardware ontwikkelaars steeds meer om vroegen.

En als AMD niet met Mantle was gekomen, hadden we nu nog steeds geen DX12 ontwikkeling gehad die ''close to metal'' te programmeren was, maar een door ontwikkeling van DX11 met zijn zware overhead.

Mantle is imho dan ook een goed voorbeeld van een Disruptive Innovation

[SG]

Dat is wat de onwetende publiek aanneemt. Met vaak grote antipathy tegen over MS. Ik heb er vraag tekens bij. AMD is uiteraard al langer bezig geweest met het bedenken en voorbereiden en uitwerken en opleveren van mantle API ergen tegen het einde wordt de NDA door broken. En MS reageerd in korte tijd door even binnen alle MS crossplatform een mantle gelijke DX12 DirecX3D even op te leveren.

Dat noem ik in record tijd.

Ik denk eerder dat dev al langer zuren en AMD of eerder de ATI afdeling al wat verder gevorden zijn en door nauwe banden met de game industrie er het een en ander is uitgerold en dus men eerder dan de DX cyclus devs van low level API voorzien.

Het is ook de slechte of inefficente multithreaded driver model dat naast de overhead van belang is. Dit loopt uiteraard langer. Maar MS aanpak is grootschaliger.

[Amiga3000]

Des te groter was dus de kans voor anderen, je kan dus ook zeggen dat blijkbaar niet een ander bedrijf in staat was om iets te doen.

Misschien dat AMD dit doet om eindelijk eens winst te maken, met de nieuwe consoles doen ze goede zaken.

Wil je de beste resultaten dan zul je voor iedere kaart eigen software moeten schrijven.

Het enige wat prettig is aan het mantle initiatief is dat men weer eens wakker wordt en verder gaat ontwikkelen.

[Verwijderd]

Des te groter was dus de kans voor anderen, je kan dus ook zeggen dat blijkbaar niet een ander bedrijf in staat was om iets te doen.

Ja, het is tekenend dat nVidia blijkbaar niet in dat gat is gesproken, ondanks dat nVidia een grotere software-afdeling heeft dan AMD, en dus makkelijker een nieuwe API kan lanceren (zie bv Cuda of PhysX, of hun werk met OpenGL-extensies, hun werk met Pixar... of wat langer geleden, hun Cg).
nVidia heeft ook een groter marktaandeel dan AMD wat GPUs betreft, dus een API zou bij nVidia ook meer kans van slagen hebben.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Vayra]

Het kan ook zo zijn dat Nvidia hiermee juist strategisch handelt. Want uiteindelijk zijn zij de lachende derde die het logo van Dx12 op de doos plakken en weer direct helemaal up-to-date zijn zonder daar een seconde aan kwijt te zijn geweest. Uiteindelijk wil Nvidia gewoon GPU's verkopen namelijk. Ze varen wel bij een status quo, in principe, omdat er toch weer GPU"s gekocht gaan worden en die blijven doorontwikkelen kost geen nieuwe API.

En AMD werkt zich een slag in de rondte, komt veel in het nieuws maar blijkt uiteindelijk vooral veel geroep te zijn geweest, omdat ze ingehaald werden door Dx12.

[Reactie gewijzigd door Vayra op 23 juli 2024 18:39]

[Verwijderd]

Het kan ook zo zijn dat Nvidia hiermee juist strategisch handelt.

Maar nVidia is juist een pro-actief bedrijf.
Als je ziet waar de laatste jaren de innovaties vandaan gekomen zijn, dan is dat vooral nVidia.
nVidia kwam met Cuda, waar later dus DirectCompute en OpenCL van zijn afgeleid (die gewoon op die originele 8800 werken).
nVidia kwam met GPU-accelerated physics, bij Intel en AMD wachten we daar nog steeds op.
nVidia kwam met een efficiente parallele tessellator. Intel heeft die inmiddels ook, bij AMD wachten we er nog steeds op.
nVidia kwam met G-Sync... AMD reageert met FreeSync.

Gezien hoe nVidia normaal gesproken bezig is met het ontwikkelen van nieuwe features, APIs etc, lijkt mij dat als het ECHT een issue was, dat nVidia in dat gat gesprongen was.

Daarnaast, het blijft opmerkelijk dat DX12 wel op alle DX11-kaarten van nVidia gaat werken, maar alleen op GCN-kaarten van AMD.
Ik heb bij de introductie van GCN al geroepen dat AMD wel ineens opvallend veel afweek van hun eerdere architectuur, en kwam met een architectuur die wel opvallend veel leek op Fermi.

[gjmi]

Apple gebruikt op OS X openGL, op iOS is Metal toegevoegt

[Verwijderd]

Er gaan geruchten dat Apple aan een eigen GPU werkt, ze hebben een architectuur licentie van Imagination Technologies, vergelijkbaar met de licentie die ze hebben van ARM voor CPU's.

Wat we dan dus krijgen voor de iOS devices is een compleet afgestemde lijn OS/Metal/CPU/GPU, de totale integratie zeg maar.

Wat dan natuurlijk ook zomaar zou kunnen ontstaan is dat Apple de OS X hardware omzet naar eigen CPU/GPU (ARM!), dan zal Metal ook volgen op OS X (of is het dan inmiddels iOS geworden op alle systemen?).

[ZpAz]

De laptop en desktop producten van Apple draaien OSX. Maar dat zal intern al jaren op ARM draaien, omdat het dezelfde core heeft als iOS. Voor de sprong naar Intel meerdere jaren terug liep het ook al jaren intern op Intel, en werden enkel apparaten met PowerPC verkocht.

Zelf denk ik ook al geruime tijd dat Apple op den duur van Intel afstapt om compleet op hun eigen SOC over te gaan, ook voor laptops en desktops. Maar dit kan nog wel even duren.

[Devion]

Die 'derde partijen' zullen dan toch de api's moeten gaan integrereren in hun rendering pipeline. Plus er is tevens een groot gedeelte aan studio's die gewoon vrolijk z'n eigen engine onderhoud. Het zijn nu voornamelijk de Indie's die op standaard engines rondhangen (Unity, UE4, CryEngine, etc.)

[NitSuA]

Beetje off-topic, maar:

De 'OpenGL Next'-api moet, net als AMD's Mantle-api en Microsofts DirectX 12, het mogelijk maken om de gpu directer aan te spreken.

Is er dan een manier om de GPU nog directer, of helemaal direct, aan te spreken? Of terwijl, zijn er meer van dit soort optimalisaties die 'logisch' zouden zijn, maar nu niet worden doorgevoerd?

Ik bedoel eigenlijk te zeggen, natuurlijk vind ik MANTLE en deze toezegging naar de Khronos Group een goede ontwikkeling, maar het hele verhaal van MANTLE klinkt mijn inziens nou niet echt als een uitvinding.. Waarom is dit niet veel eerder geïmplementeerd? Heeft niemand eraan gedacht dat het sneller is om instructies dichter op de GPU uit te voeren??

[Reactie gewijzigd door NitSuA op 23 juli 2024 18:39]

[DCK]

De GPU spreekt net zoals je CPU een bepaalde instructieset, kleine commando's die aangeven wat voor operaties de GPU moet uitvoeren. Het is niet te doen om die assemblytaal direct uit te voeren; die is compleet verschillend tussen Nvidia, AMD, Intel, Qualcomm, PowerVR en ARM. De instructieset verschilt ook tussen verschillende generaties en modellen chips van dezelfde fabrikant.

Daarom zijn in het verleden high-level APIs als OpenGL en DirectX gemaakt. die aan de programmeur bepaalde functionaliteit van de hardware beschikbaar maakte aan de programmeur. Het probleem van deze APIs is dat ze geleidelijk zijn ontwikkeld; de manier waarop GPUs worden aangestuurd lijkt nog steeds behoorlijk op de manier waarop dat in het GeForce 3-tijdperk gebeurde terwijl het karakter van GPUs enorm is veranderd sindsdien. De GPU wordt nog steeds gezien als een of andere versnelde tekentool, en niet als een eigen enorm krachtige computer op zich.

Met Mantle, Metal, DirectX 12 en OpenGL Next wordt omarmd dat GPUs een specifiek rekenkrachtig subsysteem zijn. Wat voor instructies er specifiek naar de GPU worden toegestuurd, dat zit in de driver ingebakken, maar er wordt vanuit gegaan dat een GPU een computer met instructies is en niet een tool om pixels en polygonen op te tekenen. Dat vermindert sterk het aantal keren dat de GPU en de CPU moeten communiceren, en daardoor wordt het efficiëntier.

Het maakt GPUs niet in staat om meer instructies uit te voeren, maar het maakt het in staat om efficienter instructies te accepteren. Je krijgt niet ineens meer shaderperformance daardoor, maar het verwijdert wel bepaalde bottlenecks bij het renderen van complexe geometrie bijvoorbeeld.

[Reactie gewijzigd door DCK op 23 juli 2024 18:39]

[PrisonerOfPain]

Het is niet eerder gedaan om een paar simpele redenen.

1. GPUs zijn in de afgelopen 5+ jaar enorm veranderd, er zit minder fixed function hardware in en de manier van processen is enorm veel flexibeler geworden. Daarom komen ze nu met de descriptor tables & bindless aanpakken.

2. De APIs zijn daar op achter gebleven omdat ze gewoon werkte, mensen waren zich bewust van dat het niet 100% efficient was. Maar het werkte op z'n mist op alle GPUs die in de markt lagen en de focus van Microsoft met DX11 lag ergens ander (feature development).

3. Het Mantle verhaal speelt al heel lang (2007 oid) maar is nu pas echt aan het ontpoppen omdat er eindelijk release van zijn.

Verder speelt het mee dat de nieuwe consoles gewoon moderne GPUs aan boord hebben nu en er ineens een veel grotere markt is om d'r iets mee te doen, en er is ineens een veel meer over de GPUs bekend bij developers nu.

[Verwijderd]

2. De APIs zijn daar op achter gebleven omdat ze gewoon werkte, mensen waren zich bewust van dat het niet 100% efficient was. Maar het werkte op z'n mist op alle GPUs die in de markt lagen en de focus van Microsoft met DX11 lag ergens ander (feature development).

De focus van Microsoft lag ook op het rechttrekken van alle platforms. DX11 moest ook werken op Windows Phone, en daar zit je nog vaak met DX9-level hardware.

3. Het Mantle verhaal speelt al heel lang (2007 oid) maar is nu pas echt aan het ontpoppen omdat er eindelijk release van zijn.

Ik zou zeggen 2003: http://www.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf
Toen wisten we al: "Hee, de kosten van draw calls zijn niet koel", en op console deden we dat dan ook anders.
Maar zoals je zegt: de hardware was toen anders, minder flexibel, en meer diversiteit, en een oplossing lag nog niet echt voor de hand in die dagen.
We kregen wel dingen als geometry instancing, geometry shaders, render-to-vb, streamout etc om het probleem een beetje te omzeilen. D3D10 probeerde vooral ook het aantal calls per frame te verminderen door oa renderstates veel meer te groeperen. En in D3D11 kwam er ook een beperkte vorm van multithreading.
Maar nu is de tijd pas rijp om die DX9-hardware definitief los te laten, en alleen maar te kijken naar moderne hardware met unified shaders en compute-functionaliteit.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[PrisonerOfPain]

Ik zou zeggen 2003: http://www.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf

Ik had 't specifiek over Mantle, niet over batching in het algmeen - dat speelt inderdaad nog langer

[Verwijderd]

Tsja, dan snap ik niet echt wat je bedoelt...
Als je het over 'het verhaal van Mantle' hebt, dan gaat dat voornamelijk over het batch-batch-batch verhaal (CPU-overhead door het veranderen van states en sturen van nieuwe batches, dat vaak dan ook nog eens hercompilatie van bepaalde shaders vraagt aan de driver-kant, omdat bepaalde states binnen shaders worden afgehandeld etc).

Als je het specifiek over Mantle hebt... Mantle werkt alleen op GCN-hardware, dus kan dat verhaal nooit gespeeld hebben voordat die GCN-hardware er was, en in 2007 was die er NOG LANG niet.
(Pre-GCN-hardware zal vast andere regels hebben over wat wel/niet in shaders compileerd wordt, wanneer dus wel/niet een recompile getriggerd wordt door state-changes etc... en dat zal ermee te maken hebben dat Mantle waarschijnlijk niet goed mapt op oudere AMD-hardware (of hardware van een concurrent), en zal daarom niet ondersteund worden, omdat je het probleem er niet echt mee oplost, en je dus niet echt sneller bent dan D3D11, zoals ik al eerder zei).

Dus ja, ik zie 2 opties, en de optie van "Mantle in 2007" klopt met beiden niet.

[PrisonerOfPain]

"Het verhaal van mantle" -> gesprekken met de betrokken partijen over het maken van een low-level api voor de pc.

[Verwijderd]

Gesprekken vanuit ATi?
Die hadden in 2007 wel wat anders aan hun hoofd! Ze waren op sterven na dood, AMD had ze net overgenomen, en de Radeon 2900 was een gigantische flop.
Ideaal moment om een ambitieus project als een next-gen API op te gaan starten!

Dat iemand anders die gesprekken toen heeft opgestart (bv nVidia, die daar dus met batch-batch-batch al mee bezig was, en ook al OpenGL-extensies ontwikkelde om het problem tegen te gaan), dat zou wel kunnen... Maar dan zijn we weer terug bij het punt dat ATi/AMD niet de drijvende kracht was achter het idee van Mantle/DX12/OpenGL Next, en dat ze vooral 'goedkoop scoren' op het moment.

[ignitem]

Uit de website van OpenGL kan ik niet opmaken of het Open Source is en of het onder de GPL licentie valt. Heeft iemand een antwoord?

[Verwijderd]

Het is een open standaard. Het gaat dus om een lijst van specificaties, en niet om source-code. De GPL is dan ook niet van toepassing.

[Blokker_1999]

OpenGL is een API specificatie. Het is op zich geen stukje software of hardware. De specificatie is wel uitgebracht en vrijgegeven onder een eigen open licentie die lijkt op een kruising tussen BSD, X en Mozilla. Het logo zit dan weer onder een gesloten licentie.

[goarilla]

Het is zoals ANSI C, een standaard die je zelf mag implementeren (gcc,icc,llvm/clang,...). De drivers van Nvidia en AMD komen met hun eigen implementatie. En mesa bevat ook een opengl implementatie die gebruikt worden door de opensource linux drivers.

[Wolfos]

OpenGL is geen programma, maar een specificatie. Er is dus ook geen officiele code, dit word voor ieder platform geimplementeerd, meestal door de drivers.

[bantoo]

De Open in de naam zal er ook wel blijven voor volgende versies.

[Verwijderd]

Lijkt me een goede zet:
Ten eerste zou het het werk van Khronos makkelijker maken, zodat ze hopelijk niet voor de derde keer vroegtijdig stranden bij een next-gen OpenGL API.
Ten tweede zou Mantle dan wel een toekomst hebben als serieuze open standaard. Zolang AMD de controle houdt, gaan nVidia en Intel het natuurlijk nooit ondersteunen, en is Mantle eigenlijk ten dode opgeschreven, met de komst van DX12, Metal en OpenGL NG als alternatieven.

Win-win dus.

[PrisonerOfPain]

Mbt de discussie die we gisteren hadden.

Development on DirectX 12's new features may have begun before Mantle, he said, but the "real impetus" for DX12's high-throughput layer came from the AMD API.

[Verwijderd]

Ja, wij van WC Eend, he?
Huddy kletst wel vaker uit z'n nek.
Sowieso spreekt hij zichzelf hier al tegen:
AMD heeft niet al te lang geleden nog geroepen dat er geen DX12 zou komen.
Nu geeft Huddy dus al toe dat er al aan DX12 gewerkt was voordat er sprake was van Mantle.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[PrisonerOfPain]

Mwa goed, die aankondiging was gedaan in een tijd dat er inderdaad geen sprake was van een DX12, de features die toen besproken waren zouden in een DX11.x versie gaan.

[Verwijderd]

A rose, by any other name...
Onzin-excuus dus.
De boodschap van AMD was namelijk in de trant van: "Er komt geen DX-update meer": http://www.heise.de/newst...tX-12-kommen-1835338.html

Noteer ook de datum even: 4 april 2013. Niet heel lang geleden dus.

[PrisonerOfPain]

Dat artikel gaat letterlijk over geen DX12 meer en is van een jaar geleden? Je leest dingen die niet gezegt zijn en bevestigt vervolgens mijn punt; de Mantle announcement is van 09 2013, daarna dus.

[Verwijderd]

Ik bevestig jouw punt helemaal niet?
Het volgt elkaar allemaal zo kort op, dat het nogal onwaarschijnlijk is.
AMD zegt in april nog: geen DX updates.
Vervolgens zeggen ze in september: Wij komen binnenkort met Mantle.
Daar waren ze overigens al een tijd mee bezig, want in 2011 riepen ze al "Farewell to DirectX": http://www.bit-tech.net/h...3/16/farewell-to-directx/
En nu zeggen ze: Ja, voordat wij met Mantle begonnen, was MS al met iets van DX12 bezig.
Kortom, erg ongeloofwaardig allemaal.
Gezien dat artikel uit 2011, was AMD ook voor april 2013 al lang met Mantle bezig.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[AndyD]

ik herriner mij een artikel waarin amd zegt dat als mantle uit beta gaat andere (in dat geval was het intel) het ook mogen gebruiken

[Verwijderd]

Ja, dat heeft nVidia ook over Cuda geroepen. Maar niemand gaat dat doen, zolang hun grootste concurrent de touwtjes in handen heeft.
Als AMD Mantle overgeeft aan Khronos, wordt het een ander verhaal, want dan hebben bedrijven als nVidia en Intel net zo veel inspraak als AMD.

[Blokker_1999]

AMD moet dan ook wel op papier beloven dat deze specs vrij te gebruiken zijn. Niet vandaag zeggen dat ze vrij beschikbaar zijn om dan binnen enkele jaren alsnog met patenten af te komen en rechtzaken aan te spannen. Dat hebben we spijtig genoeg al te vaak gezien in de techwereld.

[Malistix1985]

Ik ben benieuwd of Sony met de PS4 ooit Mantle zal gaan ondersteunen omdat hun console ook gebruik maakt van een GFX die deze technologie aan kan. Dat zou een super boost zijn voor AMD natuurlijk.

Volgens mij werkt mantle (nogsteeds) niet met Nvidia en Intel kaarten en tot dat dit wel volledig ondersteund zou zijn, wat waarschijnlijk nooit gaat gebeuren, is directX voor de PC waarschijnlijk het betere alternatief omdat dit tenminste wel compatible is met alle computer hardware. Dat neemt niet weg dat AMD met Mantle wel laat zien dat DirectX efficienter en beter kan, wat altijd goed is.

[vali]

Ik geloof niet dat AMD aan Microsoft laat zien dat DirectX efficienter kan werken, dat hebben ze zelf al ingezien. Had kan namelijk niet zo zijn dat Microsoft in deze stadion al is nadat AMD Mantle liet zien, ze waren er vast gelijktijdig mee bezig.

Persoonlijk heb ik meer vertrouwen in Direcx12 dan Mantle, voornamelijk omdat tablets (met elk soort gpu erin) eindelijk een flinke boost gaan ondervinden.

[Amanoo]

Ik vind vertrouwen hebben in DirectX 12 vanwege tablets juist apart. De meeste tablets draaien ofwel op Android ofwel op iOS. Windows tablets kunnen ze aan de straatstenen bijna niet kwijt. Tenzij DirectX cross platform wordt (wat op zich best leuk kan zijn, Assassin's Creed op Linux) zie ik er geen heil in.

[vali]

Gelukkig val ik niet onder "de meeste mensen". Ik koop een tablet niet als een YouTube machine en/of een simpel candy crush mee te spelen. Ik wil er naast mijn school zaken ook serieus op kunnen gamen en in mijn ogen bieden ios en android tablets dat nog niet helemaal.

Al kan je al aardig battlefield 4 spelen op een Surface pro3, ben ik erg benieuwd wat DirectX 12 gaat bieden.

[goarilla]

Dus jij wilt mainstream PC gamen op een low power device met een touch interface ?
En de gameplay in dat filmpje lagged: 10-15 fps in actie gok ik.

[Verwijderd]

MS heeft dat altijd al geweten, omdat hun Xbox altijd al een efficiente low-level laag had in de API.
Vroeger was er alleen te veel wildgroei aan GPUs om zoiets ook naar de desktop te brengen.
Tegenwoordig zijn de GPUs meer gestandaardiseerd, en ook veel flexibeler programmeerbaar. Daarom is de tijd nu rijp om een nieuw soort API te ontwikkelen.

Dat AMD zo'n API sneller op de markt heeft dan Microsoft, zegt mij niet veel. Microsoft heeft met veel meer factoren rekening te houden. Ten eerste moet MS zorgen dat de API goed werkt op ALLE GPUs, niet alleen die van AMD. Dus dat betekent sowieso al veel meer overleg etc.
Ten tweede moet MS ook de juiste ontwikkeltools leveren, omdat vrijwel alle game developers DirectX gebruiken op Windows en/of Xbox.
Bij AMD zijn er nog geen publieke ontwikkeltools. Op dit moment is het zo dat een select aantal ontwikkelaars samen met AMD-ontwikkelaars werken aan Mantle-ondersteuning. Niet helemaal hetzelfde.

[haarbal]

De ps4 heeft al een eigen lowlevel api.

[PrisonerOfPain]

Ik ben benieuwd of Sony met de PS4 ooit Mantle zal gaan ondersteunen omdat hun console ook gebruik maakt van een GFX die deze technologie aan kan. Dat zou een super boost zijn voor AMD natuurlijk.

Ik betwijfel het - Sony heeft z'n eigen API die super lekker werkt.

Volgens mij werkt mantle (nogsteeds) niet met Nvidia en Intel kaarten en tot dat dit wel volledig ondersteund zou zijn

En daarom ligt 't nu bij Khronos

[jeroen7s]

zeer mooie zet van amd, al vraag ik me af wat dat gaat betekenen voor de toekomst van mantle zelf, als er een cross-platform, low-level API komt die goed in elkaar zit
zeer pro-consumer beslissing van amd

[PrisonerOfPain]

Eer dat Khronos met een daadwerkelijke standaard aan komt zetten zal nog wel even duren. Verder heeft Mantle natuurlijk als eerste toegang tot AMD specifieke features.

[daellat]

Sowieso die open standaarden. Uiteindelijk gaat het natuurlijk om hogere omzet, het is en blijft een bedrijf, maar samen met steam (alhoewel gewoon een DRM programma op zichzelf, ik heb het dan meer even over Steam OS en in mindere mate de steam machine) vind ik dat ze een stuk meer goodwill kweken dan nvidea met hun dichtgeknepen proprietary troep D:

[Verwijderd]

Waarom zeurt nu iedereen erover, en toen 3DFX met hun eigen standaard(Glide) kwam helemaal niemand?

[Verwijderd]

Toen 3DFX ermee kwam, waren er nog geen standaarden.
Direct3D bestond nog niet, en OpenGL was alleen voor dure workstation-kaarten en CAD/CAM, niet voor goedkope game-kaartjes zoals van 3DFX.
Iedere fabrikant kwam dus met z'n eigen standaard.

[Verwijderd]

OpenGL werd ook ondersteund door goedkope kaartjes zoals de S3 virge, en Direct3D bestond toen al wel degelijk gezien de 3DFX voodoo1 beide standaarden ondersteunde.

Er waren inderdaad aardig wat verschillende 3D accelerators op de markt rond die tijd. Glide werd gewoon de standaard vanwege de populariteit van de Daimond Monster3D.

[Verwijderd]

OpenGL werd ook ondersteund door goedkope kaartjes zoals de S3 virge, en Direct3D bestond toen al wel degelijk gezien de 3DFX voodoo1 beide standaarden ondersteunde.

Nu moet je even niet de data door elkaar gaan halen.
De Voodoo 1 kwam in oktober 1996 op de markt, met Glide.
De eerste versie van Direct3D is ook uit 1996. Misschien dat D3D zelf iets eerder was dan de Voodoo 1, maar er waren nog geen games die het gebruikten, D3D was dus nog niet een 'standaard' in de zin dat het gebruikt werd in alle games. D3D werd sowieso vrij traag opgepakt in het begin. De paar accelerators die op de markt waren, hadden allemaal hun eigen API op dat moment, en er werden voor games patches uitgebracht voor nieuwe 3d-kaarten. Vanwege de performance van de 3DFX-kaarten werd Glide in eerste instantie de populairste 3D-API.

De S3 Virge kwam in 1995, dus die had sowieso geen Direct3D op dat moment, want dat bestond niet. Natuurlijk konden ze dat later met een driver-update wel toevoegen, maar dat is wat anders.

OpenGL was er al HELEMAAL niet. De eerste OpenGL game was GLQuake uit 1997. Dit is wat de readme zegt:

Theoretically, glquake will run on any compliant OpenGL that supports the
texture objects extensions, but unless it is very powerfull hardware that
accelerates everything needed, the game play will not be acceptable. If it
has to go through any software emulation paths, the performance will likely
by well under one frame per second.

At this time (march ’97), the only standard opengl hardware that can play
glquake reasonably is an intergraph realizm, which is a VERY expensive card.
3dlabs has been improving their performance significantly, but with the
available drivers it still isn’t good enough to play. Some of the current
3dlabs drivers for glint and permedia baords can also crash NT when exiting
from a full screen run, so I don’t recommend running glquake on 3dlabs
hardware.

3dfx has provided an opengl32.dll that implements everything glquake needs,
but it is not a full opengl implementation. Other opengl applications are
very unlikely to work with it, so consider it basically a "glquake driver".

Kortom, zoals ik zeg, in maart 1997 waren er eigenlijk alleen maar professionele kaarten die OpenGL support hadden.
Vanwege GLQauke zijn bedrijven als 3DFX dus van die 'MiniGL' drivers gaan schrijven. Dat is geen OpenGL, maar een drivertje die *net* genoeg ondersteunt om GLQuake te draaien. Met wat kleine aanpassingen konden ze ook andere games op basis van die engine draaien, zoals Half-Life of Quake 2. Maar volwaardige OpenGL-support kwam pas later, toen de hardware completer werd. Ik meen dat nVidia met z'n TNT de eerste was met een volledige OpenGL-implementatie. Intussen was dat alweer 1998, en waren we al weer wat generaties verder qua hardware en APIs.
Toen 3DFX kwam met een volwaardige OpenGL, was dat ook een stuk trager dan hun MiniGL trouwens.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

- Direct3D support staat gewoon op de verpakking de Monster3D, het staat zelfs herhaaldelijk op de featurelist. genoemd.

- OpenGL ondersteuning 1.1 zit ingebakken in de BIOS van de S3 Virge. De accelatiefuncties waren nihil omdat de chips zo langzaam waren.

- GLquake was de eerste game die gebruik maakte van OpenGL, maar je moest een volledige openGL32.dll van de latere 3DFX drivers in je win32 map plaatsen, en ja hij was langzamer, want MiniGL werd alleen geschikt voor Quake en Quake2.

- In 1995 kwam de 3Dblaster VLB al uit, idd een professionele volledige kaart van 2000 dollar, echter een paar maanden(lente van 1996) later kwam er een PCI uitvoering van uit voor 350 dollar, ook een doorluskaart gericht op gamers(met volledige OpenGL support, en direct3D ondersteunde hem volledig( De Voodoo kaaren waren een stuk duurder) Deze kaarten hadden ook nog een eigen API, GLINT, voor games, maar slechts tiental spelletjes die ondersteuning boden. Unreal engine ondersteunde de kaart wel.
- Creative labs stapte iets later over op de Rendetion Verité, voor de 3Dblaster PCI. Ook een kaart met een eigen API die naast direct3d en OpenGL een eigen standaard voerde, hier is ook een dedicated port van; vQuake(eind 1996). De Verité is slechts iets langzamer dan de Voodoo1 in performance, maar was een 2D/3D oplossing.


- De eerste kaart van Nvidia met openGL ondersteuning was de Riva218, de voorloper van de ZX en de TNT. En dat is een kaart uit 1997, waar ik destijds 450 gulden voor neer moest leggen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

- Direct3D support staat gewoon op de verpakking de Monster3D, het staat zelfs herhaaldelijk op de featurelist. genoemd.

Ontken ik toch ook niet? Ik zeg dat D3D er wel was toen de 3DFX chips gelanceerd warden, maar dat games toch vooral Glide ondersteunden, en D3D-support pas later op gang kwam.

- OpenGL ondersteuning 1.1 zit ingebakken in de BIOS van de S3 Virge. De accelatiefuncties waren nihil omdat de chips zo langzaam waren.

Onzin. OpenGL is een API, en kan niet in een BIOS ingebakken zitten. Dat moet via een driver voor het OS.

- GLquake was de eerste game die gebruik maakte van OpenGL, maar je moest een volledige openGL32.dll van de latere 3DFX drivers in je win32 map plaatsen, en ja hij was langzamer, want MiniGL werd alleen geschikt voor Quake en Quake2.

Die 'OpenGL32.dll' *was* een MiniGL driver. GLQuake sprak gewoon OpenGL aan, dus op Windows is dat dan OpenGL32.dll. MiniGL was dus een vervangende OpenGL32.dll die niet de volledige OpenGL implementeerde, maar net genoeg om GLQuake te draaien. Dit noemt men dus 'MiniGL" drivers. Dat staat ook in de GLQuake readme die ik hierboven plaatste:

3dfx has provided an opengl32.dll that implements everything glquake needs, but it is not a full opengl implementation. Other opengl applications are very unlikely to work with it, so consider it basically a "glquake driver".

- In 1995 kwam de 3Dblaster VLB al uit, idd een professionele volledige kaart van 2000 dollar, echter een paar maanden(lente van 1996) later kwam er een PCI uitvoering van uit voor 350 dollar, ook een doorluskaart gericht op gamers(met volledige OpenGL support, en direct3D ondersteunde hem volledig( De Voodoo kaaren waren een stuk duurder) Deze kaarten hadden ook nog een eigen API, GLINT, voor games, maar slechts tiental spelletjes die ondersteuning boden. Unreal engine ondersteunde de kaart wel.

De 3DBlaster had een gestripte 3dlabs chip, die volgens dit artikel niet bijster goed werkte met Direct3D (dat dus later toegevoegd is in een driver-update omdat het bij de release van de kaart nog niet bestond): http://vintage3d.org/3dlabs.php#sthash.TqiupYWv.dpbs
3dlabs werd ook al genoemd in de GLQuake readme, en hoewel deze kaarten OpenGL-drivers hadden (als 1 van de weinigen, vooral vanwege het professionele verleden van 3dlabs), werd afgeraden om ze te gebruiken, omdat het niet goed werkte, en zelfs het system crashte.

- Creative labs stapte iets later over op de Rendetion Verité, voor de 3Dblaster PCI. Ook een kaart met een eigen API die naast direct3d en OpenGL een eigen standaard voerde, hier is ook een dedicated port van; vQuake(eind 1996). De Verité is slechts iets langzamer dan de Voodoo1 in performance, maar was een 2D/3D oplossing.

De Verite heeft wel een OpenGL driver, maar die schijnt nooit uit beta gekomen te zijn: http://vintage3d.org/verite1.php#sthash.MV797kDW.dpbs
Je kunt er GLQuake op draaien, en nog wel iets meer, maar het is geen 100% werkende OpenGL.
Er is ook een MiniGL driver voor dat ding, wat dus aangeeft dat die OpenGL driver een latere ontwikkeling is.

Verder was de Verite de kaart die MS gebruikte bij het ontwikkelen van Direct3D, en waarmee ze eind 1995 de eerste demonstraties van D3D gaven. De kaart kwam echter pas later op de markt.

- De eerste kaart van Nvidia met openGL ondersteuning was de Riva218, de voorloper van de ZX en de TNT. En dat is een kaart uit 1997, waar ik destijds 450 gulden voor neer moest leggen.

Ik had het over *volledige* OpenGL-ondersteuning. nVidia begon daarmee met de Riva128, maar pas bij de laatste driver-release hadden ze echt een volwaardige OpenGL. Deze was echter wel beperkt tot 16-bit: http://en.wikipedia.org/wiki/RIVA_128
Tegen die tijd was de TNT dus ook al op de markt, met een OpenGL driver die ook 32-bit ondersteunde.
Dus de Riva128 kaart is wel ouder dan de TNT, maar de volledige OpenGL driver voor de Riva128 niet.
Die drivers kun je hier nog steeds vinden (pluspunten voor geweldige support van nVidia): http://www.nvidia.com/object/riva_drivers.html
Ze zijn van maart 1999.

Snap je nu wat je allemaal door elkaar haalt?

[Verwijderd]

Opengl32.dll is een standaardnaam voor het stuurprogramma dat
windows gebruikte, de juiste versie word meegeinstalleerd door je videokaart. Windows98 heeft zelfs een standaard software versie ervoor . Dat heeft geen moer met 3DFX, of welke andere leverancier te maken.

Zoals in je eigen link netjes staat vermeld renderde de Riva128 16bit kleurdieptes. Dit deed 3DFX ook,, maar die hield dit grapje vol t/m de Voodoo3 3000.

En die driver van 1999 zijn de laatst beschikbare versie, ik had die kaart gewoon in mijn systeem en alle games werkten zelf met de bijgeleverde drivers destijds zonder problemen in openGL, en op een ATI rage was dit trouwens ook geen probleem.

Als de kaart erkend word als OpenGL ondersteunend, is dat zo, wat jouw interpretatie ervan is doet er dan niet toe.

Snap je nu wat je allemaal door elkaar haalt?

Met zo een idioot denigrerende houding verwijs ik je naar de zandbak, doei!

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

Opengl32.dll is een standaardnaam voor het stuurprogramma dat windows gebruikte, de juiste versie word meegeinstalleerd door je videokaart.

Dat is niet correct.
OpenGL32.dll is de 'hub' voor het Installable Client Driver protocol (ICD).
Het is niet de bedoeling dat deze wordt vervangen.
De bedoeling is dat OpenGL drivers zich in de registry aanmelden. De applicatie spreekt dan OpenGL32.dll aan, en kan daarmee opvragen welke drivers er beschikbaar zijn. Vervolgens kies je de driver die je wil gebruiken, en draagt OpenGL32.dll de rest over naar de gekozen driver.
Voor meer info, zie: http://msdn.microsoft.com...re/ff568203(v=vs.85).aspx

En die driver van 1999 zijn de laatst beschikbare versie, ik had die kaart gewoon in mijn systeem en alle games werkten zelf met de bijgeleverde drivers destijds zonder problemen in openGL, en op een ATI rage was dit trouwens ook geen probleem.

Wat is 'OpenGL'? Als je daarmee doelt op GLQuake of andere games die daarvan zijn afgeleid, tsja, nogal logisch, de 'OpenGL' implementaties waren in eerste instantie puur geschreven om die games te draaien. Dat wil nog niet zeggen dat ALLE OpenGL software erop draait.

Als de kaart erkend word als OpenGL ondersteunend, is dat zo, wat jouw interpretatie ervan is doet er dan niet toe.

Nee, want zelfs met MiniGL wordt een kaart als 'OpenGL' kaart herkend. Alleen werken de meeste calls niet, of slechts met een beperkt aantal parameters, hardwired voor GLQuake etc.

[Verwijderd]

- Als je de drivers van je kaart installeerde, overschreef die OpenGL32. Trek de DLL anders eens gewoon open.

Dat is niet correct. OpenGL32.dll is de 'hub' voor het Installable Client Driver protocol (ICD). Het is niet de bedoeling dat deze wordt vervangen.

Dat ging er in de Windows9x tijd toch echt heel anders aan toe, en over die periode gaat het hier. Het stond zelfs heel uitgebreid gedocumenteerd in de readme van GLquake, anno 1997.

OpenGL is een standaard. Die heeft revisies, en word continu uitgebreid. Het is nogal logisch dat als je een applicatie pakt die OpenGL4 vereist, je die niet kan draaien op een OpenGL2.0 opstelling, net zoals je met een Directx5 kaart geen DirectX10.1 applicaties kan draaien. Dat houd echter niet in dat de kaarten op het moment dat ze uitkwamen 100% volgens de toen geldende standaard waren.

En een 3DFX kaart met alleen de MiniGL driver word niet herkend als openGL, ook niet door installers van een game uit die tijd. Zelfs een ander knutselproject GLdoom werkte niet met de miniGL driver.

Er stond wel een geschikte dll tussen bij de voodoo drivers, iets in de trend van ogl32.dll, die kon je gewoon renamen naar opengl32.dll, en over die in je system32 map heenkopiëren, dan werkte het wel. Die liep echter een stuk minder snel dan de miniGL.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

- Als je de drivers van je kaart installeerde, overschreef die OpenGL32. Trek de DLL anders eens gewoon open.

Dat zeg ik: als ie dat doet, is het dus geen volledige OpenGL driver, maar een hack.
3DFX kwam pas in 1999 met een echte OpenGL ICD (ja ook voor Windows 9x zoals je ziet): nieuws: 3Dfx OpenGL ICD voor Quake3
Daarvoor was het dus een MiniGL-driverhack.
Lees anders dit document er maar eens op na: http://read.pudn.com/downloads6/doc/18629/opengl-icd.doc

Het stond zelfs heel uitgebreid gedocumenteerd in de readme van GLquake, anno 1997.

Er stond dan ook bij dat dat een "GLQuake"-driver was, en niet geschikt als generieke OpenGL-driver, omdat het geen volledige implementatie is.

OpenGL is een standaard. Die heeft revisies, en word continu uitgebreid.

Daar hebben we het hier niet over. De OpenGL ICD bestond al een tijdje, maar vrijwel alle fabrikanten hadden moeite om goede OpenGL drivers te ontwikkelen.

Dat houd echter niet in dat de kaarten op het moment dat ze uitkwamen 100% volgens de toen geldende standaard waren.

Nu moet je even 2 dingen scheiden:
1) De hardware
2) De drivers

Voor geval 1) geldt: De meeste videokaarten van de eerste/tweede generatie ondersteunden niet de volledige OpenGL 1.0 featureset in hardware. Ze moesten sowieso bepaalde dingen in software emuleren (voor GLQuake was dat dus niet echt een issue, omdat die maar een subset gebruikte van de OpenGL-features, waardoor je met MiniGL-drivers een eind kon komen, zelfs op hardware die niet aan de OpenGL 1.0-standaard voldeed).
Voor geval 2) geldt: Ook voor de hardware die WEL volledig aan de OpenGL 1.0-standaard voldeed, waren er vaak geen, of geen goede OpenGL-drivers, waardoor je dus alsnog problemen had met het draaien van OpenGL-software.

Dit kun je dus ook uit de GLQuake-readme halen, want zij zeggen dat er maar 1 kaart is die goed werkt. Andere kaarten zijn te traag (vanwege software-emulatie), drivers crashen, er zijn "GLQuake-drivers" (later bekend als MiniGL), of helemaal geen drivers.
De volledige OpenGL drivers van 3DFX, die eindelijk kwamen in 1999, waren ook trager dan de MiniGL drivers. Dat geeft nog maar eens aan hoe lastig het is om goede OpenGL-drivers te maken, en wat een driverhack die MiniGL-oplossingen waren.

En een 3DFX kaart met alleen de MiniGL driver word niet herkend als openGL, ook niet door installers van een game uit die tijd. Zelfs een ander knutselproject GLdoom werkte niet met de miniGL driver.

Natuurlijk wel. Die MiniGL driver is gewoon een alternatieve OpenGL32.dll. Zet dat ding in je windows\system32-directory ipv de originele van Windows, en iedere app ziet dat ding, en ziet dus een 'OpenGL' device.
Dat de meeste software er niet op werkt, is logisch. Dat ding is alleen ontworpen voor GLQuake, en negeert een hoop commando's.
Ik heb zelf een PowerVR PCX2 met een MiniGL-driver, en heb daar ook m'n eigen OpenGL code op proberen te draaien. Het doet niet wat het moet doen, maar je kunt wel degelijk een 'OpenGL'-context openen via z'n MiniGL-driver, en polygons renderen etc. Het gaat alleen fout qua texturing, belichting, camera-posities en dergelijke, zodra je teveel afwijkt van wat er in GLQuake gebruikt wordt.

[Verwijderd]

Heb je al die onzin die je hier beweerd wel eens in de praktijk getest?

Ik bespeur namelijk maar behoorlijk hard dat jij die tijd niet bewust hebt meegemaakt, en zeker niet zo diep in de materie zat als ik destijds, laatstaan enige hands-on ervaring uit die tijd hebt.

Je verhaal klopt namelijk voor geen kant, en jij hoeft MIJ zeker niet het verschil tussen hard en software uit te leggen, of Api's of drivers.

MiniGL is toegewijd voor specifiek de quake1 en quake2 engine te laten renderen op 3DFX kaarten. Nergens anders voor.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

Heb je al die onzin die je hier beweerd wel eens in de praktijk getest?

Ik bespeur namelijk maar behoorlijk hard dat jij die tijd niet bewust hebt meegemaakt, en zeker niet zo diep in de materie zat als ik destijds, laatstaan enige hands-on ervaring uit die tijd hebt.

Ik denk eerder dat het andersom is.
Ik heb die tijd vast VEEL bewuster meegemaakt dan jij, want ik programmeerde al 3d renderers voordat 3d-kaarten uberhaupt op de markt waren.
Later ben ik met vroege D3D en OpenGL-kaarten gaan werken, en ik heb met die PowerVR PCX2-kaart ook nog wel wat met z'n native PowerSGL API gedaan.
Ik heb ook een aantal Matrox-kaarten gehad die HELEMAAL geen OpenGL ondersteunden, zelfs geen MiniGL voor GLQuake.
Voor dat soort kaarte had je dan bv weer GLDirect van SciTech: http://scitech-gldirect.en.softonic.com/

Lees anders m'n blog eens, dat gaat deels over retro-coding: http://scalibq.wordpress....ldskoolretro-programming/

Dus ja, ik weet wel waar ik over praat hoor, ik heb die tijd HEEL bewust meegemaakt, en hobby nog steeds wel eens met oude hardware en vage APIs.

MiniGL is toegewijd voor specifiek de quake1 en quake2 engine te laten renderen op 3DFX kaarten. Nergens anders voor.

Ja, dat zeg ik toch de hele tijd? Jij bent hier degene die beweert dat 3DFX altijd al OpenGL heeft gehad.
GLQuake is echter wel een 'gewone' OpenGL app. MiniGL doet zich dus voor als 'gewone' OpenGL driver.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

Hhaha, droom lekker verder!

Ik sleutel al sinds 1990 aan mijn eigen hardware, en werkte van 1995 tot 2003 als bijbaantje op de technische dienst bij destijds de grootste PC keten van europa.

Ik heb ook nog kaarten gehad die helemaal geen ondersteuning voor 3D hadden hoor, tussen 1990 en 1996 wel een keer of 8 gewisseld.

En ja, 3DFX heeft altijd al ondersteuning voor openGL gehad, Quake echter niet. Daarvoor is MiniGL ontwikkeld. En powerVR kaarten waren gemeengoed rond de eeuwwisseling hoor, omdat ze zo goedkoop waren. Vergeet je je glide wrapper trouwens niet te deinstalleren volgende keer dat je de werking van MiniGL test?

Ik ga niet zeggen, nou mag jij weer, want ik ben je geneuzel spuugzat en heb nog wel meer te doen.

[Verwijderd]

Hhaha, droom lekker verder!

Ik droom niet, ik heb daadwerkelijk D3D en OGL software geschreven op die ouwe kaarten.
Da's toch even wat anders dan 'sleutelen aan hardware'. We hebben het hier over software, da's een andere tak van sport dan een paar kaartjes in een moederbordje steken en op een installertje klikken.

Ik heb ook nog kaarten gehad die helemaal geen ondersteuning voor 3D hadden hoor, tussen 1990 en 1996 wel een keer of 8 gewisseld.

Zoals je ziet op mijn blog, heb ik op dat soort kaarten zelf 3d-renderers ontwikkeld. Ik heb ze allemaal gehad, Hercules, CGA, PCjr/Tandy, EGA, VGA, en later via DirectDraw.

En ja, 3DFX heeft altijd al ondersteuning voor openGL gehad, Quake echter niet. Daarvoor is MiniGL ontwikkeld.

Je haalt hier toch echt dingen door elkaar.
Nee, Quake had oorspronkelijk geen 3d-acceleratie. Later is er een speciale versie ontwikkeld voor de Verite, genaamd vQuake. En een generieke versie voor OpenGL, genaamd GLQuake.
GLQuake was het eerste OpenGL-spel. Omdat er toen nog geen goede OpenGL-drivers waren, begonnen fabrikanten dus met MiniGL-drivers, specifiek om GLQuake te kunnen ondersteunen.

Later werden die doorontwikkeld tot volledige OpenGL-drivers. Zoals ik met een link naar het betreffende artikel op Tweakers.net al had aangetoond: 3DFX kwam daar in 1999 pas mee.
Dus ik snap niet waarom jij vol blijft houden dat 3DFX altijd al OpenGL-support had. Als dat zo was, hadden ze ook geen MiniGL nodig gehad.

Vergeet je je glide wrapper trouwens niet te deinstalleren volgende keer dat je de werking van MiniGL test?

Hier haal je weer dingen door elkaar.
Glide wrapper op een PowerVR? Het idee alleen al!
PowerVR leverde natuurlijk z'n eigen MiniGL-drivers, die niet op Glide draaiden, maar op hun eigen PowerSGL: http://www.vogons.org/viewtopic.php?t=32961
Hier kun je ze zelf downloaden: http://www.ag.ru/games/quake/patches
Echt, leuk dat je dingen probeert te roepen, maar je weet echt niet waar je over praat.
Zie ook: http://en.wikipedia.org/wiki/MiniGL

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

Kaartjes in een moederbordje prikken? Nee, ik loste problemen op van mensen die hun gekochte spullen niet aan de praat kregen. Ik heb het ook goed genoeg voor elkaar dat ik gewoon zakelijk als Beheerder en netwerkarchitect al jaren serieus mijn brood verdien, en niet mezelf terug hoef te trekken en uit verveling aan te programmeren tegen zwaar verouderde consumentenhardware en hun substandaarden.

En over OpenGL support van 3DFX, download welke driver package dan ook, rename 3DFXOGL.dll naar opengl32.dll, klaar.

En ik haal geen dingen door elkaar, en ik weet wel degelijk waar ik over praat. Ik deel alleen als technicus en engineer jouw "Creatieve interpratie" van zaken niet.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[Verwijderd]

En over OpenGL support van 3DFX, download welke driver package dan ook, rename 3DFXOGL.dll naar opengl32.dll, klaar.

En wat is je punt?

En ik haal geen dingen door elkaar, en ik weet wel degelijk waar ik over praat. Ik deel alleen als technicus en engineer jouw "Creatieve interpratie" van zaken niet.

Pah, meneer de 'beheerder en netwerkarchitect' wil strijden met een software-engineer/architect die al zo'n 20 jaar graphics programmeert.
Echt, snap je het nu echt niet, of ben je gewoon te trots om je fouten toe te geven?

[Verwijderd]

Mijn punt is dat het werkt, en al die fratsen als MiniGL's en eigen API's nergens voor nodig zijn.

Ik geloof niet dat een software engineer me in een link beperkingen voorschoteld van het huidige WDM model, daar waar het VxD model van toepassing was.

Zoals ik al aangaf, ik snap alles prima, alleen jouw versie van de werkelijkheid ontgaat me.

[Verwijderd]

Mijn punt is dat het werkt, en al die fratsen als MiniGL's en eigen API's nergens voor nodig zijn.

Die waren dus wel nodig, zoals gedocumenteerd in de GLQuake readme en de MiniGL-pagina op Wiki, en nog talloze andere bronnen.

Ik geloof niet dat een software engineer me in een link beperkingen voorschoteld van het huidige WDM model, daar waar het VxD model van toepassing was.

Waar heb je het nu weer over? Je dropt steeds leuk van die termen uit die tijd (zoals Glide wrappers), maar je snapt niet waar je over praat.
Ik heb toch specifiek een link geplaatst naar een document dat ook OpenGL ICD voor Windows 95 bespreekt, en ook OpenGL ICD drivers voor 3DFX-kaarten voor Windows 95.
En Windows 95 gebruikt idd VxD. WDM werd pas met Windows 98 geintroduceerd.
Wat dat er verder mee te maken heeft, zou ik niet weten, want het hele OpenCL ICD-gebeuren leeft in user-space, niet in kernel-space. Je hebt het dus sowieso niet over WDM of VxD, maar over DLLs. Die kunnen op hun beurt dan weer WDM-drivers danwel VxDs aanspreken, maar dat is weer een ander verhaal.

Zoals ik al aangaf, ik snap alles prima, alleen jouw versie van de werkelijkheid ontgaat me.

Je geeft ook je fouten niet toe. Want nadat jij begon over Glide wrappers, heb ik je gelinkt naar de daadwerkelijke MiniGL driver voor GLQuake voor PowerVR, dat natuurlijk niets met Glide of Glide wrappers te maken heeft (als je het ding bekijkt, zie je dat hij SGL.DLL aanspreekt, de native API van PowerVR dus), daar heb ik je niet meer over gehoord.
Je weet dus echt niet waar je over praat.

[Verwijderd]

- WDM kwam met Windows 98SE. Het wel of niet kunnen overschrijven van de opengl32.dll, en of dat verstandig is, is niet van toepassing. Je linkt vervolgens naar een MSDN artikel van toepassing op windows Vista en 7

En ik drop wel degelijk termen uit die tijd, die waren namelijk van toepassing op de hardware waarmee je qua kennis met mij poogt te touwtrekken. Je veranderd ook het onderwerp elke keer als je een fout maakt.

-De powerVR implementatie van MiniGL heeft het nooit gehaald bij het grote publiek, zoals je hoort te weten. Aan de andere kant beweerde je eerder dat sommige kaarten nooit de markt haalden, terwijl ik ze toch echt in mijn handen heb gehad. Komisch is dat.

Tuurlijk weet ik niet waar ik over praat, doe je de groeten aan je psychiater? Autist.

[Verwijderd]

- WDM kwam met Windows 98SE.

Nee hoor, ook de eerste Windows 98 had support voor WDM: http://en.wikipedia.org/wiki/Windows_Driver_Model

Het wel of niet kunnen overschrijven van de opengl32.dll, en of dat verstandig is, is niet van toepassing.

Jawel, het overschrijven van opengl32.dll is niet de juiste manier om een opengl-driver te installeren in Windows.

Je linkt vervolgens naar een MSDN artikel van toepassing op windows Vista en 7

En alle eerdere OSen met OpenGL-support.
Ik linkte ook naar dit document: http://read.pudn.com/downloads6/doc/18629/opengl-icd.doc
Dit document geeft toch duidelijk aan dat het ook op Windows 95 van toepassing is.

Je veranderd ook het onderwerp elke keer als je een fout maakt.

Helemaal niet. Ik blijf nog steeds bij mijn originele punt: OpenGL-support was in de beginjaren van 3d-acceleratie (1995-1999) heel beperkt.

-De powerVR implementatie van MiniGL heeft het nooit gehaald bij het grote publiek, zoals je hoort te weten.

Ten eerste is het niet 'de implementatie', want PowerVR heeft verschillende MiniGL-drivers gemaakt, voor verschillende spellen.
Ten tweede, wat heeft dat ermee te maken?
Je bent duidelijk zelf degene die steeds van onderwerp wisselt. Eerst haalde je Glide wrappers erbij (die er dus niks mee te maken hebben), en nu begin je weer over 'nooit gehaald bij het grote publiek'. Geen idee wat je daarmee wil zeggen. Ik heb de MiniGL drivers voor GLQuake en Quake 2 altijd gehad, stonden volgens mij gewoon op de driver-CD van m'n Apocalypse 3Dx.
Die van Half-Life had ik nog niet, maar die kon je van het internet plukken.

Aan de andere kant beweerde je eerder dat sommige kaarten nooit de markt haalden, terwijl ik ze toch echt in mijn handen heb gehad.

Waar beweerde ik dat? Ik heb even teruggelezen, maar kan echt niets vinden dat ook maar enigszins in die richting wijst.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 18:39]

[arendjr]

Als OpenGL Next inderdaad flinke stukken van Mantle overneemt lijkt me dat inderdaad een goede zaak. Dat betekent namelijk dat het supporten van OpenGL Next voor developers die al geïnvesteerd hebben in Mantle ook weer makkelijker wordt. Bovendien heeft AMD het afgelopen jaar toch ook al weer flink wat praktijkervaring op kunnen doen met Mantle.

Dat gecombineerd met de kennis van Nvidia die nu al het onderste uit OpenGL proberen te halen (met flink succes, zie o.a. slides van de Steam Dev Days waar Nvidia ook aanwezig was), denk ik dat dit wel iets heel moois kan worden.

[Amanoo]

Ik zie het denk ik wel zitten. Opnemen van Mantle technologie in OpenGL zal ook Nvidia forceren deze Mantle technologie de ondersteunen, waardoor het al veel meer een standaard wordt en Nvidia ook moeilijker zal kunnen vasthouden aan eigen gesloten API's.

Zou het ook Linux een boost kunnen geven? Als ontwikkelaars Mantle gebruiken werkt meteen de grafische engine al half op Linux, dankzij de adoptie in OpenGL, waardoor Mantle meteen al aanwezig is in Linux? Of praat ik nu onzin?

[Reactie gewijzigd door Amanoo op 23 juli 2024 18:39]

[SinergyX]

Tja, einde van de rit zal het de Engine makers zijn die de keuze maken welke API zij gebruiken. Veel games maken gebruik van een vaste engine (Unreal, Unity, Frost), dat het voor games an sich niet bijzonder veel uitmaakt.

Daarnaast zit er buiten optimalisatie van API natuurlijk nog een baggervloot aan optimalisatie binnen de game. Je kan de beste hardware en API's hebben, als de rest van de game slecht geschreven is, win je er per saldo nog niets mee.