Microsoft kondigt DirectX Raytracing voor realtime raytracing aan

Microsoft heeft de DirectX Raytracing aan de DirectX 12-api toegevoegd. Volgens de fabrikant maakt de techniek de weg vrij voor games die deels via realtime raytracing en deels via het traditionele rasterization zijn opgebouwd.

DXR zal in eerste instantie bij games gebruikt worden als aanvulling op bestaande renderingtechnieken zoals screen space reflections, verwacht Microsoft, waarbij de weergave van deze effecten er flink op vooruit zou gaan. Rasterization is een efficiënte en beproefde renderingtechniek, aldus het bedrijf, dat via slimme technieken toch schaduwen, reflecties en belichting kan tonen. Toch zijn er grenzen aan het realisme dat de techniek kan bieden, waar raytracing in beeld komt, met zijn simulatie van de interactie van licht met objecten in een virtuele wereld. Raytracing kan straks realtime omdat gpu's er krachtig genoeg voor worden, is de verwachting. Op termijn kan DXR zo rasterization compleet vervangen als algoritme voor het renderen van 3d-scenes.

DirectX Raytracing voegt globaal vier concepten toe aan DirectX 12. De eerste is een acceleration structure, oftewel een object dat de 3d-omgeving representeert en die als eerste stap bij het renderen van content gemaakt moet worden. Daarnaast zijn er de raytracing pipeline state, de DispatchRays-startpunten voor het tracen van de rays en nieuwe shadertypes als ray-generation, closest-hit, any-hit en miss. De werklast van DXR kan met de bestaande Graphics- en Compute-engines van DirectX 12 afgehandeld worden.

Microsofts PIX-debuggingtool ondersteunt DXR zodra de functionaliteit beschikbaar komt. Daarnaast maakt Microsoft bekend dat game-engines als Frostbite, SEED, de Unreal Engine 4 en de Unity Engine DXR gaan ondersteunen, evenals 3DMark. Microsoft claimt al bijna een jaar te werken aan de uitbreiding van DirectX 12, samen met ontwikkelaars en hardwarefabrikanten. Met huidige hardware kunnen ontwikkelaars aan de slag met DirectX Raytracing, claimt Microsoft, zonder details te noemen.

Eerder op maandag kondigde Nvidia aan dat zijn eigen RTX-techniek samen gaat werken met DXR en zo realtime raytracing op Volta-gpu's mogelijk maakt. AMD laat in een verklaring weten ook met Microsoft samengewerkt te hebben aan de techniek, maar kondigt nog geen hardwarematige ondersteuning aan.

Reacties (71)

[Davidoff1976]

Dat geeft een stuk betere kwaliteit! Dat zie je ook terug bij 'Shadow map' en 'Raytraced shadows' in 3dsmax als voorbeeld. Waarbij Raytraced shadows veel scherper zijn (handig voor translente materialen) al is shadow map daarentegen in te stellen op zachtere schaduwen.

Bij raytraced shadows hoeft er ook geen resolutie meer gekozen te worden (shadow map res) zodat de boel wat sneller gaat. (m.b.t. op geheugen gebruik)

[Reactie gewijzigd door Davidoff1976 op 23 juli 2024 08:22]

[Zoijar]

Niet helemaal waar dat je geen "resolutie" hoeft te kiezen: het grote probleem bij raytracing is aliasing, dus hoeveel rays je schiet en hoe je die combineert. Verder krijg je bij goed tracen een explosie van rays als elke reflectie/bounce resulteert in een aantal nieuwe rays (licht breekt en gaat niet een kant op na reflectie) Dus ook daar moet je instellen hoeveel bounces en secondary rays je kan doen.

[Davidoff1976]

Schaduw resolutie hoef je in ieder geval niet meer te kiezen. En dat is wat ik bedoel...

[SG]

Nou nee je moet ten eerste een omgeving hebben met gladde reflecterende oppervlakten waar je duidelijk reflexies artefacten ziet. Een Doom met Chrome balles is dus onzin.
Een race games met Spiegels of reflexes in de lak is nice. Of gebouw met de nodige spiegels en ramen.
Heel veel games hebben door gebrek aan spiegel materialen niet een daaraan.
Als ik game ben ik lig niet bezig met of iets correct is en echt subtiel is dus meten weten issue is.
Ben dan druk met gamen.

Dus voor sommige omgevingen en objecten goed bruikbaar maar voor games met weinig van die materialen is zonde van productie resources.

[Davidoff1976]

De game wereld streeft juist naar realisme en scherpe details (die zeker opvallen in hoge resoluties) dus ben het niet mee eens met 'Druk met gamen' waar ik wel mee eens ben is dat ze concessies moeten doen in realisme en snelheid.

[Verwijderd]

De mensen van de Unreal game engine komen a.s. woensdag met meer informatie over dit real-time Ray-Tracing DXR.
https://www.unrealengine....raytracing-and-nvidia-rtx

Nvidia zegt dat het waarschijnlijk een hybride word van Rasterization voor standaard zaken en Ray-Tracing voor reflecties en schaduwen.

DirectX 12 zorgt er al voor ontlasting van je CPU en kan meer Draw Calls genereren voor de GPU, want met de sprongen in GPU performance wordt de CPU de Bottleneck.
Tevens is er met DX12 mogelijk zowel een AMD als Nvidia card beide in je pc te hebben. (Best of Both worlds?)

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:22]

[Davidoff1976]

Ben overigens net bezig met de unreal engine, en nog niet alles door genomen!

Maar ondersteund de engine nou ook gewone Ray traced shadows of alleen Ray Traced Soft Shadows? En is het dan ook wel echt 100% ray traced?

Snap dat nog even niet zo goed al kan ik het makkelijk opzoeken

Heb voor de geïnteresseerden een foto link bij geplaatst wat de verschillen zijn!

https://www.imgtec.com/wp.../2017/02/comparisonV8.png

[SG]

Ja nV en AMD mixen is leuk. Maar dat is ook meteen de meest geavanceerde form van soort van SLI Crossfire vervanging wat dus enorme load op game studio render team zet. Dus dit wordt heel zelden gedaan. Op team na die wel de hardware wilt pushen en zich met zulke features wil onderscheiden van de rest van de markt. Voor een heel klein sub deel van target markt. Dus commercieel niet interresant voor de meeste devs.

[Origin64]

Het telt ook mee dat het met raytracing minder werk is om weerspiegelingen te maken als je de physics basis goed hebt. En de performance impact van een spiegeling is veel lager, dus als je genoeg spiegels neerzet zal het uiteindelijk efficienter werken dan de conventionele render technieken.

[Dorstlesser]

Nou nee je moet ten eerste een omgeving hebben met gladde reflecterende oppervlakten waar je duidelijk reflexies artefacten ziet.

Hoe kom je daarbij als ik vragen mag? De belichting op voorwerpen die niet glad en niet reflecterend zijn knapt er volgens mij nl. ook erg van op! Zag een tijd terug dit filmpje van de eerste Quake met raytracing; resolutie is het nog niet maar je ziet dat de belichting van schoten e.d. en ook schaduwen er mooier uit ziet, ook op de muren die niet bijzonder reflectief zijn.

[SG]

Hoe ik daar bij kom. Nou eenvoudig ik speel game. Bij de meeste corridor shooters ben je meer bezig met de opfor dan turen naar details. Dan zul je toch meer een game met de nadruk op sifhtseeing.
FPS shooter nee heeft voor mij geen grote meerwaarde.
In Sandbox shooter al stuk meer.
In adventure mogelijk nog meer.
Iets waar je de game exoerience tijd krijgt om focussen of shadows wel kloppen.

In game als OFP of ARMA tuur je in de verte om opfor vooral eerder te zien met de nadruk van dood is dood en je dus helemaal opnieuw moet starten.
In CoD waar je hectisch op opfor jaagd is ook niet zo veel meer waarde.

Misschien voor Star Citizen

[KopjeThee]

Ray tracing is al jaren of decennia een soort heilige graal. Het geeft onmiskennaar het meest natuurlijke resultaat, maar tegen hele hoge reken kosten. Dat we nu langzaam richting real time ray tracing gaan, biedt mooie kansen. Ik ben benieuwd naar de verdere ontwikkelingen.

[Verwijderd]

Hoe moet ik dit lezen? Alleen real time raytracing voor de schaduwen of ook de belichting? Dat laatste zou stiekem best ziek zijn kijkend naar de hoeveelheid data maar t zal een enorme stap richting fotorealistisch zijn.

[Wolfos]

Het gaat over het gehele renderproces, dus een volledige vervanging van de rasterizer door een raytracer. De video in het artikel laat zien wat voor mogelijkheden dit bied.

[ErikRo]

Raytraced plaatjes zien er vaak zo vreemd en kunstmatig uit, benieuwd of dat gaat werken in games quake in raytracing gezien was knap gedaan maar niet mooi imho.

[verleemen]

Juist ja, in den tijde van de amiga deden reflections animator en Imagine er een dik uit over om een vrij simpele geraytracede afbeelding van 352x288 te maken. Dan was je wel blij met scanline die daar maar tien minuten per frame over deed. Ik weet nog dat ik voor een videoproject voor de bandstad Hengelo- Enschede een animatie van 90 frames liet renderen, dat duurde in scanline 3 en een halve dag, en toen bleek ik bepaalde settings toch niet helemaaal...


En toen moest t dus over,
En al die tijd kon je dus niks verder met je computer doen, Jaa officieel kan ie multitasken maar niet als je processor under full load staat natuurlijk. En wat je al helemaal niet wil is dat ie na anderhalve dag plotseling stopt want ja, t waren 4096 kleurenbeelden, dat wordt te veel data als je dat als losse BMP’s op slaat dus dat werd gelijk in iff anim formaat opgeslagen.

Ja dat waren nog eens tijden ik mis de gezelligheid, en de magie, aar dat andere, ben blij dat dat voorbij is:)

[Kubrix]

Mooie tech voor Valve om HL3 mee te maken

[henk717]

Gezien valve een van de grote spelers achter Vulkan is verwacht ik dat ze hun eigen API gebruiken zeker omdat valve aan cross platform releases doet. Als je met Vulkan in een release Windows, Linux en uiteindelijk Mac kan ondersteunen zie ik behalve Xbox development geen reden om DX12 te gaan gebruiken voor de Windows release.

[rjberg]

Ik had altijd begrepen dat raytracing ouder is dan rasterization.

Voor dat laatste is namelijk een z-buffer nodig, iets wat vroeger te veel geheugen kostte.

[Mic2000]

En over tien jaar in onze telefoons

[Wolfos]

Eerder twee jaar geleden
https://www.imgtec.com/legacy-gpu-cores/ray-tracing/

[catfish]

Vulcan of DX12, beide zijn gewoon "een" standaard.
Er is geen enkele reden waarom DX12 niet zou kunnen op Linux (behalve dat ik MS dit voorlopig nog niet zie doen).

[Enchantress]

DX 12 is van MS en Windows is van MS.
Bv Linux is niet van MS dus dat gaan ze nooit doen.

[sfranken]

Dat werd van .NET ook gezegd, maar zie hier nieuws: Microsoft brengt .Net naar Linux en OS X en maakt .Net Server Core op...

[Overv]

De reden daarvoor is dat Linux verreweg het dominante platform is voor serverapplicaties. Bij PC gaming is het omgekeerde waar, dus is er voor Microsoft weinig reden om hun diensten/technologie op Linux aan te bieden.

[GekkePrutser]

Plus dat er al een third-party .NET CLR was: Mono. Die behoorlijk veel gebruikt wordt.

Met een eigen CLR heb je de support beter in handen dus ik kan het van Microsoft wel begrijpen.

[latka]

Maak me maar weer wakker als .Net core gelijk loopt met .Net op Windows. De core API is een leuk begin maar je hebt er niets aan voor complete cross-platform development.

[sfranken]

Je mist het punt. Het punt is dat nota bene Microsoft Linux releases doet. Ik kan me nog een Steve Ballmer herinneren die het volgende te melden had over Linux:

Linux is not in the public domain. Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That's the way that the license works.

Nu, met een andere wind door het bedrijf, doen ze 'opeens' dit.. Dáár ging het om.

[StefanDingenout]

die nieuwe wind waait er al een tijdje hoor, vooral bij de web teams.

[latka]

Die uitspraak was toen al marketing speak en gericht op de gpl. Punt is dat alles wat tot op heden cross platform is van ms de plank misslaat: Silverlight op Linux via mono? Troep. SQL server op Linux: ja een beetje maar doe maar niet. Het is precies genoeg om de checkboxes bij inkopers te vullen maar meer dan dat ook niet. De nieuwe wind bij ms ruikt als de oude.

[bush]

wat een onzin, we gaan toch niet meer over silverlight praten? zelfs op windows is het dood. SQL Server op Linux is een prima product maar nog niet fully featured, ze hebben verder behoorlijk wat linux op Azure. bvb hun AKS service of linux docker containers op App Service

[latka]

Mijn punt. Investeren in .net core is een risico door het track record van ms.

[Crysania]

hoezo is silverlight op linux nieuwe wind.. dat is echt al jaren dood (heel silverlight btw)

Je ziet een steeds sterkere nadruk op Azure consumptie bij Microsoft en het zal ze aan hun reet roesten of dat Windows of Linux bakken zijn die daar draaien.

.Net Core 2.0+ is gewoon prima en werkt goed op windows + linux en je ziet MS ook veel investeren in het containerized stuk met Kubernetes, docker containers etc

[latka]

Nieuwe wind sloeg op de opmerking dat MS tegenwoordig oh zo goed bezig is sinds steve balmer weg is. Mijn ervaring is dat investeren in MS technologie alleen handig is als duidelijk is in de boeken van MS dat ze er inmiddels quit op spelen. Als er verlies wordt geleden lijkt MS heel makkelijk de stekker er uit te trekken (logisch met aandeelhouders). Dit is een risico voor iedere nieuwe technologie die ze introduceren. Zo ook .Net core: als het niet binnen nu en een redelijke termijn duidelijk bijdraagt aan de de bottom line stoppen ze er mee.

[bush]

en hoe is dat anders dan bij andere bedrijven?

[latka]

Het verschil in snelheid van eruit trekken, het kabaal wat ze initieel maken over iets nieuws en hoe ze "oh zo strategisch erin geloven". Van alle bedrijven waar ik mee samengewerkt heb scoort MS op dit punt als zeer onbetrouwbaar.

[bush]

al eens de producten van google gevolgd?

[latka]

Daar staat groot beta bij en GWT ben ik met een boog omheen gegaan, dat straalde 'tijdelijke oplossing' uit. Dat is iets wat MS zou sieren: dit nieuwe gave platform zou wellicht de toekomst kunnen zijn ipv. allerlei verhalen ophangen bij influencers (lees: mensen die er niets van snappen maar wel beleid maken) om dan de keutel in te trekken (ja het zit diep, ben al redelijk wat geld kwijtgeraakt door dit soort gedraai van MS).

[StefanDingenout]

Het heet niet voor niks Core. Het hele idee is dat het nooit gelijk zal lopen met .Net op Windows, omdat het juist een platform onafhankelijk core moet zijn. Het is inderdaad nog wel maar een begin, maar ik zie het probleem daar niet van. Liever dat ze een begin releasen en iets met feedback van developers doen dan een monolith neerplanten waar het weer harstikke moeilijk is wijzigingen aan te brengen.

[Reactie gewijzigd door StefanDingenout op 23 juli 2024 08:22]

[Crysania]

Sinds 2.0 bevat het echt al veel van de APIs hoor.

Voor web applicaties / apis / mobile apps etc zou ik nu altijd .net Core kiezen. alleen als je diepe integratie wil met Windows OS zit je aan full framework vast. hoe vaak wil je dat nog?

[StefanDingenout]

inderdaad.

Nou ja, bij elke serieuze applicatie (niet losse tooltjes, maar iets als office of een grafisch pakket) heb ik liever een native applicatie.

[Davidoff1976]

Buiten dat om! Laten ze eerst maar eens de driver ondersteuning goed voor elkaar hebben. Zodra Dx12 naar Linux komt zal er wel heel veel bij komen kijken.

En buiten dat weer om zijn veel spellen afhankelijk van Windows in zekere zin. Kijk maar bijvoorbeeld naar randapparatuur.

Ik zie het niet gebeuren in ieder geval. Linux is gewoon geen game platform!

[Origin64]

DX9 draait nu beter op Linux in Wine dan onder Windows. Geef het een paar jaar de tijd.

[Tielenaar]

DX9 is meer dan 10 jaar oud, dus wat heeft dat voor zin?

[Origin64]

De 2 games die ik nu het meeste speel, csgo en sc2, draaien op dx9
En over een paar jaar kan Wine dus goede ondersteuning bieden voor dx10/11/12

[DanielsWrath]

Dus er is 1 reden waarom dit niet zou kunnen

[stewie]

Microsoft speelt catch-up met Vulkan qua ray-tracing want ze zijn al een tijdje bezig met een vulkan ray-tracing api die gestart werdt en voorgesteld word door Imagination "powerVR"


https://www.imgtec.com/bl...e-ray-tracing-revelation/

[Reactie gewijzigd door stewie op 23 juli 2024 08:22]

[StefanDingenout]

Dus? Waarom zou Microsoft perse de eerste moeten zijn? Vooral omdat er sowieso tot noch toe geen hardware ondersteuning voor ray tracing was. En nu tegelijk met de eerste kaart (van Nvidia) die dat wel heeft word deze API ook aangekondigd, dus je kunt moeilijk beweren dat ze te laat zijn.

[Verwijderd]

Dus ik zit nu gewoon naar een potje stratego van een paar tech. bedrijven te kijken?

[Alfa1970]

Nee, naar het welles nietes spelletje tussen de verschillende fan bases.
Die zullen het toch nooit eens kunnen worden. Dus trek je eigen plan en laat het welles nietes voor wat het is.

[StefanDingenout]

Dat dus.

@Verwijderd Ik kaart gewoon aan dat zeuren over wie eerst was met een api helemaal niet zo relevant is, aangezien tot nog toe geen van beiden gebruikt kon worden omdat de eerste kaart die dat gaat kunnen nog maar net aangekondigt is. Het duurt dus nog wel een paar maanden voor wat voor standaard dan ook er daadwerkelijk toe doet. En jaren voor het redelijk veel gebruikt word in grafische kaarten voor games.

Een welles nietes spelletje van dingen die gebruikt worden is tot daar aan toe. Dan kun je tenminste nog vergelijken hoe goed de api in de praktijk is. Maar gaan zeuren over wie eerst was met een api die sowieso nog niet eens gebruikt kan worden...

[Reactie gewijzigd door StefanDingenout op 23 juli 2024 08:22]

[Origin64]

Vulkan mag dan het cross platform voordeel hebben het nadeel is dat het een concurrerende API is die niet elke game zal ondersteunen.

Dus DX12 draait binnenkort elke game maar alleen op Windows en Vulkan draait niet elke game maar wel op elk OS

[henk717]

Dat heb je niet helemaal goed begrepen, het is aan de ontwikkelaar om zijn API's te kiezen. DX12 zal dus niet elke game kunnen draaien, integendeel want de meeste games zijn nog steeds voor DX11 en ouder en daarbij wordt een losse versie van DX aangesproken.

Maar ook in DirectX vs Vulkan gaat je betoog niet op kijk bijvoorbeeld daar Doom deze kan op OpenGL of Vulkan draaien, directx wordt niet ondersteund.

[Origin64]

Ik bedoelde nieuwe games. Dus games die in productie gingen nadat DX12 af was. Er zijn nu ook nog devs die voor DX11 kiezen maar dat zal uiteindelijk wel ophouden.

Dat er games uitkomen die alleen op min of meer open source apis draaien kan ik alleen maar toejuichen.

[henk717]

De grote engines zullen inderdaad steeds meer gebruik gaan maken van zowel DX12 als Vulkan, maar DX12 is een stuk moeilijker te gebruiken dan DX11 omdat het veel meer controle in handen geeft. Ik verwacht dat de kleinere studios met een eigen engine dan nog wel een poos DX11 aan zullen houden net als dat er nu nog steeds DX9 games uit komen vooral als het om een 2D spel gaat.

[SG]

Bij zeer kleine producties en "small scope" waarbij je gebruik maakt van eigen Engine is API een aanzienlijk deel van werk en cross plaform releases eerder na mekaar dan synchroon. Je test niet alleen API per platform maar de algehele Q&A plus platform specifieke beperkingen of unieke features.

Grote producties is large content team wat grootste deel van werk verzet waar Engine doch cruciaal maar kleiner sub team aan werkt waar de aPI abstractie eerder een implementatie detail is.

Voor klein 3 man team met productie tijd van jaar een enorme taak.
Bij triple a project met gedeelde Engine team waar 3 jaar aan gewerkt wordt een implementatie detail.
Wat ergens rekening mee gehouden wordt in de planning. Bij gedeelde Engine is dat gedeelte vaak al overgenomen en bij elke nieuwe project evolueert dat mee.

Dus de API wars is meer iets waar platform fans mee bezig zijn en meeste pro geen invloed ophebben omdat er van boven uit al beslist is.

Vanuit de game industrie is grote perspectief vanuit commercie en daar is Mian target belangrijk als daar Xbox platformen bij zitten is DX12 keuze voor W10 niet ver en sowieso ook optioneel target en elke kleinere markt steeds minder commercieel van belang.

Keuze is daar van Publisher gezien Consoles eerst die zijn elk groot
Windows > > MAC Linux zeer groot verschil
denk dat W7 dan belangrijker is en alleen als bij grote producties zij grote massa wil benaderen dan voldoet een DX11 ook.
En is Vulkan eerder optioneel.

Uiteraard is er na zooi sequels al Engine die verder ontwikkeld wordt en kan er soms de keuze komen om ipv DX11 vulkan te gebruiken en DX12 te laten vervallen Maar dat is als de studie en of Publisher W7 commercieel belangrijk vind.

Het verleden het heden en de toekomst is ge-licenceerde data duiven game Engine waar art team al vlug productief is en snellere time toe market. Eigen Engine is meer iets als je game concepten een unieke zeldzame feature nodig hebben waarin de licenceerbare Engine slecht of niet in voorzien.

Het grootste probleem is juist de productiviteit van art teams API juist niet.

[Neko Koneko]

DX12.....
Vulkan is een stuk beter, geen gezeik meer met andere platformen het kan gewoon overal op gedraaid worden. Denk ook dat dat juist de toekomst is.

DX12 = Windows only
Vulkan = cross-platform

Het is best vervelend dat Tweakers volzit met profeten die bij elk bericht over een niet open-source product meteen een totaal off-topic betoog gaan houden over waarom het product waar het nieuwsbericht over gaat erger is dan de reïncarnatie van Hitler en de duivel gecombineerd

[Umbrah]

Waar zie je hier AMD/nVidia genoemd worden? Dit gaat specifiek over een toevoeging aan DX12... een API, geen merk/GPU. De enige Volta GPU die we hebben is momenteel te Titan-V; en dat zal amper 0,1% van de install-base zijn. Voor mainstream zullen we nog een stap verder zijn, en voordat het écht goed presteert nog zeker nóg een stepping. Bovendien zullen de engines (UnrealTech/Frostbite hebben al aangekondigd...) óók nog catchup spelen, dus ga er vanuit dat je dit zeker 3 jaar nog niet ziet. En dat is zelfs ná dat de DX12 variant waar dit in zit uit is (best guess: fall 2018 windows)

Als je gaat praten over compute/parallellisatie, dan zul je zien dat nVidia al een aankondiging heeft gedaan vandaag waarbij het zeker één, waarschijnlijk twee generaties GPU's van hen gaat duren (volta) totdat je dit gaat zien... Wat dat betreft ligt alles nog open. Als je over standaarden/compute gaat praten, dan heeft AMD wel lang een voorsprong gehad, dat zie je in veel OpenCL-achtige toepassingen, en uiteraard de coin-hype.

Met dat in het achterhoofd, puur hypothetisch, heeft voor dit soort "niet-traditioneel"-GPU werk AMD potentieel juist de voorsprong, maar feit blijft: geen leverancier heeft nog hardware voor deze API; De DX12 versie ervoor is nog niet uit, en de software die het gebruikt is ook nog niet uit.

[Xeon_1]

Deze toevoeging werkt enkel deftig op nvidia.
Zie aankondiging van RTX gisteren.
AMD kaarten kunnen het wel maar tegen een zware prijs dat het een pak trager gaat.
Hardware limiet of software handicap dit ter keerzijde.
Maar nvidia kende is het een geforceerde software handicap zoals gameworks / vm passtrough support.

Nvidia is de Intel / Microsoft van de gpu wereld
Zou me niet verbazen dat ze gewoon wat geld aan ms gegeven hebben voor deze nvidia "only" feature om AMD voor een vol domme feit te zetten en nog meer marktaandeel te krijgen

[Enchantress]

Nee, Nvidia heeft een eigen RTX ontwikkeld, deze van MS wordt door AMD ook volledig ondersteunt.

[StefanDingenout]

op 1 kaart van nvidia die nog uit moet komen en geen normale gamers kaart is. Natuurlijk is er duidelijk samenwerking tussen ms en nvidia, maar het is niet alsof AMD dit soort hardware niet kan introduceren voor het zelfs maar een beetje gebruikt word in games. Dan zijn we al wel wat jaartjes verder.

[sfranken]

Wat heeft AMD hiermee te maken? DX12 word ook door AMD kaarten geslikt, toch?

[Enchantress]

AMD’s Vega ondersteunt de volledige DX12 features, Nvidia pascal doet dat niet.
Dus wie loopt er precies achter?

[Verwijderd]

Objectief gezien?: AMD, want die kopen geen ontwikkelaars om met een ment to be played programma om spelletjes kreupel te maken voor concurenten.

oftoppic: dit gaat me waarschijnlijk erg veel -1tjes opleveren....

[NC83]

Dat doet AMD dus gewoon ook hoor, alle GPU vendors zijjn daar niet netjes in. Ik heb vragen van vendors gehoord om een feature toe te voegen aan een game omdat ze weten dat het niet super werkt op de andere GPU om betere scores te krijgen. Maakt niet uit of het NV of AMD is.

[Origin64]

AMD hebben al jaren zon programma waarin ze devs helpen om optimalisaties voor hun architercture toe te voegen aan de engine. Of ze daarbij ook bewust nvidia slechter laten presteren weet ik niet. Ik heb er niet van gehoord maar het zou zomaar kunnen.