Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 24 reacties
Bron: nVnews

Een artikel van nVnews over de nVidia Cg programmeertaal is gisteren geupdate met een interview met David Kirk, de chief scientist van het bedrijf. De vragen richten zich vooral op de manier waarop Cg kan bijdragen aan fotorealistische beelden, maar er wordt ook gesproken over de moeilijksheidsgraad van het programmeren, de manier waarop oude kaarten met in Cg geschreven spellen om gaan en performance. Het is natuurlijk overbodig om te zeggen dat Kirk positief is over al deze punten, maar 3Dlabs denkt er toch heel anders over, volgens een artikel op Extreme Tech. Deze hebben meer vertrouwen in OpenGL 2.0:

nVidia Cg met oude bok 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.

Contrary to Nvidia's claim, developers WILL have access to low-level hardware features from the assembly level if they so desire. Each hardware vendor will have the choice of supporting their own hardware-specific assembly language or the more common ARB_vertex_program assembly language extension, as they desire. These assembly level interfaces will work seamlessly with the OpenGL 2.0 high level shading language.

Contrary to their implied positioning, Nvidia's is not planning to offer Cg to the OpenGL Architecture Review Board for consideration as a standard of any type. Rather, they have stated that they fully intend to control the specification and implementation. Other graphics hardware vendors would be offered the ability to implement this Nvidia-specified language, under Nvidia licensing terms, for their own hardware.

Goodiem4n scoort 4-op-een-rij .

Moderatie-faq Wijzig weergave

Reacties (24)

Om even duidelijkheid te scheppen:
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 is +-10 keer zo compact en dus ook veel sneller (en overzichtelijker) te schrijven.
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.

Nu is die compiler er alleen voor nVidia kaarten (duh...ze hebben hem ontwikkeld), maar deze compiler can ook door ATI herschreven worden. En van wat ik heb begrepen is Cg een open standaard (dit blijkt uit de dia slides die ik van nVidia heb gezien en meerdere previews op het net; ik denk dat de laatste alinea van de preview hierboven dus liegt).

Dus zij kunnen gratis hun eigen comp8iler schrijven, mat de gratis SDK die nu op de developers board van nVidia te downloaden is (alsmede met een groot aantal al geschreven shaders :) )

Maar het belangrijkste is dat Cg een taal is om shaders mee te schrijven, om grafische mooi-igheden met textures te doen, en niet voor vertices en polygonen, waar je dus OpenGL en Direct3D voor hebt. Cg is dus een soort programmatisch Photoshop, waar OpenGL en Direct3D een soort commandline 3DSMAX of MAYA zijn (ik weet het, de vergelijking gaat niet helemaal op, maar nu snapt de digibeet het wellicht wat beter).
Ze zitten dus helemaal niet in elkaars vaarwater. Tenminste, dat is wat ik allemaal heb begrepen.
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.
edit : drukte op enter bleek "posten" de standaard button te zijn :'(
*)Assembler
Pop EAX
push EAX
//idem maar dan weet je wat die hex code voorsteld
in Opcode en Operands

*)hogere orde taal C++
Teller++;
ehm, Pop EAX en Push EAX heffen elkaar precies op (behalve dat de top van de stack in EAX geladen wordt)
Teller++ wordt zoiets als INC EAX (mits variabele Teller in register EAX)

Het principe is duidelijk, maar je voorbeelden hadden iets zorgvuldiger uitgezocht kunnen zijn :o
Ik snap dit bericht niet helemaal. Cg is bedoeld om de vertex en pixel shaders op nieuwe kaarten te kunnen gebruiken zonder die in assembly te hoeven aanspreken (wat heel moeilijk en tijdrovend is). Je kan het gebruiken icm. directx en opengl dus OpenGL 2.0 is toch geen concurrent?

Uit dit bericht blijkt dus dat in OpenGL 2.0 die dingen nog steeds via assembly gaan, lijkt mij Cg dus wel nuttig samen met OpenGL 2.0.
In plaats van naar een gestandaardiseerd iets te gaan, lijkt het wel of iedereen zijn eigen 'standaarden' bedenkt, en zijn eigen weg gaat. Dit lijkt me nou niet echt bevorderlijk, zometeen worden spellen Cg-only of opengl-only, wat natuurlijk niet handig is.
En de grafische kaarten moeten er ook allemaal maar mee om kunnen gaan...
Aan de ene kant heb je gelijk. Maar aan de andere kant, als die cg gewoon beter is, met mooiere beelden e.d., dan doet nvidia het dus goed. Ze hebben een andere methode die dus schijnbaar mooiere dingen kan bereiken. Dan kan het misschien afwiken van de huidige standaard, maar als het echt beter is, dan wordt het de nieuwe standaard. En tja, ik vind dat zoiets nooit slecht kan zijn. En als het niet goed genoeg zal zijn in vergelijking met opgengl 2.0, dan sterft het inderdaad vanzelf wel weer, zoals beneden ook al vermeld werd.
De GPU's zijn juist niet standaard.

Cg wordt gebruikt door OGL/DX8.x of hoger door de runtime interpreter voor beide API's
Krijgen we straks weer het gedoe net als ooit met 3Dfx.

Alle andere hardware fabrikanten houden zich netjes aan de standaards. Behalve de grootste speler.

Maar goed uiteindelijk komen we wel weer op een standaard uit al is het via een om weg.
Sja, uiteindelijk heeft het 3dfx geen good gedaan....

Weten we nu wat nVidia te wachten staat?
Ach....als het nix is sterft het vanzelf uit... is het heel mooi zijn wij heel blij..... toch? of denk ik nu TE simpel
Als ik het zo lees draait een gecompileerd Cg-programma bovenop DirectX/OpenGL. Het had revolutionair geweest als een Cg-applicatie "direct op de videokaart" had gedraaid (op de PC welliswaar, maar met directe toegang tot de kaart), dan heb je maximale flexibiliteit en snelheid. De gelaagde softwarestructuur (DirectX/OpenGL) wordt dan wel om zeep geholpen.

Ik zie wel mogelijkheden in een statische, gecompileerde 3D softwarestack, getuned voor een bepaald systeem.
1 van de redenen van directx is juist om GEEN "direct op de videokaart" te krijgen, dit is namelijk zeer slecht: foutje in prog = crash, als gaat het sneller, nee bedankt
CG wordt dus geen open standaard.. Andere videokaart producenten moeten gaan lappen om CG te mogen implementeren..Denk niet dat ze daar veel zin in hebben. nVidia probeert zo natuurlijk zijn leidende positie te versterken en meer macht over de industrie te krijgen.. Straks verzinnen ze CG v.2 en dan moet ATi weer volgen en dokken om mee te kunnen.. Lekker dan. nVidia lijkt microsoft wel..
Wellicht komt het 'erbij'. Naast Direct3D, OpenGL nu ook nVidia Cg. Ik weet niet of het toekomst heeft, feit is wel dat nVidia marktleider is wat 'ontwikkelingsplatform' voor spellen betreft, maar 3dfx heeft het toch ook niet gered met Glide, terwijl 3dfx toch ook destijds marktleider was ...
David Kirk? Had Spock geen tijd ofzo :Y)
Hmmm dit is toch geen interview met David Kirk over CG? Dit is een reactie van "John Schimpf, Director of Developer Relations for 3Dlabs" over de claims die Kirk maakte
Ik quote maar ff uit de artikel waar naar verwezen word:
Op GameSpyDaily is een interview te vinden over dit onderwerp met nVidia's chief scientist, David Kirk
Lezen... :Z

\[off-topic]
Kama modden naar overbodig kan ik begrijpen, maar troll??
\[/off-topic]
't Ging er me alleen maar op dat de topic mi niet goed is...
Cg zelf was niet belangrijk genoeg voor het nieuws he...

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True