AMD port Mantle naar Linux

AMD is bezig met het porten van Mantle naar Linux, zo zegt een gamingspecialist van de fabrikant tegen de Duitse site ComputerBase. Hoe en wanneer Mantle voor Linux uitkomt, is onbekend. De DirectX-concurrent draait nu alleen nog op Windows.

AMD zou volgens de specialist van het bedrijf talloze verzoeken hebben gekregen van ontwikkelaars om Mantle naar Linux te porten, schrijft ComputerBase. Dat zou te maken hebben met de aankomende release van Steamboxen, pc's met het op een Linux-kernel gebaseerde Steam OS van Valve. Valve zou bovendien zelf baat hebben bij een port van Mantle naar Linux, speculeert de site.

Mantle is een alternatief voor DirectX voor het renderen van 2d- en 3d-graphics. Omdat het in tegenstelling tot DirectX meer 'low-level' werkt, ontlast het de cpu en kunnen game-ontwikkelaars 'dichter op de hardware' programmeren. Tweakers concludeerde dan ook dat vooral gebruikers met mindere cpu's en krachtige videokaarten profiteren van Mantle.

Wanneer Mantle voor LInux uitkomt, zegt het bedrijf niet in de verklaring. Steamboxen zullen in het komende jaar op de markt komen.

Reacties (185)

[apronk]

Is decennia geleden al met succes gedaan door 3DFX, dat heette Glide en was veel meer performant dan DirectX of OpenGL door de low-level access.
Simpel gezegd zijn de basis OpenGL instructies rechtstreeks in de GPU gezet, daardoor werkte het zo verrekte snel.
Helaas werkte Glide dus alleen maar met 3DFX kaarten, en hun hardware was verder niet echt om over naar huis te schrijven, maar door de performance van Glide vele malen beter dan de concurrentie.
Op DirectX en OpenGL terrein verloor het redelijk snel van nVidia, maar Glide werkte ook al prima onder Linux in die tijd.
Ik hoop dat Mantle dezelfde kant op gaat maar het dus wel beschikbaar stelt aan andere GPU makers en daar een standaard in komt.

[PeterBezemer]

op linux is mantle veel interessanter dan op windows, omdat je daar al directx hebt, denk ik...

[CrimInalA]

Ik had niet verwacht dat het zou gebeuren . Fantastisch nieuws , lang op gehoopt .

[Cilph]

Ik sta verteld. Had dit niet van ze verwacht gezien de rampzalige kwaliteit van de Linux drivers.

[Nonstop decay]

Nou..., rampzalige Linuxdrivers? Gelukkig gaat dat al een heel eind de goede kant op.
Zie bijvoorbeeld:
http://www.phoronix.com/s...t144_win81_ubuntu14&num=2
http://www.phoronix.com/s...m=radeon_1404_win81&num=2

Ik vind ze best prima nu, en ik denk dat het alleen nog maar beter wordt.

On-topic: Top dat ze Mantle ook naar Linux brengen! Ik ben benieuwd hoelang het gaat duren en hoe het gaat werken.

[GewoonWatSpulle]

Misschien is dit juist een reden, een verse start, geen 'oude' driver code maar puur Mantle support.

[Alfa1970]

Mantle is alleen maar een API schil, die moet nog wel met de driver praten om bij de hardware te kunnen.
Dus al is Mantle geweldig, zo lang de drivers ruk zijn gaat niemand er op vooruit.

[Titan_Fox]

Als AMD de Mantle API naar Linux gaat brengen zullen ze er heus wel voor zorgen dat de drivers eindelijk fatsoenlijk zullen werken. Toegegeven; dit heeft véél te lang moeten duren. Ik denk dat we Steam heel erg dankbaar mogen zijn dat zij deze gewaagde stap hebben durven zetten. Door hun is het hele "games for Linux" verhaal aan het rollen gekomen; fabrikanten krijgen nu eindelijk de motivatie om eens wat anders dan enkel Windows en MacOS te ondersteunen.

[Tijger]

Mjah, dat van het bedrijf dat al jaren lang geen fatsoenlijke OpenGL drivers weet te maken voor Linux maar met Mantle gaat dat ineens natuurlijk wel lukken...uh...ja. Beetje optimistisch gedacht mischien.

[Countess]

bij mantle is de driver laag maar heel dun. veel veel minder werk als drivers voor openGL of directX maken dus.

en nog belangrijker je hoeft ze niet voor elk spel individueel aan te passen om goede performance te krijgen. dat moeten de game developers nu zelf doen (zoals het hoort!)

[Verwijderd]

en nog belangrijker je hoeft ze niet voor elk spel individueel aan te passen om goede performance te krijgen. dat moeten de game developers nu zelf doen (zoals het hoort!)

Lijkt mij niet hoor.
Bij OpenGL en Direct3D is het ook nooit de bedoeling geweest dat er driver-optimalisaties per applicatie zouden komen, maarja, dat is concurrentie he.

Ik zie dan ook niet waarom het bij Mantle anders zou zijn... Als er een game/benchmark is die niet zo efficient loopt onder Mantle, dan zal AMD vast wel wat app-specifieke tweaks/cheats/replacements in de driver bakken.

[Countess]

vast, grote verschil is echter dat de developer er met mantle zelf VEEL meer controle over heeft en niet meer met 2 grote black boxes moet werken.

die 2 black boxes achter elkaar maken tweaks aan de laatste box onvermijdelijk als je maximale performance wil.

met mantle word het 1 black box, en dan maar een heel klein dun doosje. het is dus veel transparanter wat er gebeurt en daarom veel gemakkelijker voor de developers om zelf te optimaliseren.

[Verwijderd]

met mantle word het 1 black box, en dan maar een heel klein dun doosje. het is dus veel transparanter wat er gebeurt en daarom veel gemakkelijker voor de developers om zelf te optimaliseren.

Het blijven altijd 2 black boxes:
De API/driver-laag, en de GPU zelf.
Je hebt nu al te maken met vrij veel verschillende varianten van GPUs. Ten eerste natuurlijk GCN 1.0, 1.1 en 2.0. Ten tweede verschillen in shadercount, geheugenbandbreedte etc.
Code schrijven die op alle mogelijke configuraties optimaal werkt, is dus erg lastig.

Zeker als er in de toekomst weer nieuwe chips uitkomen, is de kans groot dat de code niet optimaal is voor die chips. Er kon immers tijdens het ontwikkelen van de game geen rekening worden gehouden met de mogelijkheden en beperkingen van die chips. Dit kan AMD dan in de drivers ondervangen.

[Countess]

dan waren het er hiervoor 3 black boxes.

en driver optimalisaties voor oude games op nieuwe gpu's zag je toch al nauwelijks.

waarschijnlijker is dat de engine makers verantwoordelijk gaan zijn voor goede implementaties voor nieuwe hardware (dat moeten ze toch als ze hun engine willen blijven verkopen) . en dan kan iedereen voor zich beslissen of ze voor hun game een patch uit brengen of niet.

[Verwijderd]

dan waren het er hiervoor 3 black boxes.

Wat is de derde dan, als de eerste twee API/driver-laag en GPU zijn, zoals ik al zei?

en driver optimalisaties voor oude games op nieuwe gpu's zag je toch al nauwelijks.

Zeker wel.
'Oud' is relatief. Een game die een paar maanden gereleased is voordat een nieuwe GPU op de markt komt, is niet 'oud', daar wordt echt wel voor geoptimaliseerd.
Bij populaire games kan het zelfs een aantal jaren na release nog interessant zijn (zeker als ze veel gebruikt worden in benchmarks, zoals Crysis).

waarschijnlijker is dat de engine makers verantwoordelijk gaan zijn voor goede implementaties voor nieuwe hardware (dat moeten ze toch als ze hun engine willen blijven verkopen) . en dan kan iedereen voor zich beslissen of ze voor hun game een patch uit brengen of niet.

Lijkt me juist niet waarschijnlijk. Over het algemeen is een game gewoon EOL zodra ie released is. Eventuele patches omdat de game niet is te spelen, okee... Maar optimalisaties/nieuwe renderpaths, dat gebeurt zelden of nooit.

[2green]

Wat zeg je nou? Mantle is onderdeel van de driver, juist om het overhead te beperken ( closer to the metal).

"Mantle reduces the CPU’s workload by giving developers a way to talk to the GPU directly with much less translation. With less work for the CPU to do, programmers can squeeze much more performance from a system, delivering the greatest benefits in gaming systems where the CPU can be the bottleneck."

Bron: amd

Edit: bron toegevoegd

[Reactie gewijzigd door 2green op 23 juli 2024 19:18]

[Tijger]

En weten we allemaal nog de les van drivers die close to the metal opereren en waarom we die niet meer gebruiken? Blijkbaar zijn we de lessen uit het verleden vergeten.

[Countess]

veel lessen van zo lang geleden zijn niet meer relevant voor vandaag de dag. de hardware is in vele opzichten heel uniform, zelfs tussen AMD nvidia en intel, waar het vroeger een wildgroei was aan variaties.

zelfs de structuur van de huigige GPU's lijkt vrij veel op elkaar, en daarom is een universele API met maar een dunne abstractielaag nu wel haalbaar en praktische waar dat 15-20 jaar geleden gewoon niet mogelijk was.

[Verwijderd]

zelfs de structuur van de huigige GPU's lijkt vrij veel op elkaar, en daarom is een universele API met maar een dunne abstractielaag nu wel haalbaar en praktische waar dat 15-20 jaar geleden gewoon niet mogelijk was.

Eigenlijk is dat helemaal niet waar.
De oorspronkelijke Direct3D was ook buffer-georienteerd, en had al heel goed gewerkt voor de huidige aanpak met multithreading.
Ik had dat zelf al een tijd geleden gezegd: Verwijderd in 'nieuws: AMD: updates voor OpenGL en DirectX liggen in lijn met Mantle-visie'
Nu zegt Alex St. John (1 van de D3D-ontwikkelaars van het eerste uur) hetzelfde op zijn blog: http://www.alexstjohn.com...opengl-metal-full-circle/

Destijds vonden ontwikkelaars het maar lastig om direct GPU-instructies te bufferen en naar de kaart te sturen, en kozen ze voor de simpele OpenGL-achtige high-level manier.
Dit bleek een foute keuze: nu willen ze alsnog die low-level buffers.
Full circle dus.

[acemoo]

Nee weet ik niet

[2green]

Ehm... Ik dacht dat die les alleen voor noobs gelde? Als technische informaticus zie ik het in elk geval heel anders.

[Verwijderd]

Nee, noobs (als in: programmeurs die niet in het DOS-tijdperk hebben gewerkt) hebben dat lesje nooit geleerd.
Wij 'DOS-veteranen' weten wel beter: het is ondoenlijk om hardware direct aan te spreken, of via een 'close-to-metal' laagje als VESA.
Zoveel software die niet goed (meer) werkt, of waar je alleen op 'select few' videokaarten bepaalde features kon gebruiken, omdat de rest die features wel had, maar het net niet 100% compatible was op hardware-niveau.

En ook in het begin van het Windows-tijdperk... Dingen als Glide en PowerSGL waren heel leuk... maar dat krijg je nu niet meer aan de praat (al zijn er dan wel weer Glide-wrappers met meer of minder succes).
Glide verdween omdat 3dfx omviel. PowerSGL verdween omdat PowerVR een andere richting op ging qua architectuur, en het niet de moeite waard vond om PowerSGL te blijven ondersteunen. Ik zie Mantle precies dezelfde kant opgaan. Over een paar jaar stappen we over op programmable rasterizing, raytracing of iets... en dan komen er compleet andere GPUs, waar Mantle totaal niet op aansluit.

Games die Direct3D en/of OpenGL supporten, werken daarentegen vaak nog steeds op een moderne Windows 8.1-machine.

[GewoonWatSpulle]

Die zelfde driver moet nu OpenGL en DirectX ondersteuning brengen, alle twee standaarden die zij zelf niet verzonnnen hebben.
Nu kunnen ze het van core tot scherm pixel zelf bepalen, als dat geen voordelen bied dan weet ik het ook niet meer.

[Countess]

Ik sta verteld. Had dit niet van ze verwacht gezien de rampzalige kwaliteit van de Linux drivers.

je loopt een jaar of 2 a 3 achter.

[Reactie gewijzigd door Countess op 23 juli 2024 19:18]

[Spekkie88]

Nice, als je de verschillende verhalen van developpers mag geloven is OpenGL namelijk een crime... Op deze manier zou Mantle nog wel eens heel groot kunnen gaan worden...

[Verwijderd]

OpenGL is verre van 'een crime'

DirectX is alleen maar zo wijdverspreid omdat het de boel makkelijker maakt voor developers door middel van allerhande handige wrappers en functies.

OpenGL is meer 'to the bone', het kost misschien wat meer moeite ervoor te ontwikkelen, maar de performance is wel 2 tot 3 voud.

Er is ook een reden waarom in ziekenhuizen en labratoria enzo vrijwel exclusief met OpenGL word gewerkt, het is gewoon een stuk beter in het tonen van enorme complexe modellen.

En inderdaad, mobieltjes vandaag de dag maken allemaal volop gebruik van OpenGL, maar bijvoorbeeld WebGL is ook een snel groeiend platform, wat feitelijk ook gewoon OpenGL is.

Microsoft verliest markt (met DirectX), maar ze zijn op het moment druk met het proberen boven water te houden van de XOne, reken er echter maar op dat binnenkort berichten naar buiten komen over DX12 met weer een of andere nieuwe vorm van 'tesselation', of een ander trucje om betere performance te krijgen.

De grap is, OpenGL heeft die truc's niet nodig, gaan ze die echter op een gegeven moment wel implementeren, zal OpenGL meteen de grootste woorden, want dan krijg je helemaal een enorm performance verschil.

[Silmarunya]

OpenGL wordt gebruikt in biotechnologie omdat bijna alle scientific computing in Linux gebeurt. Mogelijk is er een performancevoordeel, maar daar heb ik nooit iets over gelezen. Toch niet '2-3 maal'.

Overigens is het visualiseren van eiwitten waarnaar je verwijst grafisch niet zo heel bijzonder. Het is vooral de structuur modelleren dat enorm rekenintensief is, het weergeven ervan kan een oude Intel IGP.

[koelpasta]

"OpenGL is meer 'to the bone', het kost misschien wat meer moeite ervoor te ontwikkelen, maar de performance is wel 2 tot 3 voud."

LOL,,.,. als dit waar was dan bestond directx op de pc niet meer en was iedereen onder windows overgestapt op opengl.
Onzin dus.

[Spekkie88]

Zulke performance winst heb ik nog nooit gezien... Verder is de reden volgens mij in ziekenhuizen meer dat al die apparatuur werkt met linux en niet met windows. Zo heeft mijn vriendin meerdere malen moeten werken met MRI scanners en daar was de frontend linux based en geen windows. Waarmee je dus per defenitie bent aangewezen op OpenGL.

[xleeuwx]

Afhankelijk per ziekenhuis, maar inderdaad er zijn apparatuur dat op *nix draait en er zijn ook zat apparatuur dat op windows draait

[Alfa1970]

het kost misschien wat meer moeite ervoor te ontwikkelen

En dat is nu precies het heikele punt waarom OpenGL het aflegt tegen DirectX.

Het ontwikkelen voor DirectX is makkelijker (meer tools), dus kost het minder, dus zullen meer ontwikkelaars dat gebruiken.

Beetje zoals het Betamax versus VHS verhaal..

[Verwijderd]

Het gaat in de praktijk ook helemaal niet om of welke sneller of beter is. OpenGL is open. En iedereen mag het toepassen. Dit zorgt ervoor dat het een snellere keus zal worden dan DirectX. Bijna elk apparaat heeft een OS. En niet op elk apparaat is een Windows OS voor.

Ook al is OpenGL niet beter of sneller. Dan nog kan het DirectX volkomen verslaan.

Iets beters wint niet altijd. Daar zijn miljoenen voorbeelden van. Er spelen vaak ook andere belangen zoals vrijheid, openheid en omarming van technologie door de markt.

Microsoft heeft jaren lang druk kunnen zetten vanwege hun monopolie. Echter is de klassieke desktop PC niet de enigste computer meer met een "echt" operating systeem. We hebben nu tablets/telefoons/autoradio's/TV's/koelkasten die soms en vaak gewoon een compleet operating systeem bevatten welke niet de herkomst Microsoft heeft en dus daarom geen DirectX kan gebruiken. Dan is de enige keuze OpenGL.

[dmantione]

omdat het de specificatie meer gericht is om CAD e.d. dan op spellen.

Dat OpenGL ook voor CAD gebruikt wordt is juist, maar deze uitspraak ben ik het mee oneens. Ik kan weinig specifieks in de OpenGL-API ontdekken waarvan je nu zegt dat ze dat zo voor CAD gedaan hebben. Het is een teken-API. Of een spel nu tekent of een CAD-applicatie, om het even.

[Verwijderd]

Er zit inderdaad niets specifiek aan CAD in OpenGL... maar men is wel verschrikkelijk langzaam in het implementeren van zaken die specifiek voor games nuttig zijn. Shaders bijvoorbeeld zijn de grote doorbraak van DirectX-9 geweest, omdat het daar allemaal keurig gestandaardiseerd was, en perfect implementeerbaar voor de developers. OpenGL deed daar lange tijd niets aan, en DX9 type shaders moesten via proprietaire extenties toegevoegd worden. Dat is een mooi voorbeeld hoe men bij de OpenGL specificatie geen interesse in spellen heeft. Vanaf dat moment zet DirectX gewoon de toon, en OpenGL voegt het naderhand eventueel ook toe in hun specs...

In principe maakt het weinig uit welke van de twee je gebruikt, maar DirectX is gewoon meer up-to-date en vernieuwender wat betreft games.

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

[Verwijderd]

Shaders bijvoorbeeld zijn de grote doorbraak van DirectX-9 geweest, omdat het daar allemaal keurig gestandaardiseerd was, en perfect implementeerbaar voor de developers.

DirectX 8 al, hoor.
Die hele generatie van SM1.x shaders is compleet genegeerd door OpenGL.
DirectX 9 kwam met SM2.0, en pas veel later kwam OpenGL eindelijk met hun shader-standaarden... eerst de lelijke ARB 'assembly' shaders, en later GLSL. Voor beiden heb je minimaal SM2.0 nodig.
Voor de eerste generatie shader-hardware heb je in OpenGL alleen vendor-specifieke extensies, en daardoor is het nooit op grote schaal gebruikt.

[Verwijderd]

Tegenwoordig wel ja... Vroeger niet. OpenGL had destijds bv hogere eisen qua precisie voor rasterizen, textureren en shading dan Direct3D. Voor CAD/CAM was precisie immers belangrijk... Voor games konden er hier en daar wel wat stukjes afgesneden worden om de kaarten goedkoper te maken en/of betere framerates te krijgen.
Eisen waar de eerste generaties van consumenten-accelerators dus niet aan konden voldoen.
Daarom werd OpenGL dus in eerste instantie ook niet voor games gebruikt, en was er ruimte voor APIs als Glide en Direct3D.
Tegenwoordig is er geen onderscheid meer.

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

[koelpasta]

"Tegenwoordig wel ja... Vroeger niet. "

Volgens mij zitten er tegenwoordig ook gewoon nog een zooi primitives in opengl die ooit voor CAD zijn bedacht en niet door games worden gebruik.
Delen van de engine zien ook nog steeds het liefst datastructuren die afkomstig zijn uit de CAD-tijd.

[Verwijderd]

Ligt eraan wat je 'tegenwoordig' noemt...
OpenGL heeft nu een 'core' profile, en een 'legacy' profile.
In 'legacy' modus ondersteunt ie dus nog steeds oude meuk.
Het 'core'-profile is echter compleet gebaseerd op shaders en buffers, en werkt vrijwel hetzelfde als Direct3D.

Overigens is met CAD/CAM software als Autocad tegenwoordig D3D de default renderer.

[Verwijderd]

Wat een ongelooflijke onzin. Je hebt duidelijk geen flauwe benul van waar je over praat.

OpenGL is geen zier sneller dan DirectX

Oke, als jij daar beter van slaapt, blijf dat lekker denken, lekker ongezouten mening ook trouwens. Ondertussen lees ik al een 2 jaar mee met de ontwikkelingen binnen Valve en Nvidia, waar die cijfers vandaan komen. (even googlen en je vind ze ook)

En het is trouwens Carmack he, niet Carmick, geinporem.

[Verwijderd]

Ondertussen lees ik al een 2 jaar mee met de ontwikkelingen binnen Valve en Nvidia, waar die cijfers vandaan komen. (even googlen en je vind ze ook)

Lees je ook wel eens onafhankelijke benchmarks?
reviews: SteamOS: nieuw gameplatform bouwt druk op
http://rootgamer.com/2737...er-strikesource-benchmark

[2green]

Je bronnen gebruiken in test 1 een beta versie van een os met opengl tegen een stable met directx, dit is een waardeloze vergelijking.

Bron 2 is al een stuk beter, hier zie je inderdaad dat opengl in de drivers nog niet zo ver geoptimaliseerd zijn als directx. Ben benieuwd wat de resulten nu een jaar later zijn, nu de drivers verder verbeterd zijn.

Wat ik mij ook afvraag is of de opengl driver wel werkelijk zo goed presteerd een jqar geleden, heb al veel testen gezien en gedaam, waarbij de dirextx test alle functies uitvoerde en die voor opengl functie oversloeg.

Verder een interesante test trouwens, beter dan het meeste wat ik tegenkom.

[Verwijderd]

Je bronnen gebruiken in test 1 een beta versie van een os met opengl tegen een stable met directx, dit is een waardeloze vergelijking.

De claims van Valve dat hun linux/OpenGL versie sneller was, zijn anders al veel ouder dan de versie die daar getest is.

[2green]

Klopt. Ik betwijfel ook of uiteindelijk veel verschil gaat zitten in opengl en directx. Als er al in eentje straks voordelen gevonden worden tov de ander dan corrigeert met de fout/bottleneck toch wel. Net als valvemin overleg met anderen heeft gedaan toen opengl in genoemde test sneller bleek. Het enige voordeel dat opengl heeft is datmhet dichtermop de metal geprogrammerd kan worden, maar daarm anticipeert ms al op mrt toekomstige directx aanpassingen.

Ben benieuw waar de nieuwe opengl specs mee komen, wat amd van plan is en waar valve mee komt. Geloof er niets van dat de gamepads niet tijdig klaar konden zijn. Vermoed driver wensen e.d.

[koelpasta]

"Ondertussen lees ik al een 2 jaar mee met de ontwikkelingen binnen Valve en Nvidia, waar die cijfers vandaan komen. (even googlen en je vind ze ook)"

Sorry hoor, maar valve maakt geen high end engines.
Noem 1 valve game waar een moderne high end videokaart warm van wordt..

[Verwijderd]

Hahahaha echt? dat is je definitie van een high end engine? als de gpu warm word?

En 'high end' is niet echt het doel geweest van de (huidige) engine, een van de speerpunten van de Source engine is juist dat het ontzettend schaalbaar is, je kan bijvoorbeeld portal2 of dota2 op een nieuwe pc met allerlij toeters en bellen spelen, maar ook nog op een pentium 3.

Echter gaat het hier in de verste verte niet over de engine, maar over SteamOS en samenwerkingen tussen Valve en Nvidia/AMD

[koelpasta]

"En 'high end' is niet echt het doel geweest van de (huidige) engine, een van de speerpunten van de Source engine is juist dat het ontzettend schaalbaar is, je kan bijvoorbeeld portal2 of dota2 op een nieuwe pc met allerlij toeters en bellen spelen, maar ook nog op een pentium 3. "

Grapjas. We hadden het over performance en jij kwam met het verhaal dat opengl 2 a 3 keer sneller was dan directx...
Maar nu kom je opeens aan met schaalbaarheid en dat 'high end' niet het doel is geweest.
Even voor de duidelijkheid. De 'huidige' versie van de steam engine is een opgedirkte versie van een 10 jaar oude engine en is hevig aan vervanging toe. Valve games zien er dan ook behoorlijk gedateerd uit wat betreft graphics, zowel in dx als in ogl.
Wat mij betreft heeft valve geen recht van spreken als het aankomt op high end graphics. Is gewoon niet hun business.

En ja, als je gpu niet warm wordt dan weet je op zn minst datie uit zn neus staat te vreten.

[Verwijderd]

Inderdaad, de GPU-temperatuur zegt niet zo veel...
Neem iets als Furmark: stelt op zich niets voor, maar het houdt de GPU wel flink bezig.
Wat dat betreft kunnen de meeste engines een GPU wel hard aan het werk zetten... Als je de resolutie maar hoog genoeg zet, AA flink opkrikken, en de CPU-effecten zo laag mogelijk, om te voorkomen dat je een CPU-bottleneck krijgt, dan moet die GPU er flink aan trekken.

Een goede/moderne engine probeert de GPU zo efficient mogelijk aan te sturen, zodat de graphics zo gedetailleerd mogelijk zijn, en toch nog goed speelbare framerates te halen zijn.

De engines van Valve vallen hier inderdaad niet onder, omdat ze technisch ver achterlopen, en een beetje PC makkelijk een game als Portal 2 op honderden FPS kan draaien, zelfs op 1080p en hoger, met AA.

[Verwijderd]

Edit: terecht inderdaad, gezien de blog

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

[VNA9216]

Beter is erg relatief. Direct3D en openGL hebben een aanpak die nogal verschilt. Je kan met beide geweldige games maken, alleen de denkwijze van de programmeur moet wat anders zijn.

Je kan beter geen programmeur die al 10 jaar met Direct3D werkt in ene zonder training iets met openGL laten maken, en andersom ook niet. Dan krijg je van die reacties zoals we de afgelopen jaren wel van game devs gezien hebben die hun engine hebben geport naar een andere techniek.

Beide technieken zijn prima, iedere techniek heeft zn voor en nadelen, en imho kan je niet echt zeggen dat de een beter is dan de ander. Het is een stukje gewenning.
Alleen de debugging tools voor openGL zijn een tijd ondermaats geweest. Al is die situatie de laatste jaren flink verbeterd

[Spekkie88]

Op phoronix zijn de afgelopen tijd verschillende referenties geweest naar blogs/uitlatingen van verschillende developpers over de problemen van OpenGL. Dit is er bijvoorbeeld 1 van.

Wat ik tot nu toe van heb vernomen is dat voor linux OpenGL eerder een noodzakelijk kwaad is volgens die developpers. Het is dan ook goed om te zien dat er nu een alternatief komt voor Linux, dat hopelijk fijner werkt.

[Reactie gewijzigd door Spekkie88 op 23 juli 2024 19:18]

[FreezeXJ]

Mantle blijft voor een groot deel OpenGL hoor, maar het kan bepaalde calls verhuizen van je CPU naar je GPU. Verder is OpenGL zo erg niet, het is alleen oud. Te oud, eigenlijk. Wellicht kan een fikse update daar verandering in brengen, zodat we ook onder open-source een prettige grafische toolkit hebben.

[it0]

Ja opengl is vreselijk kijk maar naar android en ios waar alles opengl is...

[Neko Koneko]

Spectaculaire graphics inderdaad

[Remz]

Metal != Mantle

Mantle is voor AMD kaarten
Metal is voor Apple socs

[Remenic]

Metal.

[dragon9114]

iOS8 krijgt de Metal API en niet Mantle.

[eL_Jay]

Bam. en in 1 keer wordt mantle wel interessant (voor mij)

[Pikkemans]

Die steamboxen kunnen nog een leuke markt gaan worden. Verstandig om erin te springen zoals AMD doet. Vooral omdat AMD Mantle een open API is.

[Verwijderd]

Hoewel ik zeker hulde wil geven aan AMD voor het maken van deze stap, kan je nou niet echt zeggen dat ze erin zijn gesprongen, Valve probeert al bijna 2 jaar AMD aan de linux te krijgen, en is al ongeveer net zo lang wel bezig met nvidia (samenwerken aan linux drivers enzo)

[jiriw]

En toch zijn de open-source drivers (zie laatst de tests van Phoronix) voor AMD kaarten beter (mede door het goed leveren van hardwarespecificaties door AMD aan de opensource gemeenschap) dan die voor NVidia kaarten.
De closed-source linux drivers van NVidia zijn dan overigens wel weer beter...

Het is allemaal relatief. AMD en NVidia leggen hun accenten op andere plekken. Valve heeft baat bij goed werkende drivers voor games. Maakt niet uit of ze open of gesloten zijn en had natuurlijk graag wat handjes van AMD 'geleend' voor goede drivers. Maar AMD heeft altijd al een wat minder (kleiner?) driverontwikkelteam gehad dus ik denk dat ze liever hun driverontwikkeling op Windows richten en verder met fatsoenlijke specificaties open-source teams willen ondersteunen (i.p.v. dat alles gerieverse-engeneerd moet worden). Het lijkt mij nogal logisch dat ze de keuzes maken die ze doen.

[himlims_]

Er is wat van te zeggen, maar, AMD laat hier een kans liggen. Voor zo ver ik begrijp, is de prestatie van AMD tozv Nvidia vaak meer 'bang for bucks' (bij windows).

Linux land is compleet andersom; AMD prestaties is ver ver onder de maat tozv Nvidia drivers.

Dit platform is sterk in opkomst, en ontwikkelaars stellen hun games steedsvaker voor linux beschikbaar. Daar lag een kans voor AMD; een nieuwe markt, sterk aan het groeien die inmiddels de MAC voorbij is!

Door mijn linux gaming pagina heb ik veeel contacten opgedaan, en 99% draait op een nvidia opstelling omdat AMD slechte drivers heeft, die ook nog eens slecht presteren. Ondanks de FU van Linus blijft nvidia de nummer 1. Daar waar Intel serieus stappen aan het maken is, en zal me niet verbazen dat die begin volgend jaar AMD voorbij gaan.

let wel; bij oude hardware gaat dit niet op

[Titan_Fox]

Ik word hier absoluut blij van ! Het lijkt erop dat Linux eindelijk begint door te breken en dat dit geweldige OS ook voor vastgeroeste Windows-gamers tot een volwaardig alternatief kan worden.

Het fijne is dat Mantle veel dichter op de hardware zit. Hiermee kun je bij games die het ondersteunen betere prestaties verwachten op oudere hardware. Doordat Linux sowieso stukken vlotter is dan Windows ben ik erg benieuwd naar toekomstige benchmarks.

Op de een of andere manier heb ik het gevoel dat Microsoft over haar hoogtepunt heen is en met de tijd steeds minder relevant zal gaan worden. Ik kan dit enkel toejuichen; meer open software zal zorgen voor betere compatibiliteit, omdat er nog veel te veel gesloten software wordt gebruikt die aan alle kanten worden dicht getimmerd met proprietary patenten.

[Reactie gewijzigd door Titan_Fox op 23 juli 2024 19:18]

[NTAuthority]

Open API? Dacht het niet.

[2green]

AMD zegt anders van wel, volgens de bron waar tweakers naar refereert.

"Huddy said that Mantle is an open-source API. But the Mantle tools have largely been shared with game makers, and the company has not said when they will be opened up to the wider development community."

Edit: bron aangepast

[Reactie gewijzigd door 2green op 23 juli 2024 19:18]

[Verwijderd]

Dan heeft Huddy een beetje een raar idee van wat open source is.
Open source houdt normaal gesproken in dat IEDEREEN toegang tot de source code heeft.
Op dit moment hebben alleen een paar AMD-partners uberhaupt toegang tot Mantle development tools. Of die de source ook hebben of niet, is niet duidelijk (DICE zal dat wel hebben, die hebben immers mee-ontwikkeld).
Maar ik als 'normale' developer kan niet eens een simpele SDK downloaden met headers, libraries, en iets van documentatie, om uberhaupt een Mantle-app te kunnen bouwen.
Daarmee is het dus meer gesloten dan bv DirectX, Cuda, PhysX of OpenGL.

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

[GORby]

Open Source wil niet zeggen dat iedereen de broncode mag hebben...
Open Source wil zeggen dat je de broncode moet beschikbaar stellen aan degenen aan wie je je product levert. Wanneer zij dus het product leveren aan 3 bedrijven en daar ook de broncode bij stoppen, kunnen ze perfect zeggen dat het open source is.
Afhankelijk van de licentie kunnen die bedrijven dan bepaalde dingen met die broncode doen, of niet.

[Verwijderd]

Open Source wil niet zeggen dat iedereen de broncode mag hebben...

Jawel, zoals ik al zei: http://en.wikipedia.org/wiki/Open_source

In production and development, open source as a development model promotes a universal access via free license to a product's design or blueprint, and b) universal redistribution of that design or blueprint, including subsequent improvements to it by anyone.

Iedereen dus.

Volgens mij ben jij in de war met dingen als 'shared source', waarbij je toegang tot de broncode kunt krijgen onder bepaalde voorwaarden. Maar open source is *per definitie* toegankelijk tot iedereen.

[2green]

De beperkte toegang is inderdaad een veel gehoorde klacht, maar sluit noet uit dat het een opensource product is. Een soortgelijk voorbeeld is android, waar de code ook pas later van vrijgegeven werd.

Vind deze strategie nooit netjes trouwens, maar begrijp waarom amd het in dit geval doet. Techinische voorsprong en toch brede uitrol door de open api.

[Verwijderd]

De beperkte toegang is inderdaad een veel gehoorde klacht, maar sluit noet uit dat het een opensource product is.

Jawel.
Bij een opensource product is de source per definitie beschikbaar.
Het sluit niet uit dat Mantle ergens in de toekomst opensource zou kunnen worden, maar dat *is* het dus niet, op dit moment. Roepen dat het wel zo is, is gewoon misleidende marketing van Huddy.

Techinische voorsprong en toch brede uitrol door de open api.

Laten we ten eerste niet de terminologie door elkaar halen. Een open standaard/open API is niet hetzelfde als open source.
Ten tweede, het open zijn van een standaard of API garandeert nog niet dat het breed uitgerold wordt.
nVidia en Microsoft hebben al officieel bekendgemaakt dat ze geen Mantle gaan ondersteunen. Van Intel en Sony verwacht ik ook niet dat ze dat gaan doen. Intel heeft genoeg aan DX12 support, en Sony heeft al z'n eigen low-level API op de PS4. Niemand heeft belang bij Mantle.

[2green]

Kwestie van de definitie dat je hanteerd van opensource. De wereld is er nog niet uit, alhoewel jij dat klaarblijkelijk wel bent. Zie het android voorbeeld wat ik noemde. Zoals ik al zei vind ik het ook niet correct, maar helaas komt en verlate code vrjgave steeds meer voor.

Laten we inderdaad de definties niet door elkaar halen... Een api is source code, dus open api = open source.

Voor de rest heb ik ook gelezen dat nvidia en intel geen mantle ondersteunen, maar dit staat een bredere uitrol nog steeds niet in de weg. Het zijn de game ontwikkelaars die het willen en zo te lezen ook gaan krijgen.

[koelpasta]

" Een api is source code, dus open api = open source. "

Je kunt de definitie van een api los zien van een implementatie.
Volgens mij is mantle een open standaard.
Een open standaard betekent nog niet dat de source code van een implementatie automatisch open source is.

[2green]

Eens

[Blokker_1999]

De definitie ligt toch echt vast hoor. Bij open source heeft de eindgebruiker van een product het recht om de broncode van dat product in te zien. Door bijv. het laattijdig beschikbaar stellen van broncode (soms pas maanden na release) bij bijv. Android schenden fabrikanten de GPL die vasthangt aan bepaalde onderdelen van dat OS.

[2green]

Ok en toch wordt het opensource genoemd voorafgaand aanmde release van zo' versie.

[Verwijderd]

Zie het android voorbeeld wat ik noemde.

Maar de Android-source is ook openbaar, van Mantle hebben we nog NIETS.

Laten we inderdaad de definties niet door elkaar halen... Een api is source code, dus open api = open source.

Nee, een API is geen source code. Een API is een Application Programming Interface. Dat is dus een verzameling functie-definities en datastructuren.

Sowieso vind ik het nogal onlogisch om het over open source te hebben bij iets als Mantle. De implementatie van Mantle is hardware-specifiek, dat is gewoon de driver. Daar hebben game developers en andere IHVs ook niet zo heel veel aan. De implementaties van Direct3D en OpenGL waren ook niet open source, en dat heeft ook niemand ervan weerhouden om er hardware-drivers voor te bouwen of games mee te schrijven.

Ik denk eerlijk gezegd niet dat AMD z'n hele driver open source maakt (omdat daar vast gepatenteerde technologie in zit), en dus denk ik dat Huddy eigenlijk uit z'n nek kletst. Ik denk dat hij bedoelt dat het een open standaard gaat worden.

maar dit staat een bredere uitrol nog steeds niet in de weg.

Jawel, want de AMD GCN-chips hebben maar een marktaandeel van ongeveer 14% (zie http://store.steampowered.com/hwsurvey/videocard/)
Dus zolang het alleen AMD is, zul je nooit brede ondersteuning krijgen van Mantle. Daar is AMD gewoon een te kleine speler voor.

[2green]

Van nieuwe android releaseses wordt pas maanden later de source vrijgegeven en toch worden die versies opensource genoemd.

Functie definities is programmeercode voor mij, dus wat mij beteft code. Maar ben het met je eens dat het onlogisch is mantle opensource te noemen. Een open specificatie o.i.d. zou beter passen. Mogelijk dat het te maken heeft met hun opensourcemlinix driver plannen.

Amd is reeds in overleg om catalyst opensource te maken. Niet volledig, maar grotendeels. Dit zodat catalyst en radeon grotendeels dezelfdencode kunnen delen. Staat ergens op phoronix o.a. en in wat mailinglists voor radeon. Op deze wijze kunnen ze het beste van twee werelden combineren, maar ze stuiten nog op behoorlijk wat weerstand qua benodigde kernel aanpassingen.

[Verwijderd]

Van nieuwe android releaseses wordt pas maanden later de source vrijgegeven en toch worden die versies opensource genoemd.

Android valt onder de Apache license: http://www.apache.org/licenses/LICENSE-2.0
Deze verplicht je niet om wijzigingen openbaar te maken, in tegenstelling tot bv de GPL.

Android is open source omdat er source is gereleased op een bepaald moment, onder een open source licentie.
Bij Mantle is er nog niets gereleased, dus kun je nog niet over open source spreken.

Functie definities is programmeercode voor mij, dus wat mij beteft code.

Eerder een specificatie. Programmacode is taal-specifiek, een functiedefinitie is dat niet (zo kun je bv OpenGL gebruiken vanuit verschillende talen. Voor C heb je weer andere headers nodig dan voor bv Delphi, en dus andere 'programmacode').

[2green]

Onafhankelijk van onder welke licentie android valt, zijn van nieuwe releases niet de broncode vrijgegeven terwijl wel over een opensource release gesproken wordt.

De laatste keer dat ik keek (lees: afgelopen week), was de opengl api gespecificeerd in c. Zie bijvoorbeeld glBindBuffer

[Verwijderd]

Onafhankelijk van onder welke licentie android valt, zijn van nieuwe releases niet de broncode vrijgegeven terwijl wel over een opensource release gesproken wordt.

Dat zou dan net zo fout zijn als de statements van Huddy hier.

De laatste keer dat ik keek (lees: afgelopen week), was de opengl api gespecificeerd in c. Zie bijvoorbeeld glBindBuffer

Blijkbaar snap je het verschil niet tussen een specificatie en een programmeertaal.
Je kunt best C gebruiken als 'pseudocode' om een specificatie van een functie te geven. Dat betekent nog niet dat die specificatie alleen in C zou kunnen.
Dus ik weet niet wat je hiermee nu wilt zeggen.
Neem bv deze Delphi-headers: http://files.delphigl.com/new/dglOpenGL.zip
Daarin vinden we: TglBindBuffer = procedure(target: GLenum; buffer: GLuint); {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}
Dat is toch precies equivalent met: void glBindBuffer( GLenum target, GLuint buffer);
Zelfde specificatie, andere notatie.

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

[2green]

blijkbaar begrijp jij het verschil niet.

[Verwijderd]

Ik wel: Ik zie duidelijk dat de specificatie van glBindBuffer ongeveer als volgt is:
De functie heeft een symbool genaamd 'glBindBuffer' in de library.
De functie heeft 2 parameters.
De eerste parameter is van type GLEnum, en geeft de target aan.
De tweede parameter is van type GLuint, en geeft de buffer aan.

Dat is de specificatie.
Dat kun je in C, Delphi, Nederlands, of honderden andere talen opschrijven, de specificatie blijft hetzelfde.

Vergelijk het met decimaal, hexadecimaal of binair:
Het getal 15 decimaal is hetzelfde als 0xF of 1111b.
Dat zijn 3 verschillende representaties voor één en hetzelfde getal.

Een getal, of een specificatie, is een abstract begrip.

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

[2green]

*zucht*

Edit:
je gaat toch niet uitleggen hoe een tal-stelsel of een api werkt? Iedereen gelooft gelijk dat je dat weet, dat is een van het eerste dat je leert als informaticus.

Delphi is trouwens geen taal, maar de ontwikkelomgeving voor de taal Object Pascal.

Ik heb geen zin meer in deze onzin.

[Reactie gewijzigd door 2green op 23 juli 2024 19:18]

[Verwijderd]

je gaat toch niet uitleggen hoe een tal-stelsel of een api werkt? Iedereen gelooft gelijk dat je dat weet, dat is een van het eerste dat je leert als informaticus.

Jij wist dat blijkbaar niet, want toen ik dat zei, ging jij ertegenin, en een voorbeeld geven dat OpenGL in C gespecificeerd is...
Blijkbaar moest ik dat dus aan jou uitleggen (en koelpasta deed hetzelfde, dus de kans dat ik je verkeerd begrepen heb is niet zo groot).

Ik heb geen zin meer in deze onzin.

Ja, je fouten toegeven is niet zo makkelijk he.
Als je er niet zo op was doorgegaan, maar gewoon meteen je fout had toegegeven, dan was het nu ook niet zo'n enorme afgang voor je geworden.

[koelpasta]

"Functie definities is programmeercode voor mij, "

En toch kun je een hele set van interfacedefinities maken zonder dat je code hebt geschreven.

"Een open specificatie o.i.d. zou beter passen. "

Juist.

[2green]

Je zou het inderdaad kunnen zonder een specifieke taal te gebruiken, maar in het geval waar we het nu over hebben en de meeste andere gevallen ismdat niet zo.

Ik kan ook een programma beschrijven zonder een werkelijke taal te gebruiken.

[koelpasta]

"Amd is reeds in overleg om catalyst opensource te maken. Niet volledig, maar grotendeels. Dit zodat catalyst en radeon grotendeels dezelfdencode kunnen delen. "

Volgens mij ben jij of je bron ernstig in de war.
Radeon is een commerciele naam van een serie amd kaarten. Catalyst is de naam van het amd softwarepaket waar ook de drivers bij zitten.

[koelpasta]

"Jawel, want de AMD GCN-chips hebben maar een marktaandeel van ongeveer 14% (zie http://store.steampowered.com/hwsurvey/videocard/)"

AMD heeft volgens mij nog steeds een grotere aandeel van verkochte gpu's voor pc dan nvidia. Intel doet niet echt mee in het gaming segment dus je kunt rustig stellen dat voor gaming verder alleen nvidia er toe doet. En die heben dus een kleiner marktaandeel.
Wat dat betreft zullen er, als de oude amd chips uit de markt zijn verdwenen, dus vooral gcn chips in de pc's van gemiddelde 'high end' gamers zitten.

Ik denk dat jij de positie van amd in de pc gamingmarkt structureel onderschat, hoor.

[Reactie gewijzigd door koelpasta op 23 juli 2024 19:18]

[Verwijderd]

AMD heeft volgens mij nog steeds een grotere aandeel van verkochte gpu's voor pc dan nvidia.

Kijk dan nog maar eens goed: http://store.steampowered.com/hwsurvey
nVidia heeft 52.43%, Intel heeft 16.48%, AMD heeft 30.76%.

En die heben dus een kleiner marktaandeel.

Nee, veel groter, ten minste, binnen de markt waar het hier om gaat: gaming PCs.
AMD heeft net als Intel meer marktaandeel als je ook de APUs meerekent (want dan ook weer een vertekend beeld is, want nVidia heeft dan weer de Tegra's, maar die vallen niet onder de PC-markt)... Maar de meeste APUs zijn niet eens op GCN gebaseerd... en verder is dat niet de markt voor games, dus ook niet voor Mantle.

Het ging in Q1 voor alle drie niet zo heel flitsend, maar AMD holde bijna 2 keer zo hard achteruit als nVidia: http://jonpeddie.com/pres...phics-market-share-in-q1/

Wat dat betreft zullen er, als de oude amd chips uit de markt zijn verdwenen, dus vooral gcn chips in de pc's van gemiddelde 'high end' gamers zitten.

Ik denk dat jij de positie van amd in de pc gamingmarkt structureel onderschat, hoor.

Nee, jij overschat het, en zelfs als ik een link naar statistieken geef, negeer je die.
AMD is gewoon een veel kleinere speler dan nVidia, punt.

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

[koelpasta]

"Kijk dan nog maar eens goed: http://store.steampowered.com/hwsurvey
nVidia heeft 52.43%, Intel heeft 16.48%, AMD heeft 30.76%."

Grappig. Dat betekent dus dat amd gpu's minder vaak voor gamen worden gebruikt.
Zoals je hier ziet verkoopt amd dus wel meer gpu's dan nvidia.

"Nee, jij overschat het, en zelfs als ik een link naar statistieken geef, negeer je die."

Je gaf een link naar een pagina met uitgespecificeerde cijfers voor losse gpu's. Ik had dan zelf wel het overzicht gevonden die je hier ook linkt maar mn browser renderde de javascript niet en ik keek er overheen. Toen op zoek gegaan naar algemene cijfers en kwam ook uit bij die john peddie reports.

Magoed, amd is dus ook niet de 14% die jij in je vorige post opschreef.

Hoe dan ook, als straks alle amd chips gcn zijn dan is zo'n 37% van de gamesmarkt geschikt voor mantle. Dat is nog best een grote markt.

[Verwijderd]

Grappig. Dat betekent dus dat amd gpu's minder vaak voor gamen worden gebruikt.
Zoals je hier ziet verkoopt amd dus wel meer gpu's dan nvidia.

Ja, *iets* meer, alleen is in het geval van nVidia alles discreet, waar AMD een hoop GPUs verkoopt omdat die nou eenmaal deel uitmaken van de APUs (en die worden inderdaad niet zo vaak voor games gebruikt).

Hoewel, ik denk dat nVidia wel meer GPUs verkoopt, want dit is alleen de PC-markt, en nVidia verkoopt dus ook nog de Tegra's, zoals ik al zei. AMD heeft geen mobiele chips.

Magoed, amd is dus ook niet de 14% die jij in je vorige post opschreef.

Dat ging om GCN-kaarten, wel even goed lezen:

Jawel, want de AMD GCN-chips hebben maar een marktaandeel van ongeveer 14%

AMD heeft dus 30.76% van alle GPUs onder de Steam-gebruikers, maar slechts een deel ervan is uitgerust met een GCN-GPU, en dus Mantle-compatible. Als je de percentages optelt, kom je dus op ongeveer 14% qua GCN. De rest zijn oudere GPUs.

Hoe dan ook, als straks alle amd chips gcn zijn dan is zo'n 37% van de gamesmarkt geschikt voor mantle. Dat is nog best een grote markt.

Ik neem aan dat je 30.76% bedoelt. Da's alweer een stuk minder.
Daarnaast is de huidige trend dus dat de verkopen van AMD bijna twee keer zo hard teruglopen als die van nVidia.
Als die trend zich doorzet, dan is het marktaandeel van AMD dus een stuk kleiner dan 30% tegen de tijd dat alles GCN is.

Bijkomend probleem is dus dat *alle* nVidia DX11 GPUs geschikt zijn voor DX12. Dat zijn er dus nu al veel meer dan alle AMD-GPUs bij elkaar. Tegen de tijd dat alle AMD-GPUs GCN/Mantle ondersteunen, is Mantle dus niet meer relevant, want dan is DX12 waar het om draait.

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

[Countess]

omdat mantle ook nog niet af is. alle huidige games gemaakt met mantle zijn test cases for AMD om de API verder op te poetsen. wanneer dat gebeurt is word de API vrijgegeven (eind 2014) en heb ik er geen reden om aan te twijfel dat de tools dat dan ook worden.

standaarden releasesen voor ze klaar zijn geeft alleen maar meer problemen op te lange termijn. nu ff minder, maar straks alleen maar beter.

[Verwijderd]

Dan moet Richard Huddy zeggen: "We zijn van plan om het open source te maken zodra het klaar is". Hij zegt dat Mantle open source *is*, en dat is gewoon een leugen, want normale developers hebben geen toegang, dus is het niet open.

[Countess]

beetje muggenziften hoor.

het is NOG niet open.

[Reactie gewijzigd door Countess op 23 juli 2024 19:18]

[Nha]

Waarom is het dan AMD Mantle en niet DICE Mantle? En DICE had het al veels te druk met BF4 te verneuken om nog zo'n complexe en volledige API uit de grond te stampen. Ze zullen wel een serieuze bijdrage gedaan hebben maar hebben het zeker niet zelf moeten maken. Simpelweg geen tijd.

[Gropah]

Het is open in de zin van, alle gpu fabrikanten mogen hun eigen implementatie voor hun divers ontwikkelen, zolang ze maar hetzelfde doen. Nvidia zou dus een mantle implementatie kunnen schrijven waardoor het dus ook op nvidia kaarten zou werken, maar dit doen ze tot op heden helaas niet

[Blokker_1999]

Waarom helaas? Mantle is op dit moment nog geen succes te noemen en de techniek is specifiek ontwikkeld met de GPUs van AMD in het achterhoofd, of nVidia en Intel er zomaar mee aan de slag kunnen met hun architectuur is dus ook twijfelachtig.

[Gropah]

Het is een lowlevel API, iets wat developers meer kracht ter beschikking geeft. Dit is niet altijd nodig, maar met games kan het erg helpen. Bij de review van tweakers kwam al naar boven dat het veel voordeel kan hebben qua performance. Hetgeen wat het massale gebruik van Mantle echter in de weg staat, is het feit dat maar een deel van de gamers het kan gebruiken. Als Nvidia Mantle zou implementeren kun je denk ik veel meer games verwachten met Mantle, omdat het gros van de gamers er dan toegang tot heeft. Dit kan leiden tot betere performance van games.

Het is niet perse bedacht met AMD in het achterhoofd, maar omdat AMD het heeft ontwikkeld heeft het wel een headstart met het implementeren van Mantle.

[MoonWatcher]

In de praktijk zal het schrijven naar mantle sowieso alleen maar voor engine schrijvers weggelegd zijn. Anderen willen niet zo lowlevel schrijven maar gebruiken liever een engine.

En engines moeten vaak weer meerdere implementaties ondersteunen. ( nu dus directx, opengl en mantle )

Persoonlijk zie ik niet zo graag dat ontwikkelaars hun resources oneindig fragmenteren in het ondersteunen van een steeds verder groeiend aantal graphische implementaties.

Het kost ontwikkelaars al voldoende moeite om fatsoenlijke opengl drivers te schrijven. Laat staan om daar nog een derde render framework bij te gaan ondersteunen.

[Gropah]

Op het moment dat Nvidia Mantle gaat ondersteunen en het draait op zowel linux als windows (en uiteindelijk waarschijnlijk dan ook mac) dan zie ik het juist gebruikt worden voor alle platformen. Nu moeten games (om naar mac en linux te komen) vaak worden omgezet van DirectX naar OpenGL. Als Mantle goed wordt ondersteund kan er dus meteen in mantle gewerkt worden, waardoor er juist geen omzetting meer nodig is en hoeft er dus ook geen OpenGL of DirectX gebruikt meer te worden

[db87]

Mantle is nog volop in ontwikkeling, er komt een release versie die publiek beschikbaar is en elke (game)developer vrijstaat om te implementeren. De broncode is dan ook volledig beschikbaar. Maar Nvidia kan al veel eerder inzicht krijgen als ze daar het initiatief in nemen, dat hebben ze tot de dag van vandaag nog niet gedaan.

[Luuk.vanRiel]

Als Adobe nu ook al zijn software optimaliseert voor Linux stap ik zo over. Linux is in alle aspecten superieur aan Windows alleen blijft gamesupport en ondersteuning voor professionele toepassing ver achter.

[Verwijderd]

Hoewel ik zelf Linux gebruik (OpenSuse) vind ik je statement dat Linux stukken vlotter is dan Windows wel wat uit de lucht gegrepen. Ik vind het dan ook wat raar dat niemand, ook Microsoft haar fanboys niet, je hier op aanspreekt.

Linux distros kunnen heel vaak heel goed meekomen zo niet beter werken dan Windows in al haar vormen. Zeker op Servers staat Linux distros als Debian als een huis. Maar om nu te zeggen dat alles veel vlotter loopt in Linux (met nadruk op jouw "stukken vlotter", wat aangeeft dat het veel vlotter loopt in games). Ik kan alleen weinig Benchmarks vinden waar Linux Distros echt beduidend sneller zijn dan Windows installaties die door een gamer goed geïnstalleerd zijn. Soms een paar frames, maar het loopt niet op tot een verschil Xbox One vs PS4 (30frames vs 60 frames zeg maar)... dus waar heb jij dat soort cijfers vandaan?

[Talyan]

Dan moet er nog wel het één en ander gebeuren, ben al 3 dagen bezig een xbox controller werkend te krijgen.

[Blokker_1999]

[...]
Koop je al vast maar een goede virusscanner want er zullen veel meer en gevaarlijkere virussen zijn voor Linux dan voor Windows aangezien de broncode gewoon ingekeken kan worden.

Tuurlijk, en varkens kunnen vliegen en ik ben miljardair.

Linux is vandaag al het meest gebruikte OS ter wereld (ok, niet helemaal correct aangezien de userland tools sterk kunnen verschillen). Denk maar aan servers, smartphones, routers, ... . Als het open source karakter echt voor zoveel meer malware zou zorgen dan hadden we dat al lang gemerkt.

[Fredi]

Waarom heeft Windows dan 90% van de desktopmarkt in handen?

[Bonez0r]

Een beetje concurrentie voor DirectX is nooit verkeerd. Bovendien, als het meer fps oplevert is dat alleen maar beter.

[Tijger]

Uh, hoe zie jij DirectX draaien op Linux?

[acemoo]

Niet, maar Mantle draait wel op Windows. Dus daarom is er toch concurrentie.

[Tijger]

Maar dat is geen concurrentie voor DirectX of OpenGL, dat is concurrentie tussen AMD en Nvidia.

[acemoo]

Hoe is Mantle geen concurrentie voor DirectX of OpenGL?
Is toch gewoon weer een API waar je uit kunt kiezen?
Ik zie dit niet zo zeer als concurrentie tussen AMD en Nvidia, meer als iets dat AMD heeft bedacht omdat ze niet tevreden waren over OpenGL en DirectX. Nvidia kan het ook gewoon gaan ondersteunen.

[Probook8979]

Hier ben ik zelf ook erg geintreseerd naar.

Zo zal AMD hoge aandelen krijgen.

[dakka]

bam, dat was gelijk mijn eerste gedachte

[Jeroentjeeuh]

BAM opeens heeft AMD een goed alternatief achter de hand !!

[blouweKip]

De performanceverschillen tussen mantle en opengl waren toch nauwelijks aanwezig? Hoewel ik het een goed teken vind dat mantle nu dus multiplatform gaat (weer een pluspunt tov direct3d) lijkt het me nog wel een hele weg te gaan hebben aangezien AMD/ATI nu niet bepaald bekend staat om goede linux support (en het verschil tussen opengl en mantle kwa performance een stuk kleiner is dan bij direct3d).

[Gamebuster]

OpenGL is alleen een hel om mee te werken.

[blouweKip]

Het zou zeker fijn zijn een open multiplatform game api te hebben, op dit moment is dat opengl en de vraag is of mantle wat dat betreft beter is,de performancewinst is in ieder geval met name te halen t.ov. direct3d11 en niet t.o.v opengl, het enige nadeel van opengl (of voordeel,het is maar van welke kant je het bekijkt) is de wirwar van extensies.

Overigens juich ik deze stap van AMD/ATI wel toe als dat betekend dat hun linux support nu ook eens wat meer aandacht gaat krijgen, nu zit ik vast aan nvidia hardware omdat ATI's ondersteuning gewoonweg signficant minder goed is.

[Reactie gewijzigd door blouweKip op 23 juli 2024 19:18]

[Verwijderd]

het enige nadeel van opengl (of voordeel,het is maar van welke kant je het bekijkt) is de wirwar van extensies.

Ook het gebrek aan ondersteuning voor multithreading en de inconsistentie van implementaties/drivers onderling zijn nadelen van OpenGL.

[dmantione]

Hoe kom je daarbij? Ik programmeer er regelmatig in... heel fijne API.

[Gamebuster]

Als je weet hoe het werkt misschien. Als je informatie erover opzoekt, heb je 1000 manieren om dezelfde driehoek te tekenen. De ene keer heb je die direct mode, de andere keer moet je shaders ertussen hangen, enz.

[markieo]

Zou het nu ook mogelijk worden om bf4 te porten naar Linux?
Omdat BF4 ook gebruik kan maken van Mantle.

[stolkchris]

Misschien. Ik denk dat de drempel voor het maken van een port zeker verlaagd maar buiten Mantle zijn natuurlijk andere api's nodig die bijvoorbeeld het geluid aansturen, de input, networking enz.

[Amanoo]

In principe wordt het op zijn minst makkelijker, net zoals de het porten van een OpenGL game naar Linux makkelijker is dan een DirectX only game. Maar er is natuurlijk kans dat Battlefield 4 geschreven is met dingen als C# of .NET, en dat is weer Windows spul. Dan is er nog de vraag of een Mantle only versie van het spel gaat werken op Nvidia (donders eigenwijs bedrijf dat ik in staat acht om de meest open API's nog te negeren, al heb ik betere driver ervaringen bij hen dan bij AMD), en zit je dan nog met een bedrijf als EA, dat al helemaal kampioen is in negeren (en in afraffelen) en waar je al van groot geluk en bijna wonderen mag spreken als je van een game een OSX port ziet. Ik acht EA in staat een spel zo te schrijven dat het zonder moeite op elk platform draait, en het dan alsnog enkel voor Windows te compileren.

Volgens mijn wishful thinking gaat Nvidia nu Mantle implementeren in al zijn drivers, zodat het ook wil werken voor Nvidia gebruikers, ongeacht OS, en besluit EA dat SteamOS toch een goed idee is, maar mijn realisme acht die kans enorm klein.

[Verwijderd]

Ik hoop echt dat veel developers afstappen van dat C# en .NET framework technologie wat enkel als doel heeft: Monopolie!!!
Nu heb je wel het MONO project om dit crossplatform te maken. Maar dat kwam echt niet vanuit Microsoft. Die willen dat eigenlijk helemaal niet.

Wanneer denkt elke developer niet gelijk na bij het programmeren van een stukje software: Crossplatform. Altijd maar in hun eigen straatje denken van: ik ben geïndoctrineerd op school met C# dus kan ik niks anders.

[NTAuthority]

Waarom ondersteunt Microsoft dan wel Mono voor verschillende open-source onderdelen van het moderne .NET Framework?

[misterbennie]

Als ik het goed begrepen heb heeft Microsoft de CLI in 2000 al als open standaard gepubliceerd en ondersteunt MONO sinds de release in 2004 C# waarbij Microsoft ook ondersteuning in de ontwikkeling verleent (bron), (bron) (download voor platformen), etc.

Tegenwoordig draait MONO op zo ongeveer elk OS, inclusief OSX, iOS, Android, NetBSD, Linux. Dus allemaal redelijk cross platform, inclusief Raspberry Pi, Beaglebone, Netduino ( .NET Micro Framework), etc.

Dus persoonlijk hoop ik dat er nog veel meer ontwikkelaars .NET en C# gaan gebruiken en het een nog belangrijker ontwikkelplatform wordt.

Want C# en .NET (MONO) denken, is Cross platform denken.
En met Xamarin kun je ook prima voor mobiel ontwikkelen (iOS, Android, windows phone) en alleen de UI voor een specifiek platform maken, terwijl de rest generieke code kan zijn.

[Reactie gewijzigd door misterbennie op 23 juli 2024 19:18]

[ClementL]

De Sims 3 maakt ook gebruik van C#, en is met Mono op Mac gereleased.

[Feanathiel]

Uit interesse: zover ik weet alleen de launcher, of ook nog meer tegenwoordig?

[ClementL]

Gezien dit mogelijk is kun je er van uit gaan dat het ook voor het spel zelf gebruikt wordt.

[Verwijderd]

"bf4 te porten naar Linux"

Niet eens over beginnen. Hoe willen ze BF4 porten als ze de bugs en glitches niet eens hebben kunnen fixen?

[graverobber2]

Die porten ze toch gewoon lekker mee

En exclusief in de linux versie krijg je een paar extra bugs

[Reactie gewijzigd door graverobber2 op 23 juli 2024 19:18]

[Verwijderd]

Those aren't bugs!
Those are "features"!

[Verwijderd]

De enige reden zal de Steambox zijn van Valve. Want wie gaat er nu zoveel energie en tijd steken in het poorten van Mantle naar Linux als nog geen 2% van de desktops is uitgerust met Linux. Daarvan zal slechts weer een klein gedeelte interesse hebben in gaming.

[HashIT]

Voor zover ik zie, wordt Mantle ook op de APU's ondersteund die bedoeld zijn voor tablets en servers. Met name tablets zullen toch vaak op een Linux gebasseerd OS draaien en ook voor servers (renderfarms?) zien ze misschien mogelijkheden.

De desktopmarkt is dus niet het enige waar ze deze investering voor hoeven te doen.

[dmantione]

Windows werd pas populair op de desktop toen spellen Windows gingen eisen. Op het moment dat spellen Linux eisen, zal je die 2% rap toe zien nemen. En dat is niet dagdromen: Momenteel worden spellen Windows naar Linux geporteerd, maar als die Steambox een beetje een succes wordt ga je het omgekeerd krijgen. En dan ga je programmeurs horen vloeken voor allerlei zaken die onder Linux een fluitje van een cent zijn en onder Windows een drama.

[CAPSLOCK2000]

Ik denk dat je gelijk hebt hoor maar het zou ook gericht kunnen zijn op renderfarms. Dat is een lucratieve markt die grotendeels op Linux draait.

[HollowGamer]

Mooi dat AMD Mantle nu naar Linux brengt, alleen jammer dat het f (volledig) bedrijf het zelf nog niet heeft bevestigd.

Misschien brengt dit goed nieuws voor Linux gebruikers; AMD gaat Linux meer en meer serieus nemen. Ik persoonlijk denk dat AMD simpelweg niet de mensen (en dus het geld) heeft om net als de concurrente zich meer met Linux bezig te houden.

Ontopic: Toch zou ik graag een open-source alternatief willen zien op Linux. Iets wat door elke GPU en ontwikkelaar kan worden toegepast, zonder dat er voor elk fabrikant weer een aparte implementatie ontstaat. Of de API's moeten van elk zo goed zijn, dat ze grotendeels naast elkaar toepasbaar zijn.

[Simyager]

Toch zou ik graag een open-source alternatief willen zien op Linux. Iets wat door elke GPU en ontwikkelaar kan worden toegepast, zonder dat er voor elk fabrikant weer een aparte implementatie ontstaat. Of de API's moeten van elk zo goed zijn, dat ze grotendeels naast elkaar toepasbaar zijn.

Uhm die bestaat al en heet OpenGL?

[HollowGamer]

Nee, dit is helaas niet hetzelfde. OpenGL is een DirectX alternatief m.a.w. er zit nog een laag (meer) tussen.

De snelheid winst bij deze implementaties (van AMD en nVidia), zit hem juist dat je zo dicht mogelijk op de 'kaart' zit i.p.v. een 'stuur' laag er bovenop.

[CyBeR]

Dat kan niet, behalve door die kaarten identiek te maken. OpenGL is de standaardmanier voor applicaties die middels de implementatie in de driver van de fabrikant de hardware zelf aanstuurt. Dat kun je prima zelf doen maar dan moet je dus voor elke kaart apart je software schrijven.

[Verwijderd]

OpenGL is een open standaard, niet open source.
Er bestaat wel een open source implementatie, die MesaGL heet. Maar veel OpenGL-implementaties zijn closed-source.
Afgezien daarvan heb je wel gelijk: Elke fabrikant kan OpenGL implementeren.