PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Interview mit David Kirk bei FiringSquad


egdusp
2003-09-30, 10:05:07
http://firingsquad.gamers.com/hardware/kirk_interview/

Interessant ist vor allem, dass er von seinem berüchtigtem Marketinggeschwafer abläßt und es ein gelungenes Interview ist.

Die wichtigsten Aussagen (IMHO):
- ATI hat nicht 2-3 mal die Shaderleistung wie die GFFX (er sagt allerdings auch nicht das Gegenteil)
- Er betrachtet die CineFX Architektur als überlegen in vielen Berreichen, nur leider haben die Entwickler angefangen auf Radeon zu programmieren und deswegen eine andere Art Shader verwendet, welche die CineFX Architektur nur langsam darstellen kann. Meine Interpretation seiner Aussage ist, dass es nicht primär um die Anzahl der temporären Register geht, sondern um die grundlegenden Ideen, die hinter den Shadern stehen. Er nennt dependant texture Reads und Sin/Cos Funktionen als Stärken der CineFX Architektur. Sofern man die Shader (was wohl auch so möglich ist, sonst hätten sie es wohl kaum so interpretiert) nach den GFFX Optimierungsrichtlinien schreibt, soll die R3xx Architektur sehr viel langsamer sein, bzw. die CineFX Architektur schneller als die guten (HL2, TBAOD) ATI Shader. Also im Endeffekt müssen die Entwickler nicht nur 2x kompilieren, sondern alle Shader für 2 völlig verschiedene Ansätze entwicklen. DA NV zu spät war, haben alle nach den R3xx Grundsätzen entwickelt (alles meine Interpretation).
- Er bestätigt, dass die Wahl von 32fp vor der Festlegung der DX9 Minimumspecs geschah. ATI hatte Glück, NV Pech.

mfg
egdusp

Hellknight[FA]
2003-09-30, 10:16:25
Original geschrieben von egdusp
http://firingsquad.gamers.com/hardware/kirk_interview/

Interessant ist vor allem, dass er von seinem berüchtigtem Marketinggeschwafer abläßt und es ein gelungenes Interview ist.

Die wichtigsten Aussagen (IMHO):
- ATI hat nicht 2-3 mal die Shaderleistung wie die GFFX (er sagt allerdings auch nicht das Gegenteil)
- Er betrachtet die CineFX Architektur als überlegen in vielen Berreichen, nur leider haben die Entwickler angefangen auf Radeon zu programmieren und deswegen eine andere Art Shader verwendet, welche die CineFX Architektur nur langsam darstellen kann. Meine Interpretation seiner Aussage ist, dass es nicht primär um die Anzahl der temporären Register geht, sondern um die grundlegenden Ideen, die hinter den Shadern stehen. Er nennt dependant texture Reads und Sin/Cos Funktionen als Stärken der CineFX Architektur. Sofern man die Shader (was wohl auch so möglich ist, sonst hätten sie es wohl kaum so interpretiert) nach den GFFX Optimierungsrichtlinien schreibt, soll die R3xx Architektur sehr viel langsamer sein, bzw. die CineFX Architektur schneller als die guten (HL2, TBAOD) ATI Shader. Also im Endeffekt müssen die Entwickler nicht nur 2x kompilieren, sondern alle Shader für 2 völlig verschiedene Ansätze entwicklen. DA NV zu spät war, haben alle nach den R3xx Grundsätzen entwickelt (alles meine Interpretation).
- Er bestätigt, dass die Wahl von 32fp vor der Festlegung der DX9 Minimumspecs geschah. ATI hatte Glück, NV Pech.

mfg
egdusp


Der Mann hat Ahnung! Muß wohl meine Meinung über die ATi-Oberen revidieren :D ;)

Gefällt mir, spiegelt genau das wieder was ich immer schon sagte: Von der Technologie-Seite und der DirectX9 Implementierung spielt NVidia mit ATi mindestens in einer Klasse. Leider hat NVidia da sein eigenes Süppchen gekocht und pokern wollen, mit dem Ende, dass sich NV grob verzockt hat :(


Greetings

Timo

Exxtreme
2003-09-30, 10:49:25
ROFL, K.D. ist immer wieder für einen Lacher gut. :D :up:

Temp-Variablen lassen sich AFAIK oft nicht vermeiden und die FP-Schwäche kann man manchmal umgehen indem man vorberechnete Daten verwendet anstatt es die GraKa rechnen zu lassen. Das geht aber auch nicht immer.

Mordred
2003-09-30, 10:55:19
Original geschrieben von Exxtreme
ROFL, K.D. ist immer wieder für einen Lacher gut. :D :up:

Temp-Variablen lassen sich AFAIK oft nicht vermeiden und die FP-Schwäche kann man manchmal umgehen indem man vorberechnete Daten verwendet anstatt es die GraKa rechnen zu lassen. Das geht aber auch nicht immer.

Das mag sein, Tatsache ist allerdings das NV keineswegs schlecht ist mit ihren CineFX es leigt scheinbar wirklich an der Optimierung.

ICh bin mal gespannt wie es aussieht WENN mal ein Game kommt das ATI und NVIDIA gleich gut supportet (falls das machbar ist).

DANN kann man erst sagen wer nun effektiver arbeitet vorher nicht.

Hellknight[FA]
2003-09-30, 10:56:16
Original geschrieben von Exxtreme
ROFL, K.D. ist immer wieder für einen Lacher gut.

Temp-Variablen lassen sich AFAIK oft nicht vermeiden und die FP-Schwäche kann man manchmal umgehen indem man vorberechnete Daten verwendet anstatt es die GraKa rechnen zu lassen. Das geht aber auch nicht immer.


OK - da das für manche hier doch zu hart zu sein schein


*zensiert* :D

Greetings

Timo

Al-CAlifAX
2003-09-30, 10:56:44
Original geschrieben von Hellknight[FA]
Der Mann hat Ahnung! Muß wohl meine Meinung über die ATi-Oberen revidieren :D ;)

Gefällt mir, spiegelt genau das wieder was ich immer schon sagte: Von der Technologie-Seite und der DirectX9 Implementierung spielt NVidia mit ATi mindestens in einer Klasse. Leider hat NVidia da sein eigenes Süppchen gekocht und pokern wollen, mit dem Ende, dass sich NV grob verzockt hat :(


Greetings

Timo

Mit deinen Worten klingt des immer negativ. Und die meisten stellen immer Ati als die unschuldsfirma die uns Grakalesitung zum billigen Preis liefert. Jungs Ati is ne ne firma wie jede andere. die haben genauso gepokert und haben glück gehabt. niemals haben sie die besser hardware gehabt. sonder die besser hardware zu den DX9 specs und zu den jetzt kommenden Spielen. Und die NV Struktur, auswirken wird sich des in Spielen die explizit die Atruktur annehmen werden wie Stalker oder Doom³. Oder evtl. Quake4. Leider is des net viel. Obwohl ich net überrascht wäre wenn meine 2 Leiblingsgames, DesuEX² und Thief³ ebenfalls angepasst wären. Denn beiden verwenden sehr viel Schatten. Ist sozusagen Spielbestandteil. Alles in allem wirds aber recht wenig werden was NV angepasst wird. Und das Interview zeigt es mal wieder. Wer zuerst am Markt is, hat die besseren karten für die neuen Strukturen. Also hoffen wir mal das NV mit PS3.0 zurückschlägt. Denn ein Monopol von Ati oder Nv wüncht sich keiner ausser Fans. Is genau wie im CPU markt. Lange zeit wars ruhig, jetzt schlägt AMD mal wieder zu und mach vieles richtig. Überhitzungsschutz, Headspreader usw. und dazu ne gute Performane, nur noch net ausgereift und zu teuer. Aber wir errinnern uns. Der P4 war es auch net. Und schauen wir heute ;) Es ist immer wieder gut 2 Fimren am Markt zu haben die sich gegenseitig ärgern um den Geldbeutel für uns zu schonen. Denn ganz ehrlich. 400€ (800DM) um HL² sehr gut spielen zu können (Wobei ich immernoch denke, das der Benchmark mehr verbraucht wie des Spiel nachher selber) und mit allen Details und high Quality ist ausbeute. Vor 2 Jahren hat man sich für 200€ eine Geforce 4Ti4200 gekauft und die hält heute noch. Was ich von den jetzigen 400€ Karten net grade behauoten kann, wenn wirklich DX9 so stark involviert wird. Denn echtes DX9 braucht neue Karten, NV40 und R420. Also wieder geld für unseren geldbeutel. Und dann kommen noch einseitige programmierungen hinzu. ´Die sich irgendwann im Markt auswirken werden. denn wenn wenn 80% der DX9 Games auf einer ATi besser laufen, wird sich das ATi gut bezahlen lassen. Denn sie haben keinen gegner. Ausserdem wer glaubt der NV40 wird sich ändern. Naja ich net. Er wird die Struktur beibehalten des NV40. Die können jetzt net nen komplettes Redesign machen, nur um sich ATi anzupassen und die eigenen Wege in Richtung PS3.0 usw. ausser acht zulassen. Zumindest hoffe ich das net. Denn dann würden sie hinterherkrebsen. und Ati als Technologieführer ansehen. Wäre schade, vor allem im Bezug auf die Quadros :( So lange Rede kurzer Sinn. Finde die Aussage im Interview korrekt. Und vor allem freundlicher als den post darunter, der immer sehr negativ klingt für NV. <- meine Meinung.

Gruß AC

Hellknight[FA]
2003-09-30, 11:03:30
Original geschrieben von Al-CAlifAX
Mit deinen Worten klingt des immer negativ. Und die meisten stellen immer Ati als die unschuldsfirma die uns Grakalesitung zum billigen Preis liefert. Jungs Ati is ne ne firma wie jede andere. die haben genauso gepokert und haben glück gehabt. niemals haben sie die besser hardware gehabt. sonder die besser hardware zu den DX9 specs und zu den jetzt kommenden Spielen. Und die NV Struktur, auswirken wird sich des in Spielen die explizit die Atruktur annehmen werden wie Stalker oder Doom³. Oder evtl. Quake4. Leider is des net viel. Obwohl ich net überrascht wäre wenn meine 2 Leiblingsgames, DesuEX² und Thief³ ebenfalls angepasst wären. Denn beiden verwenden sehr viel Schatten. Ist sozusagen Spielbestandteil. Alles in allem wirds aber recht wenig werden was NV angepasst wird. Und das Interview zeigt es mal wieder. Wer zuerst am Markt is, hat die besseren karten für die neuen Strukturen. Also hoffen wir mal das NV mit PS3.0 zurückschlägt. Denn ein Monopol von Ati oder Nv wüncht sich keiner ausser Fans. Is genau wie im CPU markt. Lange zeit wars ruhig, jetzt schlägt AMD mal wieder zu und mach vieles richtig. Überhitzungsschutz, Headspreader usw. und dazu ne gute Performane, nur noch net ausgereift und zu teuer. Aber wir errinnern uns. Der P4 war es auch net. Und schauen wir heute ;) Es ist immer wieder gut 2 Fimren am Markt zu haben die sich gegenseitig ärgern um den Geldbeutel für uns zu schonen. Denn ganz ehrlich. 400€ (800DM) um HL² sehr gut spielen zu können (Wobei ich immernoch denke, das der Benchmark mehr verbraucht wie des Spiel nachher selber) und mit allen Details und high Quality ist ausbeute. Vor 2 Jahren hat man sich für 200€ eine Geforce 4Ti4200 gekauft und die hält heute noch. Was ich von den jetzigen 400€ Karten net grade behauoten kann, wenn wirklich DX9 so stark involviert wird. Denn echtes DX9 braucht neue Karten, NV40 und R420. Also wieder geld für unseren geldbeutel. Und dann kommen noch einseitige programmierungen hinzu. ´Die sich irgendwann im Markt auswirken werden. denn wenn wenn 80% der DX9 Games auf einer ATi besser laufen, wird sich das ATi gut bezahlen lassen. Denn sie haben keinen gegner. Ausserdem wer glaubt der NV40 wird sich ändern. Naja ich net. Er wird die Struktur beibehalten des NV40. Die können jetzt net nen komplettes Redesign machen, nur um sich ATi anzupassen und die eigenen Wege in Richtung PS3.0 usw. ausser acht zulassen. Zumindest hoffe ich das net. Denn dann würden sie hinterherkrebsen. und Ati als Technologieführer ansehen. Wäre schade, vor allem im Bezug auf die Quadros :( So lange Rede kurzer Sinn. Finde die Aussage im Interview korrekt. Und vor allem freundlicher als den post darunter, der immer sehr negativ klingt für NV. <- meine Meinung.

Gruß AC

Ich denke, wenn NVidia's Finanzpolster nicht so fett gewesen wäre, hätten sie den NV30 von Grund auf anders entwickelt und man stände heute wesentlich besser da. Aber so bleibt halt Geld für Experimente. NV wird die NV3x wohl unter die Rubrik "Lehrgeld" abheften und sich in Zukunft wieder der Mehrzahl von Game-Entwicklern annähern :)

Exxtreme
2003-09-30, 11:04:16
Original geschrieben von Hellknight[FA]

Bist Du ein beim ATi-Einstellungstest durchgefallener Anwärter, welcher versucht den großen Entwickler-Guru raushängen zu lassen? Für solches Möchtegerne-Wissen kauf ich mir ne Computer-Bild ;D :asshole:

Beschränke Deine "Weisheiten" in Zukunft bitte nur noch auf's "Mod-Sein" OK? :D. Du verunsicherst noch die ganzen Noobs da draussen...


Greetings

Timo
:zzz:

Also diese Info habe ich Demirug, daß Temp-Variablen nicht gut sind und daß man auf vorberechnete Werte zurückgreifen sollte wenn es möglich ist. :P

Demirug
2003-09-30, 11:05:08
Original geschrieben von Hellknight[FA]
Solltest Du in der ATi-Hardware-Entwicklung (bzw. bei ATi) arbeiten so lese bitte nicht weiter :D ;) ansonsten...

kleiner verblendeter FanATiker, welcher versucht den großen Entwickler-Guru raushängen zu lassen. Für solches Möchtegerne-Wissen kauf ich mir ne Computer-Bild ;D :asshole:

Beschränke Deine "Weisheiten" in Zukunft bitte nur noch auf's "Mod-Sein" OK? :D. Du verunsicherst noch die ganzen Noobs da draussen...


Greetings

Timo

Sonst geht es dir aber noch gut? Zuwenig geschlafen letzte Nacht?

Exxtreme hat generel schon recht mit seinen Aussagen.

Es gibt allerdings durchaus ein paar Interesante Tricks mit denen man Variablen "einsparen" kann. Und auch für das berechnen habe ich inzwischen ein paar interesante Tricks gesehen.

DrumDub
2003-09-30, 11:06:30
Original geschrieben von Hellknight[FA]
Solltest Du in der ATi-Hardware-Entwicklung (bzw. bei ATi) arbeiten so lese bitte nicht weiter :D ;) ansonsten...

Bist Du ein beim ATi-Einstellungstest durchgefallener Anwärter, welcher versucht den großen Entwickler-Guru raushängen zu lassen? Für solches Möchtegerne-Wissen kauf ich mir ne Computer-Bild ;D :asshole:

Beschränke Deine "Weisheiten" in Zukunft bitte nur noch auf's "Mod-Sein" OK? :D. Du verunsicherst noch die ganzen Noobs da draussen...


Greetings

Timo

???

Al-CAlifAX
2003-09-30, 11:08:43
Original geschrieben von Hellknight[FA]
Ich denke, wenn NVidia's Finanzpolster nicht so fett gewesen wäre, hätten sie den NV30 von Grund auf anders entwickelt und man stände heute wesentlich besser da. Aber so bleibt halt Geld für Experimente. NV wird die NV3x wohl unter die Rubrik "Lehrgeld" abheften und sich in Zukunft wieder der Mehrzahl von Game-Entwicklern annähern :)

Von Grund auf neu entwickeln. oh man bei solchen Aussagen bekomme ich immer krebs. man DX9 wurde verabschiedet als der NV30 scho fertig war. Was sollense da noch ändern bitte? Um dann nochmal 1 jahr später erst mit ner neuen Graka rauszukommen. man oh man manche halte ATi echt für den Standard schlecht hin und finden des gut.

Ati = Standard != gut

So müsste es eher heissen ;)

Prost.

Exxtreme
2003-09-30, 11:30:32
Original geschrieben von [KoC]Mordred
Das mag sein, Tatsache ist allerdings das NV keineswegs schlecht ist mit ihren CineFX es leigt scheinbar wirklich an der Optimierung.
Das denke ich wiederum nicht. Ich glaube, man müsste die gesamte Grafik-Engine + Leveldesign FX-only zusamenschustern damit es gut performt. Also alles, was der FX weh tut, komplett weglassen oder versuchen es zu umgehen. Das sind zumindest schon die Temp-Veriablen und aufwändige Berechnungen.
Original geschrieben von [KoC]Mordred
ICh bin mal gespannt wie es aussieht WENN mal ein Game kommt das ATI und NVIDIA gleich gut supportet (falls das machbar ist).

DANN kann man erst sagen wer nun effektiver arbeitet vorher nicht.
Ich weiss leider auch nicht, ob man EINE ENGINE optimal auf beide Architekturen optimieren kann unter der Bedingung, daß man immer das gleiche Ergebnis bekommt.

Mordred
2003-09-30, 11:37:15
Original geschrieben von Exxtreme
Das denke ich wiederum nicht. Ich glaube, man müsste die gesamte Grafik-Engine + Leveldesign FX-only zusamenschustern damit es gut performt. Also alles, was der FX weh tut, komplett weglassen oder versuchen es zu umgehen. Das sind zumindest schon die Temp-Veriablen und aufwändige Berechnungen.

Ich weiss leider auch nicht, ob man EINE ENGINE optimal auf beide Architekturen optimieren kann unter der Bedingung, daß man immer das gleiche Ergebnis bekommt.

Joar genau das meint ich mit optimieren. Bei jeder optimierung ist der andere im Nachteil :>

Allerdings bin ich mir zeimlich sicher das die CineFX dann ebenso gut performt wie die ATI wenn nicht sogar noch besser. Aber das wird eh niemand machen der noch alle Sinne beisammen hat :>

ICh sag ja die sollten sich ma besten wirklich mal zu dritt an einen tisch setzen und mal Richtlinien entwickeln an die sich alle halten (NVidia ATI und MS)
Dann kann man anhand der Hardware immer noch genuch vorteile rausholen :>

Allerdings ist dies leider auch sehr unwahrscheinlich da man damit ja der Konkurenz auch hilft :>

IS schon alles shit :>

Bin mal gespannt wie der V8 Duo performen wird das juckt mich ehrlich gesagt atm etwas mehr ^^

Al-CAlifAX
2003-09-30, 11:38:44
Original geschrieben von Exxtreme
Das denke ich wiederum nicht. Ich glaube, man müsste die gesamte Grafik-Engine + Leveldesign FX-only zusamenschustern damit es gut performt. Also alles, was der FX weh tut, komplett weglassen oder versuchen es zu umgehen. Das sind zumindest schon die Temp-Veriablen und aufwändige Berechnungen.

Ich weiss leider auch nicht, ob man EINE ENGINE optimal auf beide Architekturen optimieren kann unter der Bedingung, daß man immer das gleiche Ergebnis bekommt.


1. Denke auch eher das die Vorteile der FX in bereichen liegen die dann wiederum schlecht für ATi sind. wie Shadow techniken usw. Kommt halt aufs Spielprinzip an. Wird bestimmt einige Entwickler geben die darauf setzen werde. Stalker hatte viele innelevels mit Schatten. Thief³ und DeusEx² auch. Doom³ besteht ja nur aus Schatten ohne Grafik *gg*. Also abwarten. Die Masse wird aber allerdings Standard 2.0 Shader werden. Solange es not os inkompatibel wie in Halo wird. Wo eine Karte ohne Shader ein shit bild anzeigt und selbst HL1 noch bessere texturen hat. ;)

2. Weiss net. man könnte zumindestesn gewissse Dinge einbinden. zum einen den Renderpfad 2.0A. Das neue SDk is ja nu da. Dann Cg einbinden und bei erkennung einer FX karte aktivieren. Und die Shade so oder so zu 1.1-1.4 kompatibel machen. So dass bei Effekten die eigentlich mit den älteren Versionen fast gleich aussehen auch die ältere version verwendet wir und net explizit nur 2.0 verwendet wird. (is ja genau das was Ati verhindern will)

Naja ich für meine teil kann mich net beschweren. Zocke derzeit immernoch Frozen Throne ;) das nächste Games was ich kaufe wird entweder HL² werden. sollte es aber erst X-Mas kommen dann DeusEx², is einfach mal innovativer und genialer. grafik is für mich net alles. sondern leveldesign, -struktur, Spielaufbau usw.

Demirug
2003-09-30, 11:39:38
Original geschrieben von Exxtreme
Das denke ich wiederum nicht. Ich glaube, man müsste die gesamte Grafik-Engine + Leveldesign FX-only zusamenschustern damit es gut performt. Also alles, was der FX weh tut, komplett weglassen oder versuchen es zu umgehen. Das sind zumindest schon die Temp-Veriablen und aufwändige Berechnungen.

Wenn man am Leveldesign rumändert hat wirklich man aber was falsch gemacht. Denn das Design sollte man ja auch für DX7 und DX8 Karten benutzten können.

Die Temp-Variablen sind ein Job für den Compiler da sollte man sich nicht kümmern müssen. Das mit den Berechnungen durch Texturereads ersetzten ist da schon was anderes. Für das Problem habe ich aber inzwischen einen "Proof of Concept". Und dabei auch heraus bekommen warum ATI das nicht sonderlich mag.

Ich weiss leider auch nicht, ob man EINE ENGINE optimal auf beide Architekturen optimieren kann unter der Bedingung, daß man immer das gleiche Ergebnis bekommt.

Genau das gleiche nicht was aber ja auch schon aufgrund der unterschiedlichen Genauigkeit schwer werden dürfte. Es sollte aber durchaus im nicht wahrnehmbaren Bereich liegen.

ShadowXX
2003-09-30, 11:44:53
Ich wäre sowieso sehr vorsichtig damit, Aussagen des nV Chefdesigners über 'seine' FX zu sehr auf die Goldwaage zu legen (gilt auch für ATI-Ing's über ihr 'Baby').

Er wird Sie kaum schlechtreden.....oder hat schon mal jemand den Chef-Ing von Intel sagen gehört: Yo, der P4 ist nich so dolle...

Ist also mit Vorsicht zu geniessen...er muss 'sein' Werk ja auch irgendwie rechtfertigen.

Es könnte allerdings sein, dass mit einer vollständigen Anpassung einer Engine (an die FX), es tatsächlich ein pari in der Spieleleistung geben könnte...

J.S.Shadow

Exxtreme
2003-09-30, 11:52:46
Original geschrieben von Demirug
Wenn man am Leveldesign rumändert hat wirklich man aber was falsch gemacht. Denn das Design sollte man ja auch für DX7 und DX8 Karten benutzten können.

Die Temp-Variablen sind ein Job für den Compiler da sollte man sich nicht kümmern müssen. Das mit den Berechnungen durch Texturereads ersetzten ist da schon was anderes. Für das Problem habe ich aber inzwischen einen "Proof of Concept". Und dabei auch heraus bekommen warum ATI das nicht sonderlich mag.



Genau das gleiche nicht was aber ja auch schon aufgrund der unterschiedlichen Genauigkeit schwer werden dürfte. Es sollte aber durchaus im nicht wahrnehmbaren Bereich liegen.
Ich meinte das jetzt anders.

Angenommen um einen Effekt zu realisieren, braucht man viele Temp-Variablen. Als "Optimierung" auf die FX müsste man logischerweise diesen Effekt weglassen oder einen ähnlich aussehenden Ersatz finden und dann beten, daß dieser Ersatz auf der R300 gut performt. Wenn das nicht der Fall ist, dann hat man endweder leicht unterschiedliche Ergbnisse oder man lässt diesen Effekt weg.

zeckensack
2003-09-30, 11:59:59
Original geschrieben von Demirug
Die Temp-Variablen sind ein Job für den Compiler da sollte man sich nicht kümmern müssen. Das mit den Berechnungen durch Texturereads ersetzten ist da schon was anderes. Für das Problem habe ich aber inzwischen einen "Proof of Concept". Und dabei auch heraus bekommen warum ATI das nicht sonderlich mag.Wegen der Indirektion?
Ich habe nachgemessen, und bin auf zwei Takte pro Pipe pro Indirektion gekommen. Ich hatte eigentlich viel schlimmeres erwartet, nämlich acht.

ShadowXX
2003-09-30, 12:01:20
Edit:löschen..ist irgendwie doppelt gepostet worden..

J.S.Shadow

Endorphine
2003-09-30, 12:05:13
Demirug,

lass' die Flamekids doch flamen, wenn sie Freude daran haben ;) Mich würde eher mal deine Meinung zu dem Interview und den Aussagen von David Kirk interessieren, was du darüber denkst :)

Da steht ja doch einiges in Kontrast du deinem CineFX-Artikel, oder???

seahawk
2003-09-30, 12:06:21
Original geschrieben von Exxtreme
Ich meinte das jetzt anders.

Angenommen um einen Effekt zu realisieren, braucht man viele Temp-Variablen. Als "Optimierung" auf die FX müsste man logischerweise diesen Effekt weglassen oder einen ähnlich aussehenden Ersatz finden und dann beten, daß dieser Ersatz auf der R300 gut performt. Wenn das nicht der Fall ist, dann hat man endweder leicht unterschiedliche Ergbnisse oder man lässt diesen Effekt weg.

Was immer auch bedeutet, dass man mit dem ATI-Code als Ausgang arbeitet.

Es gibt imo keine "neutrale" Lösung für Shaderoptimierung.

zeckensack
2003-09-30, 12:08:19
Original geschrieben von egdusp
http://firingsquad.gamers.com/hardware/kirk_interview/Davy Boy gibt sich mal wieder in Bestform. Unglaublich.
*kopfschüttel*

Auf der einen Seite preist er immer noch das 'dead limb' 32bit-FP-Ops an. Auf der anderen Seite sagt er klipp und klar, daß man auf NV3x optimieren muß, wenn das ganze nett aussehen soll. Daß diese Optimierung zwangsläufig darauf hinaus läuft, keine FP-Shader zu benutzen, das wird er sehr wohl wissen, nur erwähnen kann er's natürlich nicht, denn dann würde er recht dämlich aussehen.

Auch recht lustig, daß er Sin/Cos erwähnt. Da braucht doch tatsächlich NV35 nur halb soviele Takte wie R300, wenn sonst nichts bremst. Großartig! :up:

Das einzige was NV3x gut kann, sind dependent reads und fixed point Ops. Das empfehle ich als 'Hintergrundwissen' zum Lesen dieses Interviews.


Und ad "24 bit ist doof", schaumer mal was DeltaChrome und Volari bieten ... 24 Bit? Aha ...

Demirug
2003-09-30, 12:23:37
Original geschrieben von Exxtreme
Ich meinte das jetzt anders.

Angenommen um einen Effekt zu realisieren, braucht man viele Temp-Variablen. Als "Optimierung" auf die FX müsste man logischerweise diesen Effekt weglassen oder einen ähnlich aussehenden Ersatz finden und dann beten, daß dieser Ersatz auf der R300 gut performt. Wenn das nicht der Fall ist, dann hat man endweder leicht unterschiedliche Ergbnisse oder man lässt diesen Effekt weg.

Das ist mal wieder so ein viele Wege führen zum gleichen Ergebniss Problem. Irgendwann ist man aber trotzdem am Ende was das einsparen angeht. Mit Tricks meinte ich aber zum Beispiel das man durchaus am Anfang das Shaders eine Speicherzelle für eine FP32 Temp benutzten kann und dann später die gleiche Zelle für zwei FP16 Temps. Dafür muss aber der Treibercompiler ran.

Gast
2003-09-30, 12:26:03
Ich finde das es endlich mal ein ehrliches und gutes Interview ist, wo DR.K. sogar eingesteht, das ATi zumind. ebenbürtige HW hat, die in einigen Bereichen schneller ist.
Wo ist also der Lacher ??? Wenn einige Leute nur halb so viel Plan wie er hätten, wären Sie vielleicht etwas ruhiger und würden weniger Fanboy Flames rausblasen!

Demirug
2003-09-30, 12:26:43
Original geschrieben von zeckensack
Wegen der Indirektion?
Ich habe nachgemessen, und bin auf zwei Takte pro Pipe pro Indirektion gekommen. Ich hatte eigentlich viel schlimmeres erwartet, nämlich acht.

Was hast du den gemacht?

Einfach eine Reihe von Texturereads hintereinader die immer das Ergebniss des vorhergehenden benutzten?

Ich meinte das ganze aber sowieso eher in der Richtung das man mit dieser Technik schnell an das Limit von 4 dependent reads kommt.

Demirug
2003-09-30, 12:29:54
Original geschrieben von Endorphine
Demirug,

lass' die Flamekids doch flamen, wenn sie Freude daran haben ;) Mich würde eher mal deine Meinung zu dem Interview und den Aussagen von David Kirk interessieren, was du darüber denkst :)

Da steht ja doch einiges in Kontrast du deinem CineFX-Artikel, oder???

Viel sagen tut er ja eigentlich nicht. Einen richtigen Wiederspruch zu meinem Artikel sehe ich da auch nicht weil er ja das Thema weiträumig umgeht.

Exxtreme
2003-09-30, 12:34:09
Original geschrieben von Gast
Ich finde das es endlich mal ein ehrliches und gutes Interview ist, wo DR.K. sogar eingesteht, das ATi zumind. ebenbürtige HW hat, die in einigen Bereichen schneller ist.
Wo ist also der Lacher ??? Wenn einige Leute nur halb so viel Plan wie er hätten, wären Sie vielleicht etwas ruhiger und würden weniger Fanboy Flames rausblasen!
ROFL, yo, K.D. sagt, daß die HW ebenbürtig ist, dann stimmt das auch. :eyes:

Dieses Interview ist eine normale PR-Aktion... nicht mehr und nicht weniger. Was soll er denn sonst sagen... etwa, daß die HW nicht besser ist?

Demirug
2003-09-30, 12:35:11
Original geschrieben von zeckensack
Auf der einen Seite preist er immer noch das 'dead limb' 32bit-FP-Ops an. Auf der anderen Seite sagt er klipp und klar, daß man auf NV3x optimieren muß, wenn das ganze nett aussehen soll. Daß diese Optimierung zwangsläufig darauf hinaus läuft, keine FP-Shader zu benutzen, das wird er sehr wohl wissen, nur erwähnen kann er's natürlich nicht, denn dann würde er recht dämlich aussehen.

Ganz so schlimm ist es nun auch wieder nicht. Im richtigen Mass benutzt kann man schon mit FP Shader arbeiten. Ist eben schade das der Genauigkeits-Mix nicht voll unter DX zugänglich ist.

Und ad "24 bit ist doof", schaumer mal was DeltaChrome und Volari bieten ... 24 Bit? Aha ...

32 Bit sind mir aber trotzdem lieber. Allerdings ist derzeit der Preis dafür zu hoch.

AlfredENeumann
2003-09-30, 13:22:50
Original geschrieben von Exxtreme
Das denke ich wiederum nicht. Ich glaube, man müsste die gesamte Grafik-Engine + Leveldesign FX-only zusamenschustern damit es gut performt. Also alles, was der FX weh tut, komplett weglassen oder versuchen es zu umgehen. Das sind zumindest schon die Temp-Veriablen und aufwändige Berechnungen.

Ich weiss leider auch nicht, ob man EINE ENGINE optimal auf beide Architekturen optimieren kann unter der Bedingung, daß man immer das gleiche Ergebnis bekommt.


Eben. siehe Dumm3. Da gibt es extra einen auf NV3X zugeschnittenen Pfad, und so erheblich wir DK gerne möchte setzen sich die NV Karten da nicht ab.

Gast
2003-09-30, 15:04:10
Original geschrieben von Al-CAlifAX
Mit deinen Worten klingt des immer negativ. Und die meisten stellen immer Ati als die unschuldsfirma die uns Grakalesitung zum billigen Preis liefert. Jungs Ati is ne ne firma wie jede andere. die haben genauso gepokert und haben glück gehabt. niemals haben sie die besser hardware gehabt. sonder die besser hardware zu den DX9 specs und zu den jetzt kommenden Spielen. Und die NV Struktur, auswirken wird sich des in Spielen die explizit die Atruktur annehmen werden wie Stalker oder Doom³. Oder evtl. Quake4. Leider is des net viel. Obwohl ich net überrascht wäre wenn meine 2 Leiblingsgames, DesuEX² und Thief³ ebenfalls angepasst wären. Denn beiden verwenden sehr viel Schatten. Ist sozusagen Spielbestandteil. Alles in allem wirds aber recht wenig werden was NV angepasst wird. Und das Interview zeigt es mal wieder. Wer zuerst am Markt is, hat die besseren karten für die neuen Strukturen. Also hoffen wir mal das NV mit PS3.0 zurückschlägt. Denn ein Monopol von Ati oder Nv wüncht sich keiner ausser Fans. Is genau wie im CPU markt. Lange zeit wars ruhig, jetzt schlägt AMD mal wieder zu und mach vieles richtig. Überhitzungsschutz, Headspreader usw. und dazu ne gute Performane, nur noch net ausgereift und zu teuer. Aber wir errinnern uns. Der P4 war es auch net. Und schauen wir heute ;) Es ist immer wieder gut 2 Fimren am Markt zu haben die sich gegenseitig ärgern um den Geldbeutel für uns zu schonen. Denn ganz ehrlich. 400€ (800DM) um HL² sehr gut spielen zu können (Wobei ich immernoch denke, das der Benchmark mehr verbraucht wie des Spiel nachher selber) und mit allen Details und high Quality ist ausbeute. Vor 2 Jahren hat man sich für 200€ eine Geforce 4Ti4200 gekauft und die hält heute noch. Was ich von den jetzigen 400€ Karten net grade behauoten kann, wenn wirklich DX9 so stark involviert wird. Denn echtes DX9 braucht neue Karten, NV40 und R420. Also wieder geld für unseren geldbeutel. Und dann kommen noch einseitige programmierungen hinzu. ´Die sich irgendwann im Markt auswirken werden. denn wenn wenn 80% der DX9 Games auf einer ATi besser laufen, wird sich das ATi gut bezahlen lassen. Denn sie haben keinen gegner. Ausserdem wer glaubt der NV40 wird sich ändern. Naja ich net. Er wird die Struktur beibehalten des NV40. Die können jetzt net nen komplettes Redesign machen, nur um sich ATi anzupassen und die eigenen Wege in Richtung PS3.0 usw. ausser acht zulassen. Zumindest hoffe ich das net. Denn dann würden sie hinterherkrebsen. und Ati als Technologieführer ansehen. Wäre schade, vor allem im Bezug auf die Quadros :( So lange Rede kurzer Sinn. Finde die Aussage im Interview korrekt. Und vor allem freundlicher als den post darunter, der immer sehr negativ klingt für NV. <- meine Meinung.

Gruß AC

naja die 400€ radeon 9700pro von dezember letzten jahres wird sich noch ne ganze weile gut halten :)

zeckensack
2003-09-30, 16:36:26
Original geschrieben von Demirug
Was hast du den gemacht?

Einfach eine Reihe von Texturereads hintereinader die immer das Ergebniss des vorhergehenden benutzten?Ja. Ich wollte das ganze eben 'pur' messen.
Daß ich andere Operationen sozusagen 'for free' noch dazu bekommen hätte, und das ganze auch nicht gerade 'real world' ist, war mir bewußt. Für die Messung ist das nicht wichtig.
Ich meinte das ganze aber sowieso eher in der Richtung das man mit dieser Technik schnell an das Limit von 4 dependent reads kommt. Oh ja, sehr schnell.
Irgendwie verstehe ich da das Problem aber nicht. Dave höchstselbst ist doch so stolz auf die Fähigkeiten der NV3x-ALUs (siehe Sin/Cos-Blubber). Dann rechnet man das halt aus.
Wenn das alles so toll funktioniert, warum soll man dann noch dependency levels für lookups verballern?
*schulterzuck*

Irgendwie redet sich der Mann um Kopf und Kragen, IMO.
Dependent reads sind nun mal die einzige relevante Schwäche der R300-Shader, und auch öffentlich dokumentiert. Wenn er nicht darauf anspielt, worauf denn dann?

Wenn er Stencil/Z fillrate meint, dann wäre das doch ziemlich an der Thematik vorbei.

Demirug
2003-09-30, 16:48:22
Original geschrieben von zeckensack
Ja. Ich wollte das ganze eben 'pur' messen.
Daß ich andere Operationen sozusagen 'for free' noch dazu bekommen hätte, und das ganze auch nicht gerade 'real world' ist, war mir bewußt. Für die Messung ist das nicht wichtig.

Unter diesem Umständen sind die Dependet Reads wirklich nicht so teuer. Wenn ich das ganze richtig verstanden haben werden die Reads teuer wenn die einzelnen Phase unausgeliechen sind. Also in der ersten Phase ein Read gefolgt von vielen Arithmetikanweisungen und dann nochmal 3 dependent reads mit nur jweils einer Arithmetikanweisungen

Oh ja, sehr schnell.
Irgendwie verstehe ich da das Problem aber nicht. Dave höchstselbst ist doch so stolz auf die Fähigkeiten der NV3x-ALUs (siehe Sin/Cos-Blubber). Dann rechnet man das halt aus.
Wenn das alles so toll funktioniert, warum soll man dann noch dependency levels für lookups verballern?
*schulterzuck*

Irgendwie redet sich der Mann um Kopf und Kragen, IMO.
Dependent reads sind nun mal die einzige relevante Schwäche der R300-Shader, und auch öffentlich dokumentiert. Wenn er nicht darauf anspielt, worauf denn dann?

Bei den NV3X kannst du dependency levels verballern wie du lustig bist da gibt es kein Limit. Witzig ist allerdings das ATI zum Beispiel für Sinus und Cosinus lookups als gute Lösung sieht.

Wenn er Stencil/Z fillrate meint, dann wäre das doch ziemlich an der Thematik vorbei.

Es ging wohl schon um Shaderleistung.

zeckensack
2003-09-30, 17:01:58
Original geschrieben von Demirug
Bei den NV3X kannst du dependency levels verballern wie du lustig bist da gibt es kein Limit. Witzig ist allerdings das ATI zum Beispiel für Sinus und Cosinus lookups als gute Lösung sieht.Ist klar. Ich frage mich nur, was für NV3x jetzt besser sein soll:
a)Sinus/Cosinus ausrechnen auf der tollen, leistungsfähigen ALU
b)Sinus/Cosiuns doch lieber aus einer LUT holen, weil ... *hust*arithmetiklangsamist*hust*

Beides gleichzeitig kann ja wohl nicht angehen :|
Und genau da fehlt auch im Interview die klare Linie.
Er widerspricht sich selbst. Er fordert NV3x-optimierten Shadercode. Dann braucht er aber nicht mit ALU-Details anzugeben, die bei 'korrekter' Optimierung sowieso nicht zum Tragen kommen.

Demirug
2003-09-30, 17:11:42
Original geschrieben von zeckensack
Ist klar. Ich frage mich nur, was für NV3x jetzt besser sein soll:
a)Sinus/Cosinus ausrechnen auf der tollen, leistungsfähigen ALU
b)Sinus/Cosiuns doch lieber aus einer LUT holen, weil ... *hust*arithmetiklangsamist*hust*

Beides gleichzeitig kann ja wohl nicht angehen :|
Und genau da fehlt auch im Interview die klare Linie.
Er widerspricht sich selbst. Er fordert NV3x-optimierten Shadercode. Dann braucht er aber nicht mit ALU-Details anzugeben, die bei 'korrekter' Optimierung sowieso nicht zum Tragen kommen.

Hehe ist doch ganz einfach. Komplexe Berechnungen sollen durch LUT ersetzt werden. Sinus/Cosinus sind auf einem NV30 keine komplexen Berechnungen.

aths
2003-09-30, 17:12:22
Original geschrieben von Demirug
32 Bit sind mir aber trotzdem lieber. Allerdings ist derzeit der Preis dafür zu hoch. In einem Punkt stimme ich Dr. D. K. in der Tat zu: 16 Bit für Farben und 32 Bit für Geometrie, demzufolge ein Misch aus 16 und 32 Bit, halte auch ich für sinnvoller als eine durchgehende 24-Bit-Pipe. Gut, ATIs Farb-Berechnungen sind genauer. Aber 24 Bit sind noch keine 32, 32 Bit ("single") ist ein sehr bekanntes Format, wenn die Pixelshader-Pipe das auch "fressen" kann, ist das imo vorteilhaft.

"Mixed Precisision" Shader sind sicherlich aufwändiger zu erstellen, das ist natürlich eine Kehrseite.

Aaaaber, Vertex Shader 3.0 wird ja TMUs kriegen (endlich, btw!!) Vertex Shader arbeiten mit single, also 32 Bit. ATIs 24-Bit-Pipe scheint mir eine Übergangslösung zu sein, sie werden wohl eine (dann aber durchgehende) 32-Bit-Pipe mit der nächsten Generation anbieten.

Demirug
2003-09-30, 17:30:54
Original geschrieben von aths
In einem Punkt stimme ich Dr. D. K. in der Tat zu: 16 Bit für Farben und 32 Bit für Geometrie, demzufolge ein Misch aus 16 und 32 Bit, halte auch ich für sinnvoller als eine durchgehende 24-Bit-Pipe. Gut, ATIs Farb-Berechnungen sind genauer. Aber 24 Bit sind noch keine 32, 32 Bit ("single") ist ein sehr bekanntes Format, wenn die Pixelshader-Pipe das auch "fressen" kann, ist das imo vorteilhaft.

Ich hätte auch noch gerne das Integerformat. Das Int12 Format ist wenn es um reine Farbberechngen geht und man kein HDR braucht oft besser als FP16 und beim NV40 wurde ja schon von einem Int16 Format gemunkelt.

Vorallem könnte man die FP32 Werte die hinten aus der Pipeline rauskommen vorne wieder einspeisen. Könnte für Partikeleffekte interesant werden.

"Mixed Precisision" Shader sind sicherlich aufwändiger zu erstellen, das ist natürlich eine Kehrseite.

Ja, aber wenn man sich selbst ein paar Regeln aufstellt (Farben = FP16 ; Vektoren = FP32) ist das noch im grünen Bereich. Beim Programmieren für eine CPU überlegt man sich ja auch welcher Datetype am besten passt.

del_4901
2003-09-30, 17:34:15
Die Vertexshader waren doch schon immer FP32, oder irr ich da?

zeckensack
2003-09-30, 17:38:04
Original geschrieben von AlphaTier
Die Vertexshader waren doch schon immer FP32, oder irr ich da? Du irrst nicht ;)

aths
2003-09-30, 17:41:56
Original geschrieben von AlphaTier
Die Vertexshader waren doch schon immer FP32, oder irr ich da? Die sind, genau wie DX7 T&L, durchgehend 32-bittig ("single precision" floating point.)

Demirug
2003-09-30, 17:44:11
Original geschrieben von aths
Die sind, genau wie DX7 T&L, durchgehend 32-bittig ("single precision" floating point.)

Aber davor gabe es die dunkle Zeit in der jeder gemacht hat was er wollte. :D

Quasar
2003-09-30, 17:54:14
Original geschrieben von Demirug
Aber davor gabe es die dunkle Zeit in der jeder gemacht hat was er wollte. :D

DX-Prediger, ick hör' dir trapsen.... :D

Demirug
2003-09-30, 18:00:06
Original geschrieben von Quasar
DX-Prediger, ick hör' dir trapsen.... :D

In diesem Fall nicht. Das war teilweise so exotisch das hätte man nie unter einen Hut gebracht.

Exxtreme
2003-09-30, 18:00:39
Original geschrieben von Demirug
Aber davor gabe es die dunkle Zeit in der jeder gemacht hat was er wollte. :D
Eieiei. :|

Zecki sagte schon mal, daß Micro$~1 nicht in der Lage ist, ein vernünftiges API zu entwerfen.

Wenn sie solche "undefinierten" Dinge zulassen, dann taugt's IMHO wirklich nicht sehr viel.

del_4901
2003-09-30, 18:02:22
Original geschrieben von zeckensack
Du irrst nicht ;)

Also spielte Demi darauf an im FragmentProzessor für die Koordinaten XYZW Fp32 zu nehmen und für die RGBA Farben FP16? seh ich das richtig?

Demirug
2003-09-30, 18:02:22
Original geschrieben von Exxtreme
Eieiei. :|

Zecki sagte schon mal, daß Micro$~1 nicht in der Lage ist, ein vernünftiges API zu entwerfen.

Wenn sie solche "undefinierten" Dinge zulassen, dann taugt's IMHO wirklich nicht sehr viel.

Vor DX7 gabe es in DX ja gar kein Hardware vertex processing. Ich bezog mich da auf einige properitäre Lösungen.

Demirug
2003-09-30, 18:04:37
Original geschrieben von AlphaTier
Also spielte Demi darauf an im FragmentProzessor für die Koordinaten XYZW Fp32 zu nehmen und für die RGBA Farben FP16? seh ich das richtig?

Im Prinzip ja. Wobei natülich ausnahmen die Regel bestätigen können.

aths
2003-09-30, 18:05:03
Original geschrieben von Demirug
Ich hätte auch noch gerne das Integerformat. Das Int12 Format ist wenn es um reine Farbberechngen geht und man kein HDR braucht oft besser als FP16 und beim NV40 wurde ja schon von einem Int16 Format gemunkelt.Ach, Int12... Int12 ist das, was ich mir tierisch schon bei GF3, spätestens GF4 gewünscht hätte. Inzwischen halte ich Int12 langsam für überholt.
Original geschrieben von Demirug
Vorallem könnte man die FP32 Werte die hinten aus der Pipeline rauskommen vorne wieder einspeisen. Könnte für Partikeleffekte interesant werden.24 Bit FP ist eben ein "Sonderformat".
Original geschrieben von Demirug
Ja, aber wenn man sich selbst ein paar Regeln aufstellt (Farben = FP16 ; Vektoren = FP32) ist das noch im grünen Bereich. Beim Programmieren für eine CPU überlegt man sich ja auch welcher Datetype am besten passt. Auf der anderen Seite, wenn der Transistorcount das hergibt (bzw. das Registerfile http://www.aths.net/files/smilies/lol.gif) wäre eine durchgehende 32-Bit-Pipe ja auch ganz schön :)

zeckensack
2003-09-30, 18:05:56
Ich glaube Demirug meinte eher sowas wie zB 12.4 fixed point =)
MOVQ mm0,[ESI] ;get x and y
PFMUL mm0,[const16f] ;prescale
PF2ID mm0,mm0 ;convert to integer
PSLLD mm0,16 ;remove high bits (Quake 2 bogus)
PSRAD mm0,16
PI2FD mm0,mm0 ;convert back to float
MOVQ [EDI+o_coords],mm0 ;write out x|y coordinates
:schlag:

IMO auch nicht weiter tragisch, da man ja keine Vertex-Daten nahe an der CPU parken konnte. Das wurde erst mit HW T&L notwendig. Bis dahin haben eben die Treiber die Konvertierung gemacht.

Demirug
2003-09-30, 18:09:51
Original geschrieben von zeckensack
Ich glaube Demirug meinte eher sowas wie zB 12.4 fixed point =)
MOVQ mm0,[ESI] ;get x and y
PFMUL mm0,[const16f] ;prescale
PF2ID mm0,mm0 ;convert to integer
PSLLD mm0,16 ;remove high bits (Quake 2 bogus)
PSRAD mm0,16
PI2FD mm0,mm0 ;convert back to float
MOVQ [EDI+o_coords],mm0 ;write out x|y coordinates
:schlag:

IMO auch nicht weiter tragisch, da man ja keine Vertex-Daten nahe an der CPU parken konnte. Das wurde erst mit HW T&L notwendig. Bis dahin haben eben die Treiber die Konvertierung gemacht.

Ja genau sowas und es gab Grafik-Hardware die in diesem Format gearbeitet hat. (zumindestens auf dem Papier)

del_4901
2003-09-30, 18:10:13
Original geschrieben von zeckensack
Ich glaube Demirug meinte eher sowas wie zB 12.4 fixed point =)
MOVQ mm0,[ESI] ;get x and y
PFMUL mm0,[const16f] ;prescale
PF2ID mm0,mm0 ;convert to integer
PSLLD mm0,16 ;remove high bits (Quake 2 bogus)
PSRAD mm0,16
PI2FD mm0,mm0 ;convert back to float
MOVQ [EDI+o_coords],mm0 ;write out x|y coordinates
:schlag:

IMO auch nicht weiter tragisch, da man ja keine Vertex-Daten nahe an der CPU parken konnte. Das wurde erst mit HW T&L notwendig. Bis dahin haben eben die Treiber die Konvertierung gemacht.

Ihr ASM Kackfreaks, das braucht immer soviel Zeit zum Reindenken. In Zeiten von HLSL sollte sowas verboten werden ;) !!!

aths
2003-09-30, 18:12:52
Zecki, könntest du sowas auch in C++ schreiben? Ich kann so schlecht ASM lesen http://www.aths.net/files/smilies/s.gif

zeckensack
2003-09-30, 18:14:08
Original geschrieben von AlphaTier
Ihr ASM Kackfreaks, das braucht immer soviel Zeit zum Reindenken. In Zeiten von HLSL sollte sowas verboten werden ;) !!! Den 'HLSL'-Code dazu habe ich halt nicht griffbereit gehabt ;)

Btw ist das ASM für 'ne CPU. Die passende HLSL wäre in dem Fall C++.

zeckensack
2003-09-30, 18:16:07
Original geschrieben von aths
Zecki, könntest du sowas auch in C++ schreiben? Ich kann so schlecht ASM lesen http://www.aths.net/files/smilies/s.gif Na gut ?-)
dest->x=float(uint(16.0f*src->x)&0xFFFF);
dest->y=float(uint(16.0f*src->y)&0xFFFF);
Müsste stimmen :grübel:

Demirug
2003-09-30, 18:18:44
Original geschrieben von zeckensack
Den 'HLSL'-Code dazu habe ich halt nicht griffbereit gehabt ;)

Btw ist das ASM für 'ne CPU. Die passende HLSL wäre in dem Fall C++.

C bitte.

Zu einer objekt orientierten Shadersprache konnte man sich ja nicht durchringen.

aths
2003-09-30, 18:19:18
Danke, zecki.

Original geschrieben von Demirug
C bitte.

Zu einer objekt orientierten Shadersprache konnte man sich ja nicht durchringen. Ich hasse C.

Hmmm, für Material-Shader müsste eine OOP-HLSL doch eigentlich ganz gut geeignet sein...

del_4901
2003-09-30, 18:20:33
Original geschrieben von zeckensack
Na gut ?-)
dest->x=float(uint(16.0f*src->x)&0xFFFF);
dest->y=float(uint(16.0f*src->y)&0xFFFF);
Müsste stimmen :grübel:

gut, wenn du jetzt noch die Variablen deklariern würdest, könnte das mein Kopfinterner Compiler sogar interpretiern. :D

Demirug
2003-09-30, 18:25:11
Original geschrieben von aths
Ich hasse C.

Hmmm, für Material-Shader müsste eine OOP-HLSL doch eigentlich ganz gut geeignet sein...

OOSL find ich gut. ;)

Ist aber durchaus kompliziert gerade wenn man dann mit so Sachen wie virtuellen Methode anfängt.

del_4901
2003-09-30, 18:27:13
Original geschrieben von Demirug
OOSL find ich gut. ;)

Ist aber durchaus kompliziert gerade wenn man dann mit so Sachen wie virtuellen Methode anfängt.
Das klingt schwer nach Info3 *würg* ;)

Ailuros
2003-09-30, 18:59:01
Ich hab mir zwar die drei Seiten hier nicht durchgelesen, aber das Interview schon und hab komischerweise keine wesentlichen Einsprueche als Laie dagegen.