Om even duidelijkheid te scheppen:
Dit is niet duidelijk maar misleidend.
Cg is een programmeer taal (vergelijkbaar met de taal C, vandaar ook de naam Cg = 'C for graphics') waarmee ipv in assembly dus in een soort c geschreven wordt.
dit klopt zover.
CPU <-> IA32ssemble/machine code <-> C voor x86 platform
GPU <-> PS/VS_ASEMBLER <->Cg voor NV GPU's etc.
[quote]
[b]Dit is +-10 keer zo compact en dus ook veel sneller (en overzichtelijker) te schrijven.
[/quote]
De Cg source code is compact tov ASM dus handzamer en sneller te ontwikkelen/programmeren time to market, maar moet ook weer gecompileerd worden naar PS/VS Asembler en de Efficientie ervan bepaald de performance hit want manueel Assembler proggen is efficienter maar kost veel tijd
dus Cg is Compacter kwa Source code maar de gegenereerde assembler kan groter zijn dan als je het handmatig zelf programmeerd dus Cg compiler afhankelijk.
De compiler zal als eerste versie niet zo optimaal zijn dus
Cg zal eerder langzamer zijn maar DX8,x/9 features zijn wel sneller geimplementeerd met een geringe performance verlies afhankelijk van de Cg compiler versie.
[quote]
De output van deze taal wordt gecompileerd naar OpenGL of DirectX (kan de compilere beide aan) door een compiler die voor de specifieke hardware is geschreven. [b]
[/quote]
Nee Cg Wordt gecompileerd naar het bekende Pixel& vertex shader Assembler wat de GPU slikken kan
DirectX en OpenGL stuur deze code als data met de rest van de T&L data naar de GPU die verwerkt dan de T&L data streamm met GPUmachinekode
Dat kan als runtime interpreter in OpenGl directX runtime of als onderdeel in de DirectX sDK of precompiled.
Cg is bedoeld als hoger orde programmeertaal om de ontwikkeling project te ver aangenamen en versnellen.
Het gecompileerd eeindresultaat zal dus weer dat bekende GPU asembler zijn.
Net zoals er nu in C/C++/Pascal/java en etc geprogrammerd word ipv Assembler is dat machinetaal erg ver van menselijk begrijpen afstaat en een hogere orde taal gewoon een abstactie is voor meer begrijpelijke programmer taal die dichter bij het menselijk denken staat
je kan 'n CPU(/GPU) leterlijk machine code laten vreten.
*)Machine taal
in Hex 4F 7A FF 01 dit zijn dan 32bits
// dit is rete snel aangezien je geen overhead hebt en alles zelf in de hand dus niet afhankelijk van 'n compiler efficientie.
*)Assembler
Pop EAX
push EAX
//idem maar dan weet je wat die hex code voorsteld
in Opcode en Operands
*)hogere orde taal C++
Teller++;
// hier zie je meteen als programmeur wat de bedoeling is de compiler generreerd hieruit een lap michine/assemler code wat je in die andere methodes zelf had moet schrijven en testen en debuggen wat nu via compilatie voor je gegenereerd wordt en enkel seconden ipv uren.
Daarom wordt Assembler graag gemeden alleen voor optimalisatie en waar performance heel belangrijk is bijvoorbeeld drivers.
Omdat Assembler
Snel
Moeilijk
en tijdrovend is.
dus als Tijd geld is en performance geen preoriteit of voldoende dan hogere orde taal.
en nVidia wil dus met Cg dit ook voor de GPU verkrijgen.
Contrary to Nvidia's claim, OpenGL 2.0 WILL be 100% backward compatible with existing OpenGL levels. This has been stated in every presentation on OpenGL 2.0 since the beginning.
.
/i/1198048718.png?f=fpa)
)
:strip_icc():strip_exif()/u/1104/icon.jpg?f=community){kind=icon}
:strip_icc():strip_exif()/u/18149/catfish60.jpg?f=community){kind=small}
:strip_exif()/u/25889/boes.gif?f=community){kind=small}
:strip_exif()/u/27690/Misc_-_Boy.gif?f=community){kind=small}
:strip_exif()/u/55067/teqsmall2.gif?f=community){kind=small}
:strip_exif()/u/818/we33ee45.gif?f=community){kind=small}