D3D: Optimieren für einen IHV

[nggalai]

Hi there,

losgetreten wurde die Diskussion hier (http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&postid=401121#post401121) durch mein folgendes Posting:Daniel von Epic hatte dazu mal was zu sagen--er meinte, dass es unter D3D fast unmöglich ist, auf einen speziellen IHV zu "optimieren". Bei OpenGL sieht das natürlich ein wenig anders aus, aber bei D3D kann ich mir echt auch nicht vorstellen, wie man denn da gross an den Spezifikationen vorbeischreiben kann--und weshalb man das als Entwickler machen sollte, wenn man's doch auf Biegen und Brechen probiert.Dann kamen noch ein paar Postings zum Thema.

Wie ich da auch schrieb, hab' ich da mangels Programmiererfahrung in D3D mehr geraten als sonst was. ;) Daher die Frage: in welchem Umfang kann man unter D3D für einen spezifischen IHV "optimieren"?

ta,
-Sascha.rb

[cyjoe]

ähh, IHV???

[nggalai]

Originally posted by cyjoe
ähh, IHV??? IHV = Independent Hardware Vendor.

i.e. Grafikchipsethersteller. ;)

ta,
-Sascha.rb

[Demirug]

Man kan durchaus auch mit DX spezifischen IHV optimierungen vornehmen. Diese optimierungen fallen im wesentlichen in zwei Bereiche und sind auch von der DX Version abhängig.

1. Optimierungen durch Ausnutzung von Features

Bei DX8 wäre das zum Beispiel die Benutzung von PS 1.4 auf einer R8500. Die DX7 Fragmentpipeline hat ebenfalls viel raum für Experimente das man dort den IHVs sehr viel Spielraum gelassen hat.

2. Optimierung durch Ausnutzung von Hardware/Treiberspezifischen verhalten

Trotz aller Bemühungen von MS läst das DX DDK den Hersteller noch etwas Spielraum in der Auslegung der Vorgaben. Diese Lücken sind allerdings inzwischen sehr klein geworden und bitten dehalb kaum noch Raum.

Es gibt aber denoch Gründe warum viele Programme auf NVIDIA Hardware besser laufen und deshalb den eindruck erwecken das es mit DX doch möglich wäre massive hardwarespezifische optimierungen vorzunehmen.

1. NVIDIA stellt bei vielen Entwickler die Hauptentwicklungsplatform dar. Stellt man nun im verlauf des Projekts fest das Features auf anderen Karten nicht funktionierenwird eben mal schnell ein Fallback geschrieben. Diese Fallbacks sind aber meistens leider nicht ganz so performant.

2. NVIDIA ist sehr bemüht um die Entwickler und erhält aufgrund dieser Beziehungen auch oft sehr früh zugang zu den neuen Spielen. Das gibt NVIDIA die Möglichkeit frühzeitig die Steuersequenzen zu analysieren und falls möglich den Treiber zu optimieren.

die anderen Gründen die ich noch aufführen könnte gehören Teilweise ins Reich der Spekulation und deswegen verzichte ich hier darauf.

[Quasar]

Man könnte doch bestimmt auch mal einen Blick in gewisse Designguides werfen, wo drinsteht, was auf dem entsprechenden Chip unbedingt zu vermeiden ist, weil's stark Performance kostet, obwohl DX es zuliesse.

Ich denke, besonders bei Games, die als Launch-Demo verwendet werden, gibt's da sicherlich auch ein paar "Anpassungen", damit z.B. die chipinternen Caches optimal ausgenutzt werden. Ob diese Anpassungen nun "versteckt" im Treiber liegen, oder halbwegs "offen" in der Game-Engine ist nur eine Frage des Geschmacks...

[Demirug]

Quasar,

Designguides? naja es gibt von NVIDIA ein paar dokumente was man unter DX vermeiden sollte und was die performance steigert. Allerdings sind diese sache mehr oder minder allgemein für DX bzw. für die Echtzeit 3d darstellung gültig. Aber ansonsten ist da doch recht tote hose. Von NVIDIA gibt es noch einen Chipprofiler der zum suchen von Performancen engpässen geeignet ist. Allerdings halt nur bei NVIDIA chips. Wenn man natürlich nun die Daten so modifiziert das sie auf einem NV-Chip möglichst ausgeglichen durchlaufen gibt es bei anderen Chips durchaus wieder andere engstellen.

[zeckensack]

Ich habe das im Graka-Forum ähnlich geschrieben:

Gibt's nicht noch sowas wie 'false assumptions' zu berücksichtigen???

zB D3D meldet Pixel Shader >=v1.1

-> Falsche Annahme, daß Karte=Geforce 3
-> Falsche Annahme, daß alle anderen Gf3-Features unterstützt und mindestens gleichschnell wie auf Gf3 sind (Table Fog, Shadow Buffers)

???

[Demirug]

zeckensack,

aufgrund eines gemeldeten Feature auf andere zu schliessen ist ein verdammt schlechter still und sowas hat nichts mit optimierung auf eine Karte zu tun sonder läuft einfach jeder DX Regel entgegen. Wenn man wissen möchte was für eine Karte man hat nimmt man besser die Device und Vendor ID.

Was nun den Speed angeht. IMO ist es problemmatisch eine Engine auf irgendwelche Annahme über den Speed von Features aufzubauen. Bei jeder neuen Karte sind dann die Problem vorprogramiert da man es mit einem völlig unbekannten Performance profile zu tun hat. und wenn man dann aufgrund irgendwelcher Caps ein bekanntes Profile wählt hat man wirklich mist gebaut.

[nggalai]

Hi Demiurg,

ui, dank dir. :) An Nummer 1 hatte ich gedacht, und Nummer 2 ähnlich eingeschätzt.

Noch zu dem hier:Originally posted by Demirug
aufgrund eines gemeldeten Feature auf andere zu schliessen ist ein verdammt schlechter still und sowas hat nichts mit optimierung auf eine Karte zu tun sonder läuft einfach jeder DX Regel entgegen. Wenn man wissen möchte was für eine Karte man hat nimmt man besser die Device und Vendor ID.Der Vollständigkeit halber hier Z-Bags Posting ausm anderen Thread:Originally posted by Zeckensack
Wenn man's richtig macht, dann ist das IMO unmöglich.

Man kann es aber auch falsch machen :grhargh:

Willkommen im Reich der dämlichen Schlußfolgerungen:

Abfrage der D3D-Caps ergibt: Karte beherrscht Pixel Shader >=1.1

Aha, ist also eine Geforce 3, da hat man dann also auch Hardware-Support für Shadow Buffers, kann performant den Z-Buffer locken, bis zu vier Texturen pro Pass für nicht-PS-Sachen nutzen und selbstredend hat man Table Fog zur Verfügung ...

Wer findet den Fehler?;)

ta,
-Sascha.rb

[Exxtreme]

Originally posted by Demirug
zeckensack,

aufgrund eines gemeldeten Feature auf andere zu schliessen ist ein verdammt schlechter still und sowas hat nichts mit optimierung auf eine Karte zu tun sonder läuft einfach jeder DX Regel entgegen.
Klar ist es ein schlechter Stil. Nur Wenn der Treiber diese Pixelshaderversion meldet und bekannt ist, daß nur die GF3 sowas meldet dann ist es trotzdem... logisch. Ich frage mich sowieso, warum man unbedingt den Grafikchip wissen will. Ich dachte, daß man unter DX für die (das?) API programmiert und nicht für Grafikchips.
:bonk:

Gruß
Alex

[zeckensack]

Originally posted by Demirug
zeckensack,

aufgrund eines gemeldeten Feature auf andere zu schliessen ist ein verdammt schlechter still und sowas hat nichts mit optimierung auf eine Karte zu tun sonder läuft einfach jeder DX Regel entgegen. Wenn man wissen möchte was für eine Karte man hat nimmt man besser die Device und Vendor ID. Natürlich volle Zustimmung. Aber sowas kommt doch vor, oder???
Verbuggte Spiele gibt's immer wieder, wenn's schonmal auf jedem System und auf jeder Graka knirscht, dann kann ich doch auch vermuten, daß auch bei der Programmierung des Renderers geschlampt wurde. *eg*

GTA3 fällt mir jetzt ganz zufällig ein :stareup:

Oder sogar Max Payne, das jetzt nicht wirklich schlecht läuft, aber laut DX8.1 SDK Debug Logs ein paar wirklich dumme Sachen macht (gelockten Vertex Buffer ständig nochmal locken, du erinnerst dich vielleicht, damals ging's um den Splash Screen 'Bug' im 3DMark und du hast mir den Tip mit dem SDK Logging Tool gegeben).

Ich will eigentlich nur erreichen, daß man gewisse Programme, die quasi bewiesenermaßen schlecht geschrieben sind, aus der Optimierungsdebatte raushält. Man weiß dann zwar nicht, welche Fehler im verborgenen liegen, und ob tatsächlich an DX vorbeigeproggt wurde. Aber wenn offensichtliche Fehler da sind, kann man dem Team ruhig auch tiefgehenderen schlechten Stil und Unerfahrenheit vorwerfen. IMHO. ;)

Bei Lizenz-Engines für Direct3D kommt sowas überhaupt nicht vor (UT 1 build 430, Netimmerse, blablub). Ich unterstelle einfach mal, daß man sich hier mehr Mühe gibt, weil der Kunde ja nicht 'nur' der Endverbraucher ist, sondern eine andere Firma.

Was nun den Speed angeht. IMO ist es problemmatisch eine Engine auf irgendwelche Annahme über den Speed von Features aufzubauen. Bei jeder neuen Karte sind dann die Problem vorprogramiert da man es mit einem völlig unbekannten Performance profile zu tun hat. und wenn man dann aufgrund irgendwelcher Caps ein bekanntes Profile wählt hat man wirklich mist gebaut. Ich weiß nicht wie representativ das ganze ist, aber ich bin häufig im OGL-Forum unterwegs, wo die ganzen aufstrebenden Devs rumhängen und was von ihrer neuen 'Engine' erzählen. Viele von denen bauen tatsächlich totalen Mist, das kann man ganz deutlich an den Postings erkennen. ("How many register combiners are available on i815 integrated graphics? ...")

D3D != OGL, ich weiß, aber manche Sachen stecken so tief in den Köpfen fest, daß solche falschen Annahmen eben passieren. Die Masse der Hobbyisten hat eine Gf2MX und nichts anderes, auch nicht zum Testen. Aus Hobbyisten werden dann irgendwann Profis, und dann haben wir den Salat. Vor allem bei der aktuellen Lage der Spieleindustrie ;(

[Salvee]

Originally posted by Demirug
die anderen Gründen die ich noch aufführen könnte gehören Teilweise ins Reich der Spekulation und deswegen verzichte ich hier darauf.

Schade, würde mich echt mal interessieren, Spekulationen diesbezüglich von jemandem zu lesen, der Praxis und Ahnung hat.
Vielleicht im Spekulationsforum ? :)

[Demirug]

Originally posted by Exxtreme

Klar ist es ein schlechter Stil. Nur Wenn der Treiber diese Pixelshaderversion meldet und bekannt ist, daß nur die GF3 sowas meldet dann ist es trotzdem... logisch. Ich frage mich sowieso, warum man unbedingt den Grafikchip wissen will. Ich dachte, daß man unter DX für die (das?) API programmiert und nicht für Grafikchips.
:bonk:

Gruß
Alex

Was das logisch angeht. Im Moment ja aber wer sagt mir das es nicht von jemanden in Zukunft einen Chip gibt der ebenfalls diese PS Version als Max meldet und schon habe ich mit solchen Karte probleme.

Primär programmiert man natürlich für die API und nicht für die Karte/Chip. DX meldet aber nur ob ein Feature verfügbar ist oder nicht. Über die Performance wird aber keinen Aussage getroffen (was auch schwer möglich ist). Jemand mit Ahnung könnte jetzt natürlich die Verwendung von Features selbst abschalten (OK die Engine/Game muss es erlauben) aber die weniger technisch begabten spieler wollen einfach nur spielen und deswegen legt man soweit möglich für jede Karte entsprechende Profile an die entsprechende Featureselects im Bezug auf die Engine enthalten. Die Auswahl dieser Profile sollte aber auf jeden fall über die Device/Vendor ID erfolgen und nicht in abhängigkeit von Caps.

[Demirug]

zeckensack,

wenn ein Spiel auf keiner Karte ordentlich läuft brauchen wir nicht darüber zu streiten wer da mist gebaut hat.

An die Max Payne sache erinnere ich mich. Wobei dieser "Fehler" in der Regel keine allzu grosse Auswirkung hat. Ich möchte auch nicht unbediengt darüber urteilen ohne den Entwickler dazu gehört zu haben. Es könnte durchaus sein das die DX korrekte Lösung am Ende aber mehr aufwand für die CPU bedeutet hätte.

Ja Lizenz engines sind in der regel besser, das hängt aber auch damit zusammen das sie einfach mehr genutzt werden. da fallen Fehler eher auf und können beseitigt werden.

Im DX Bereich gibt es auch genügend Leute bei denen mann sich fragt was daraus werden soll. Es ist halt teilweise schwer zu sagen wie lange sich diese Person schon mit der sache beschäftigt.

Zudem denke ich das die Lage nicht ganz so schlimm ist. Jemanden der ohne "Erfahrung" zu einer Firma kommt wird man nicht gleich zum Leadprogrammer für die Engine machen. Bei einer Neugründung ist sowas natürlich möglich aber ob das Teil dann überhaupt jemals auf den Markt kommt ist ungewiss.

[Pussycat]

Originally posted by zeckensack

Gibt's nicht noch sowas wie 'false assumptions' zu berücksichtigen???

zB D3D meldet Pixel Shader >=v1.1

-> Falsche Annahme, daß Karte=Geforce 3
-> Falsche Annahme, daß alle anderen Gf3-Features unterstützt und mindestens gleichschnell wie auf Gf3 sind (Table Fog, Shadow Buffers)

???

Gabs doch mal! Bei einem Spiel, dass annahm das nur karten mit T+L (DX7 t+l) bump mapping konnten. Und Als der Kyro kam, funktionierte der Trick nicht mehr.

Welches Spiel war das ???

[Xmas]

Originally posted by Pussycat
Gabs doch mal! Bei einem Spiel, dass annahm das nur karten mit T+L (DX7 t+l) bump mapping konnten. Und Als der Kyro kam, funktionierte der Trick nicht mehr.

Welches Spiel war das ???
Giants?

[nggalai]

Originally posted by Xmas

Giants? Gut möglich--gab doch einen separaten Kyro-Patch, womit das Bump Mapping aktiviert werden musste.

ta,
-Sascha.rb

[Pussycat]

Stimmt, Giants wars.

Da hat man also ein Beispiel der (hat feature a -> hat feature b) - Logik

[Obligaron]

will mich jetzt auch nochmal was sagen :)

Optimierungen:
1, Wenn man die Möglichkeiten hat einen Effekt mit unterschiedlichen Mitteln zu realisieren und sieht das Möglichkeit1 schneller auf HerstellerX-Karten läuft und Möglichkeit2 schneller auf HerstellerY-Karten läuft, dann kann man insofern doch optemieren

2, Wenn man sieht ein schoener Effekt auf der Karte von HerstellerX zu langsamm ist, aber (sofern man sich die mühe macht und das überhaupt bei der dieser Karte überprüft) bei HerstellerY gut läuft und man sich trotzdem gegen diesen Effekt entscheidet, weil HerstellerX verbreiteter ist


Programmierung (auf nur einer "Plattform"):
1, Wenn man die Engine immer nur auf einer Karte testet und man sieht das der eine Effekt zu langsamm ist dann lässt man ihn halt einfach raus (obwohl er bei einer anderen nicht getesteten Karte gut/mit genügender Performance läuft)

2, Wenn man immer nur auf einer Karte/Treiber programmiert dann optimiert ja auch automatisch, da man sich/die Engine an die "eigenarten" der Karte anpasst(man will ja das seine Engine gut läuft).


P.S: Das ist alles nur meine persönliche Meinung/Vermutungen, da ich selbst (noch?) keine Grafikporgrammierung mache kenne ich mich auch nicht so gut aus, aber alles oben kommt mir logisch vor. Bitte korregiert mich, wenn ich irgendwo falsch liege. :)

MfG,
Obligaron

[Obligaron]

dumme frage, stimmt ihr mir bei meinem letzten posting hier alle zu oder weso schreibt keiner mehr was? *grübel*

MfG,
Obligaron

[zeckensack]

Originally posted by Obligaron
dumme frage, stimmt ihr mir bei meinem letzten posting hier alle zu oder weso schreibt keiner mehr was? *grübel*

MfG,
Obligaron Sieht gut aus :)

[Pussycat]

Wenn du unbedingt eine Reaktion willst, musst du ATI / NV / AMD beleidigen :D

[Obligaron]

lol :D