SiliconArts introduceert RayCore MC-architectuur voor realtime raytracing

SiliconArts heeft zijn RayCore MC-architectuur gepresenteerd. Deze grafische architectuur is bedoeld voor pathtracing en kan volgens het bedrijf bijvoorbeeld geïntegreerd worden in soc's. De eerste producten met deze architectuur moeten in 2021 worden aangekondigd.

De RayCore MC-architectuur is bedoeld voor integratie in chips van derde partijen. De architectuur is volgens SiliconArts schaalbaar en kan geïntegreerd worden in verschillende 'gameplatforms'. Het bedrijf noemt daarbij cloudplatforms, desktops, mobiele apparaten, consoles en vr- en ar-platforms. RayCore MC is momenteel beschikbaar in een externe graphics accelerator voor ontwikkelaars en soc-ontwerpers voor evaluatie. Momenteel zijn er verder nog geen concrete producten op basis van RayCore MC. SiliconArts verwacht dat de eerste soc's met deze architectuur in 2021 worden onthuld.

De RayCore MC-serie is bedoeld voor realtime pathtracing, een vorm van raytracing. Het bedrijf meldt dat de architectuur onder andere geschikt is voor toepassingen als global illumination, schaduwen en reflecties. Volgens SiliconArts kan de RayCore MC-serie naar verwachting 'tot 300 miljoen rays per seconde berekenen per vierkante millimeter aan chipoppervlak'. De power dissipation zou per milliwatt vijf miljoen rays per seconde bedragen. Deze prestatiegegevens zijn gebaseerd op verwachte rekenprestaties van de architectuur op een 5nm-procedé van TSMC, terwijl de huidige sample wordt geproduceerd op een 22nm-node van GlobalFoundries.

Het is niet duidelijk hoe RayCore MC zich verhoudt tegenover bijvoorbeeld de RTX-videokaarten van Nvidia of de RDNA2-chip in de Xbox Series X, aangezien Nvidia en Microsoft andere prestatiemetingen aanhouden. SiliconArts geeft aan op aanvraag meer gedetailleerde benchmarks en performance metrics te verstrekken. Het bedrijf heeft nog niet gereageerd op navraag van Tweakers.

SiliconArts is in augustus ook lid geworden van de Khronos Group, een consortium dat onder andere de Vulkan-api ontwikkelt. Het bedrijf zal onder andere werken om de Vulkan Raytracing-extensie compatibel te maken met zijn architecturen. De RayCore MC-serie biedt al ondersteuning voor Intels Embree-platform. Er wordt ook gewerkt aan ondersteuning voor DirectX en raytracingplug-ins voor Autodesk 3ds Max en Blender.

De komst van RayCore MC was al langer bekend. In september verscheen een roadmap van SiliconArts waarop deze architectuur al werd vermeld, naast enkele andere producten. Toen deelde het bedrijf echter nog geen prestatieverwachtingen van RayCore MC. Ook was niet duidelijk wanneer de architectuur beschikbaar zou komen. Het bedrijf meldde toen al wel dat de architectuur onder licentie beschikbaar zou komen.

Reacties (56)

[Sandor_Clegane]

'tot 300 miljoen rays per seconde berekenen per vierkante millimeter aan chipoppervlak'.

Ok, dat is mooi. Maar hoeveel rays heb je nodig voor een gemiddelde game/DCC applicatie? Anders is het een beetje onduidelijk welke performance we kunnen verwachten.

[Arnage]

Best veel. Real-time raytracing begint een beetje leuk te worden als je per pixel per frame minimaal één ray kan tracen.

Dus voor bijvoorbeeld 4k60 heb je 3840x2160x60 = 497.664.000 rays nodig.

Als je meerdere raytraced effecten wil combineren zal je hier dus een veelvoud van nodig hebben.

Daarnaast is afhankelijk van het effect één ray per pixel vaak erg ruisgevoelig, dus heb je een flinke denoiser nodig om er wat moois van te maken. Om de kwaliteit echt omhoog te krijgen moet je ook per effect meerdere rays per pixel gaan combineren, wat er voor zorgt dat je je raybudget nog eens mag vermenigvuldigen.

Tot slot moet je voor sommige effecten, zoals global illumination meerdere keren in de scene rond stuiteren, en dus nog een trace doen vanaf het eindpunt van je voorgaande trace, wat dus voor nog meer traces zorgt.

Er zijn allerlei shortcuts te nemen die je nu in RTX ondersteunende spellen ook toegepast ziet worden, maar als je zoals zij claimen voor volledig pathtraced spellen wil gaan, zit je dus al snel in de miljarden rays per seconden regio.

[dec0de]

Ik heb hier niks aan toe te voegen op 1 ding na wat jij al wist, maar sommigen wellicht niet: het gaat hier om resolutie, dus je hebt bijvoorbeel 4 keer minder rays nodig als je op 1080p60 gaat raytracen.

en nog wat:
we hebben het over per mm2. 300.000.000 rays per mm2 is best veel.
de TU104 (rtx 2080) is 545mm2. dat zou 1635x10^8 (163500000000) rays per seconde opleveren.

de gp102 gpu (gtx 1080) is 472mm2 in oppervlakte. zodoende zou je dus 1413x10^8 (141300000000) rays per seconde kunnen tracen.

de gm204 (gtx 980) is 398 mm2 in oppervlakte, zodoende zou je dus 1194x10^8 (119400000000) rays kunnen tracen.

waarom al deze oppervlaktes? gewoon om even er in te sneaken dat nvidia de die's steeds groter maakt. realistisch gezien ga je geen die van 550mm2 groot maken voor raytracing alleen. wel illustreerd het hoe snel die wel niet is

[Reactie gewijzigd door dec0de op 23 juli 2024 03:52]

[Ayporos]

En vergeet niet dat die 300 miljoen rays per mm2 is per seconde.

Als we uitgaan van 4k60fps met 3 'traces' per pixel (afhankelijk van aggregation/techniek/fidelity kan je dit een laag óf een hoog getal noemen) kom je dan dus neer op:
~500miljoen x 60 x 3 = 90 miljard traces per seconde.
90 miljard / 300 miljoen = 300mm2 aan chipoppervlak... uitgaande van hun claims/verwachtingen van de performance op 5nm.

Ter referentie, de die size van een RTX 2080ti is 775mm2

En besef ook dat 3 'traces' per pixel niet voldoende zal zijn, uitgaande van path tracing heb je:
- de initiële trace tot een object geraakt wordt
- shadow tracing
- light source tracing
- reflection tracing
En afhankelijk van hoeveel lichtbronnen er in een willekeurige scene actief zijn kan je die praktisch vermenigvuldigen met het aantal lichtbronnen.
En voor écht 'true to life' moet je het eindpunt van elke reflectie trace ook weer nieuwe shadow/light/reflection traces laten produceren.
Uiteraard kan je ook gewoon traces bundelen en 'versimpelen' of kiezen om enkel op bepaalde aspecten te focussen (wat RTX dus doet) en échte raytracing (niet path tracing) werkt weer nét wat anders.

Al met al, toch best vet dat we dus eigenlijk op het punt staan om hardware te hebben die real-time raytracing aan kan op 4k60fps.

[Bergen]

Als we de referentie van een RTX 2080ti met 775 mm2 gebruiken, dan zou de RayCore 775 * 300 miljoen = 232,5 miljard traces per seconde kunnen berekenen.

Als je een game in 4k60 wilt spelen (4096 * 2160 * 60 pixels per seconde) zou de engine 438 traces per pixel kunnen berekenen. Daar kun je hele mooie plaatjes mee maken, lijkt mij.

[dec0de]

4k60fps met 3 'traces' per pixel

4k = 2160 * 3840 = 8.294.400 pixels (~8.3 mil pixels);
dat moet x60 (want je wil 60 beeldjes per seconde renderen)
8294400 * 60 = 497.664.000 pixels (~500 mil pixels)

en dan nu 3x elke pixel tracen: 497.664.000 * 3 = 1.492.992.000 (~1.5 miljard traces)

1.500.000.000 / 300.000.000 = 5mm2

realistisch gezien is de echte performance op z'n minst 10% minder dan de echte performance, dan kom je uit op 270 mil pixels per seconde.

en dus 1.500.000.000 / 270.000.000 = 5.5mm2 chip oppervlak.

nu nog wachten in welke specefieke situatie de chip zoveel rays kan tracen. maar we zijn dus net wat dichter bij dan jij dacht
je zat er een factortje of 60 naast namelijk

edit:

typo

[Reactie gewijzigd door dec0de op 23 juli 2024 03:52]

[Ayporos]

Oeps!

[Arjant2]

~500miljoen x 60 x 3 = 90 miljard traces per seconde.

Waarom nog een keer x60? Die zit al in je 500 miljoen. Immer 8 miljoen pixels x 60fps kom je op 500 miljoen.
Volgens mij zit je er een factor 60 naast?

[Reactie gewijzigd door Arjant2 op 23 juli 2024 03:52]

[Bl00dsoul]

omdat het 60 frames per seconde zijn

[rvt1]

- de initiële trace tot een object geraakt wordt
- shadow tracing
- light source tracing
- reflection tracing

iets meer info:
Ik ben niet bekent met path tracing en wat het verschil is met ray tracing.
Maar je hebt wel al snel minimal 2 rays per pixel nodig.
1) tegen je object (vanuit het oogpunt)
2) Vanuit je 'hit' naar minimal een lichtbron om de kleur en lichtsterkte van je object te bepalen.

maar ja, dan ben jer er nog niet. heb je meer dan een lichtbron dan moet je eigenlijk wel gaan bepalen of deze invloed hebben op de kleur van je pixel, dus nog eens een paar 'rays'.

Alleen dan kun je goed schaduwen en kleuren bepalen, en die komen automatisch mee met het rayracen...

Overigens kan hier wel global illuminatie mee helpen, dus een schadow map maken op basis van je lichtbronnen die niet bewegen.

je hebt dus heel wat rays nodig voor het klassieke ray tracen!

[Wild Cat]

Een GPU benut niet de volledige oppervlakte voor deze Ray-Tracing cores en er nodige vrije ruimte op z'n plakje silicon word benut door de nodige andere logica die nodig is voor een GPU (of FGPA) Memory controllers, L2 Cache ... Er zit iets meer in z'n plakje silicon dan alleen maar RT-cores...

Dit is puur gebaseerd op de grote van de complete die en staat los van de daadwerkelijke (onbekend) aantal mm2 dat de hoeveelheid RT-cores in beslag nemen

[dec0de]

Als je zou hebben gelezen suggereer ik ook zeker niet dat dat het geval is

Waarschijnlijk heb je ook goed gelezen, maar better safe than sorry


Edit: laatste 3 regels:

waarom al deze oppervlaktes? gewoon om even er in te sneaken dat nvidia de die's steeds groter maakt. realistisch gezien ga je geen die van 550mm2 groot maken voor raytracing alleen. wel illustreerd het hoe snel die wel niet is

[Reactie gewijzigd door dec0de op 23 juli 2024 03:52]

[Quadrupeltje]

als we volledige realtime raytracing/pathtracing kunnen doen met een chip, zijn al die shaders etc op een gpu volledig nutteloos. en kan vrijwel de hele die-size uit alleen maar rt-cores bestaan.

cgi renderd ook volledig op cpu's zonder ook maar 1 functie van de gpu te gebruiken. ooit worden al die jaren van innovatie op gpu gebied in 1 klap overbodig.

[maali]

De tendens zit juist de andere kant op... vroeger werd 't inderdaad op CPU gerenderd. Reden is vooral dat GPUs stateless renderen dus lastig om gezamenlijk clusters aan/met dezelfde data te laten renderen. maar tegenwoordig zijn er legio GPU- of hybrid-renderers. ook voor cluster rendering. En zelfs als hobbyist ff een render doen scanline vs arnold/redshift met een doorsnee consumenten GPU, het verschil in snelheid is absurd in het voordeel van GPU-based renderen hoor. dat zijn seconden vs minuten.

[rjmno1]

Het licht er ook aan aan wat voor een procidee hij gebakken is.
Hoe kleiner alles is hoe meer rays per oppervlakte eenheid.Realtime raytracing leunt zwaar op de hardware wat je op je videokaart hebt.De 2080 er is de eerste videokaart waar dit daadwerkelijk geïmplementeerd is,misschien zitten er nog kinderziektes in en misschien met een andere opbouw en verdeling met alles samen als je nagaat dat alles weer kleiner word zit er zeker toekomst muziek in.Bovendien gaat de de zucht naar steeds meer ook wat hardware betreft van de monitoren en de tv,s die 4k en nu 8 k kunnen weergeven ,dat alles vraagt natuurlijk om een nog snellere videokaart en tevens natuurlijk met een hogere resolutie.In de gamewereld zitten ze ook niet stil en steeds groter wordende textures verschijnen elk jaar met de nieuwste games.Dus zo een videokaart onder load heeft nu erg veel te doen ja.
En als alles te veel word zet je gewoon alles op full hd en alles loopt als een trein.
Het technisch wereldje van de vooruitgang van de personal computer is al jaren in een stroomversnelling gekomen en zeker met nieuwe hardware is de zucht naar sneller en meer altijd aanwezig.

[Lijmer]

Ik denk dat je ipv één ray per pixel, één path per pixel bedoelt. Met één ray kun je alleen bepalen wat direct voor de camera is, en niet hoe dat object mogelijk belicht was. Zelfs dan is met één pad en een denoiser het vaak nog heel lastig om een plaatje te maken dat niet bijna alleen maar ruis is. Vanaf 4 paths per pixel gaat het er een beetje okay uitzien met een denoiser.

[delphium]

Is het niet zo dat voor global illumination, een keer de scene / het level wordt doorgerekend en dat als data wordt ingelezen? Zo werkt het in elk geval in veel 3D programma's.

[Lijmer]

Met Path Tracing (een techniek die Ray Tracing gebruikt) word een random walk gedaan van ligt rays. Je begint bij de camera, en kijkt waar mogelijk een photon van vandaag gekomen zou zijn. Dit doe je door een ray vanuit de camera de scene in te traces. Als een object in de scene wordt geraakt, wordt op basis van het materiaal een 'bounce' berekent. Dat betekend dat er vanuit de hitlocatie een nieuwe ray wordt getraced. Dit wordt herhaald tot een licht geraakt wordt of een aantal bounces bereikt is. Dit is de berekening voor één lichtpad. Als dit nog een aantal honderd keer wordt gedaan begint het plaatje wat minder ruis te krijgen.

Nu zijn er gelukkig een hoop manieren om de hoeveelheid ruis te verminderen, zoals 'Next Event Estimation', 'Multiple Importance Sampling', 'Resampled Importance Sampling'. Daarbij kan er ook nog iets als een denoiser gebruikt worden, wat wel de correctheid van je plaatje omzeep helpt, maar je wel meer in de real-time range komt.

[delphium]

Ik heb het over global illumination. Dat is intrinsiek iets anders dan raytracing waar jij het over hebt. Bij GI worden de fotonen vanuit de lichtbron berekend naar de camera toe, waardoor je een veel realistischer beeld krijgt dan met raytracing. Die berekeningen duren lang, maar als ze klaar zijn voor een scene, dan kun je daarna de camera verplaatsten zonder te herberekenen.

[koelpasta]

Ja, maar goed, dan heb je geen real-time tracer meer nodig en kun je die data opslaan als een soort textures.

[delphium]

Dat klopt, vandaar mijn vraag of dat hier ook geldt. Overigens is GI voor buiten scenes, hele grote levels, of levels met veel bewegende objecten, niet of minder geschikt vanwege de enorme rekentijden. Wel kan GI in combinatie worden gebruikt met path- of raytracing. Bijvoorbeeld een interieur scene waar alle vaste objecten met GI worden belicht en alle bewegende objecten met (realtime) ray tracing.

[Lijmer]

Wat ik heb beschreven doet exact die fotonen simulatie, maar dan vanuit de camera, wat exact het zelfde plaatje zal opleveren als een simulatie vanuit het licht (Light Tracing), maar zal veel sneller een ruisloos plaatje maken, omdat alle paden die de camera niet raken worden overgeslagen.

Wanneer jij Global Illumination noemt, denk ik dat je light mapping bedoeld. Dat is een techniek om lighting te cachen in textures. Global Illumination is niets anders dan dat je zowel directe als indirecte belichting meeneemt in je berekening.

Light maps worden vaak met Light Tracing berekend, wat gewoon Path Tracing is maar dan vanuit het licht ipv de camera. Het nadeel van light maps is dat je niet echt specular lighting kan cachen, aangezien dat view afhankelijk is. En zoals jij als zei, gaat dit ook stuk als een object beweegt. Omdat bij Global Illumination het ene object effect heeft op het andere object. Light Mapping geeft alleen correcte resultaten bij een volledig statische scene met materialen die volledig Lambertian zijn. Dat houdt developers natuurlijk niet tegen om het statische gedeelte van een scene te light mappen, en dan maar accepteren dat dynamische objecten geen invloed hebben qua Global Illumination.

Er zijn ook nog andere technieken zoals Photon Mapping, waarbij voor een statische scene wel specular materials gebruikt kunnen worden. Daarbij worden photon splats opgeslagen, en wordt er met een final render pass vanuit de primary visibilty photons gegathered om de belichting te berekenen. Dit werkt dan ook weer alleen voor statische scenes, maar kan wel view dependent shading berekenen.

Het doel uiteindelijk met real-time Ray Tracing (en dus eigenlijk real-time Path Tracing) is dat al deze pre-calculations niet meer nodig zijn, en dat correct licht transport berekend kan worden op dynamische scenes.

[delphium]

Wat ik heb beschreven doet exact die fotonen simulatie, maar dan vanuit de camera, wat exact het zelfde plaatje zal opleveren als een simulatie vanuit het licht (Light Tracing), maar zal veel sneller een ruisloos plaatje maken, omdat alle paden die de camera niet raken worden overgeslagen.

Ehh, nee. Vanuit de camera terug rekenen naar de lichtbronnen is veel minder nauwkeurig en daarbij mis je dus juist die indirecte verlichting die je bij GI wel hebt. Dat is het verschil tussen raytracing en GI.

In het artikel wordt gesproken over: "...de architectuur onder andere geschikt is voor toepassingen als global illumination, schaduwen en reflecties". Mijn initiële vraag is dus of deze global illumination wel echt global illumination is. Want voor zover ik weet wordt dat nooit real time berekend.

[Lijmer]

Ehh, nee. Vanuit de camera terug rekenen naar de lichtbronnen is veel minder nauwkeurig en daarbij mis je dus juist die indirecte verlichting die je bij GI wel hebt. Dat is het verschil tussen raytracing en GI.

Ehh, jawel? Met backwards tracing stop je niet bij je eerste hit, je blijft doorgaan met de random walk tot dat je een light raakt. Wanneer een light geraakt is, heb je photon path gevonden, en kun je de contribution van die photon op een pixel in je camera berekenen. Materials worden niet voor niets met een Bidirectional Reflectance Distribution Function (BRDF) gedefineerd en berekend. Die formule werkt hetzelfde in beide richtingen.

Het enige nadeel wat je hebt met puur backwards tracing is dat bepaalde scenarios heel unlikely zijn om te gebeuren (denk bijvoorbeeld aan hele kleine lights raken, en caustics) waardoor het heel lang duurt voordat je plaatje converged. Dit is voor een groot deel op te lossen met bidirectional path tracing, wat puur een optimalisatie is om je plaatje sneller te laten convergen.

Met puur Path Tracing kun je een 100% biasless plaatje met volledig gesimuleerd light transport berekenen.

In het artikel wordt gesproken over: "...de architectuur onder andere geschikt is voor toepassingen als global illumination, schaduwen en reflecties". Mijn initiële vraag is dus of deze global illumination wel echt global illumination is. Want voor zover ik weet wordt dat nooit real time berekend.

Je kunt met Ray Tracing er voor kiezen om alleen bepaalde effecten te simuleren, maar met Path Tracing kun je dus wel Global Illumination berekenen. Het doel is om dit dus ook in real-time te gaan doen. Je hebt zelfs filmpjes van 5 jaar geleden waar ze al real-time path tracing laten zien, alleen wordt dat nog niet op consumenten hardware gedaan. Bijvoorbeeld deze van Otoy: https://www.youtube.com/watch?v=FbGm66DCWok Over een aantal jaar zal Ray Tracing hardware snel genoeg worden zodat volledige GI berekend kan worden.

[Sandor_Clegane]

Hier een demo van de makers van Control, ik had hem al een keertje gezien maar de details waren een beetje "hazy".

https://www.youtube.com/watch?v=ERlcRbRoJF0

[his.dudeness]

ligt aan welke raytracing features je wilt gebruiken. games doen meestal bijv. alleen raytraced reflecties of belichting, maar we zijn nog niet zo ver dat we global illumination + schaduwen + reflecties enzovoort tegelijk kunnen doen.

[Exirion]

Ik zie mezelf nog elk uur even naar boven lopen om te kijken hoe het renderen vorderde op m’n 286...

[Zoijar]

povray

[Exirion]

Dat kwam later. Ik had een boek Advanced Graphics Programming In Turbo Pascal ('91). Ben op een gegeven moment dingen in assembly gaan doen. Bij de volgende computer (386SX-25) kocht ik een Texas Instruments 387SX clone die met de juiste optimalisaties beduidend sneller dan Intel kon zijn. Was leuk hobbyen

[Zoijar]

Kan ik me iets bij indenken Heb ook nog graphics geprogrammeerd in x86 assembly, en inderdaad een 386SX-25 als eerste 8086 computer (volgens mij heb ik ook nog een 387 coprocessor gekocht ooit, weet ik niet zeker meer). Daarvoor C64 assembly, daarna een DX40 en wou altijd graag een DX2-66, maar die overgeslagen en is een P60 geworden, en Glide programmeren voor de 3dfx voodoo, met later geruchten van een klein bedrijfje dat snellere kaarten dan de giant 3dfx kon maken... nvidia inderdaad

[Reactie gewijzigd door Zoijar op 23 juli 2024 03:52]

[SG]

Ipv 80387 had Weitec co pro erbij geprikt.

[Exirion]

Ik was jaloers op mensen met een DX2-66 maar heb 'm uiteindelijk ook overgeslagen. Ben van een 486SX-25 (kon op 40MHz draaien) in '93 naar een Pentium 133 in 1995 gegaan. In '98 heb ik ook die nVidia TNT gekocht in combinatie met een Celeron 300A @ 450MHz. De eerste PC in huis was een 8088 4.77MHz met Hercules monochroom video, dus in die paar jaar waren het al enorme stappen vooruit

[jj71]

Hee, leuk, ik heb vergelijkbare ervaringen.

Begonnen op de Amiga, met een Duits boek, Amiga 3D Grafik und Animation. Ik heb 't hier nog in de kast staan. Op de Amiga heb ik in C leren programmeren en in dat boek staat de source code voor een raytracer. Natuurlijk superlangzaam op de Amiga, die slechts een 7 MHz processortje had en 1 MB geheugen.

Daarna had ik ook een 386SX, 25 MHz waar ik ook een 387SX floating-point co-processor voor heb gekocht. En precies zoals jij heb ik daar met Turbo Pascal ook zelf een raytracer in Pascal geprogrammeerd. (Dat boek "Advanced Graphics Programming" had ik niet).

En de laatste maanden ben ik de programmeertaal Rust aan het leren en ben ik weer met raytracing bezig.

Als je raytracing leuk vindt dan is dit het ultieme boek: Physically Based Rendering: From Theory To Implementation. Ik heb het papieren boek, maar het is nu volledig gratis online te lezen.

[Exirion]

Rust wil ik beroepshalve nog eens naar kijken. Met name waar functional safety een rol speelt wordt het best veel toegepast. Dank voor de tip, interessant boek. Edit: ik zag net de cover van de 2016-editie en bedacht me dat ik daar al eens een sample (Amazon) van op m'n iPad had gezet. Wel gaaf dat ie nu gratis online staat

[Reactie gewijzigd door Exirion op 23 juli 2024 03:52]

[OxWax]

24 uur voor drie ballen met één lichtbron

[Exirion]

Komt het wel op neer ja Een beetje scene duurde al snel langer dan een dag. Ik kan me nog een artikel in PC Format herinneren met een demo op floppy erbij. Cover gevonden: https://www.retromags.com...ection=img_ctrl&img=29643

[Reactie gewijzigd door Exirion op 23 juli 2024 03:52]

[OxWax]

Ik had een powermac en POV ray tracing

Zalig die retrosite, kende hem niet.
thanx

[Exirion]

Ik kende ‘m ook niet, maar Google Images wel ‘“pc format” raytracing’ en ik herkende de cover.

[Sandor_Clegane]

En je dan afvragen of ie niet gewoon was vastgelopen......

[spoor12b]

Of zo'n zeven uur wachten voor één plaatje op mijn Amiga 500.

[Henk-Bakker]

Atari ST......

[23m3]

Daarop had je in principe 12% minder geduld nodig vanwege het verschil in kloksnelheid.

[Henk-Bakker]

Motorola 68000 toch?

[23m3]

Klopt!

[mr_evil08]

Dat was niet het enige wat vroeger langzaam ging. ;-)

[Bl4ckSunr1se]

rayTracing

[AverageNL]

Uiteraard - ik heb 't op hoge snelheid aangepast Thanks!

[Bl4ckSunr1se]

👍

[loekf2]

Weet niet hoe dit gaat vliegen. Het is een accelerator core, dus je hebt nog steeds een echte GPU nodig. Op de website is te vinden dat de core een AXI bus interface heeft, want normaal is voor een SoC met ARM cores. De GPU zou dus tijdens het renderen data heen en weer naar deze accelerator moeten sturen. Dus extra geheugen bandbreedte etc.

[Scriptkid]

Weet iemand hoegroot deze chips zijn.

Klinken nl veel krachtiger dan rtx. 300m per mm2 is best veel dat is op een chip van 1cm2 30 miljoen rays.

Dat is 120 mil op een chip van 2x2 cm dat zou meer dan genoeg zijn om op 1080p te renderen zonder frame drops.

Wat ik me wel afvraag is stell je hebt een rtx en deze addon , kunnen ze dan samen werken anders heb je er niks aan.


Ahh original article zeg 8,000M rays per second. Maar dan zou de chip enorm groot moeten zijn dus iets klopt er niet. En als de , er wel hoort te zijn ipv duizend tal is de chip enorm klein, wat missen we hier.


Wat ik me eerder af vraag, kunnen we rtx en deze chip dadelijk ook gebruiken voor hw path tracing van non lightning traces want ik zie daar veel meer improvemnt in dat in lighting ray tracing.

Dan kun je nl realtime hit tracing doen, iets wat je nu niet doet omdat je fps dan instort.

[Reactie gewijzigd door Scriptkid op 23 juli 2024 03:52]

[SuperDre]

Het zal niet als een addon gaan werken, het zal geintegreerd worden in nieuwe GPU's (of Nvidia/AMD hier gebruik van zullen gaan maken is natuurlijk maar de vraag).

[Scriptkid]

dat is toch zoon beetje de definitie van een addon, ze integreren deze tech in een ARM cpu,


Addon het toevoegen van iets aan iets ?

[Sandor_Clegane]

Addon als in een extra kaart lijkt me wat hij bedoeld.

Net als die Physics kaartjes in ye olden days.

[Yzord]

Oe, hoe vet wordt VR dan met deze addon? Dan krijgen we echt mooiere beelden te zien in onze brillen. Punt is wel dat er dan een SoC in de bril moet zitten als ik het goed begrijp?

Momenteel gebruiken de brillen zonder SoC ook niet de raytrace mogelijkheden op de Nvidia kaarten dus hopelijk komt er nu toch de mogelijkheid deze ruimschoots toe te passen in de toekomst.

[SuperDre]

Ik vind andere zaken dan toch even iets belangrijker, clearlenses ipv die troep fresnellenses en verhoging van de FOV. en zeker voor dat laatste is ook wat meer resolutie nodig in de breedte (tenzij men iets dergelijks als anamorphic kan toepassen), en met headsets als de nieuwe HP Reverb G2 hebben de highend headsets al moeite genoeg mee om die fatsoenlijk aan te sturen op 90fps en dat is dan nog niet eens op 'ultra' van de doorsnee 2d games..
Maar hoe sneller ze deze extra opties inbouwen, des te sneller zullen we nog meer kunnen genieten in VR. Blijf me nog steeds verbazen hoe goed 'Robinson: the journey' uit 2016 er uit ziet, alleen jammer dat die geen update meer heeft gehad om moderne headsets beter te ondersteunen (zoals native resolution en betere ondersteuning van de controllers, want zelfs de Vive Controllers heeft vaak genoeg problemen).

[Dark Angel 58]

SiliconArts... was het niet van Sun? SGI? Sun Silicon Graphics???