EMBM bei ATI und Matrox (split aus E³ H-L²)

[Demirug]

Original geschrieben von MadManniMan
3DFX hat de facto die VS und PS 1.0 Standards gesetzt, aber ich absolut der Meinung, die "Charisma"-Engine hätte für VS 1.0 gereicht. Bei den PS solls nicht sonderlich viel gewesen sein.

Nein Charisma reicht nicht für einen 1.0 VS. Mann kann zwar relative viel damit anstellen aber wir haben es hier mit dem Problem der mangelenden Flexibilität zu tun.

Bei der Pixelpipeline fehlt erst mal eine Texture pro Pass und die Möglichkeiten des dependent Texturereads sind defakto auch nicht vorhanden.

[zeckensack]

Original geschrieben von Demirug
Bei der Pixelpipeline fehlt erst mal eine Texture pro Pass und die Möglichkeiten des dependent Texturereads sind defakto auch nicht vorhanden. Es hat mich immer maßlos aufgeregt, daß der Chip zwar EMBM kann, aber keine DRs. Letztere sind eine einfachere Untermenge von EMBM.

:krank:

[ow]

Original geschrieben von zeckensack
Es hat mich immer maßlos aufgeregt, daß der Chip zwar EMBM kann, aber keine DRs. Letztere sind eine einfachere Untermenge von EMBM.

:krank:


Wenn DRs eine einfachere Untermenge von EMBM sind, könnte man dann nicht die EMBM-'Einheit' zu DRs missbrauchen?

[zeckensack]

Original geschrieben von ow
Wenn DRs eine einfachere Untermenge von EMBM sind, könnte man dann nicht die EMBM-'Einheit' zu DRs missbrauchen? Nein.

EMBM belegt zwei Textureinheiten und läuft so ab:
1)Man nehme 'normal' ein Sample von der ersten Textureinheit,
2)dann wird dieses Sample auf die Texturkoordinaten der zweiten Einheit aufaddiert,
3)dann wird mit diesen veränderten Koordinaten von der zweiten Einheit gesampelt.

In vielen Fällen würde es mir schon helfen, wenn ich die Addition abstellen könnte. In anderen Fällen will ich überhaupt nicht von einer Bumpmap sampeln, sondern direkt die Farbe die ich aktuell vorliegen habe als Texturkoordinate benutzen.

Beides wäre weniger Arbeit, aber ich kann es nicht machen, weil EMBM eben zu starr spezifiziert ist.

[Demirug]

Original geschrieben von zeckensack
Nein.

EMBM belegt zwei Textureinheiten und läuft so ab:
1)Man nehme 'normal' ein Sample von der ersten Textureinheit,
2)dann wird dieses Sample auf die Texturkoordinaten der zweiten Einheit aufaddiert,
3)dann wird mit diesen veränderten Koordinaten von der zweiten Einheit gesampelt.

In vielen Fällen würde es mir schon helfen, wenn ich die Addition abstellen könnte. In anderen Fällen will ich überhaupt nicht von einer Bumpmap sampeln, sondern direkt die Farbe die ich aktuell vorliegen habe als Texturkoordinate benutzen.

Beides wäre weniger Arbeit, aber ich kann es nicht machen, weil EMBM eben zu starr spezifiziert ist.

Wenn ich genau darüber nachdenke konnte man die Addition doch unterdrücken.

Nach dem sampeln der Bumpmap kommt ja die folgende Berechung zum Einsatz.

Du' = Du*M00+Dv*M10
Dv' = Du*M01+Dv*M11

Setzt man die Matrix M nun auf

1 0
0 1

ist die Addition nicht mehr vorhanden.

[Quasar]

Vielleicht hat Demirug ja schon dasselbe gesagt (verstanden hab ich's nicht), aber kann man die Addition nicht umgehen, indem man schlicht "null" addiert?

Ergebnis dasselbe, Performance leider nichts gespart.

[Demirug]

Original geschrieben von Quasar
Vielleicht hat Demirug ja schon dasselbe gesagt (verstanden hab ich's nicht), aber kann man die Addition nicht umgehen, indem man schlicht "null" addiert?

Ergebnis dasselbe, Performance leider nichts gespart.

Performance sollte es eigentlich nicht kosten weil diese Recheneinheit fest eingebaut ist. AFAIK sogar nur zwischen 2 bestimmten TMUs (da könnte ich mich aber täuschen).

Einfach null addiren geht nicht weil ja die Werte welche aus der Texture (Bumpmap) kommen addiert werden und nicht von aussen vorgebene werden. Aber wie ich oben schon aufgeführt habe müsste sich die Matrix dafür missbrauchen lassen.

[zeckensack]

Öhm, sorry, war meinerseits ein Schnellschuß.

Die Addition kann man am einfachsten ausschalten, indem man auf der zweiten EMBM-Einheit einfach die Texturkoordinaten auf Null setzt.

Aber den simplen dependant read kriegt man damit trotzdem nicht hin. Das Problem ist einfach, daß das Sample aus der ersten Einheit meine nächste Texturkoordinate bestimmt, und nicht irgendeine Farbberechnung, die ich vorher gemacht habe. Das kriegt man nicht weg. Man kann dann eben nur pro Vertex an den Texturkoordinaten für die erste EMBM-Einheit spielen, aber eben nicht pro Pixel in diese Berechnung eingreifen. Dann kann ich mir das ganze auch gleich komplett sparen.

Lange Rede, kurzer Sinn,
EMBM kann man derzeit nur für EMBM einsetzen, und für nichts anderes :(

[Quasar]

Original geschrieben von zeckensack
[...]
Die Addition kann man am einfachsten ausschalten, indem man auf der zweiten EMBM-Einheit einfach die Texturkoordinaten auf Null setzt.

Das in etwa meinte ich mit meinem Post.

Original geschrieben von zeckensack
Lange Rede, kurzer Sinn,
EMBM kann man derzeit nur für EMBM einsetzen, und für nichts anderes :(

Weisst du zufällig, auch wenn es völlig OT ist, wie sich die Matrox G4xx/550 hier verhält? IIRC melden zumindest die D3D-Treiber 3 Textureinheiten auf der Pipeline, wovon eine eigentlich die EMBM-Einheit sein sollte.

Kann man die noch für etwas anderes gebrauchen?

[Demirug]

Original geschrieben von zeckensack
Öhm, sorry, war meinerseits ein Schnellschuß.

Die Addition kann man am einfachsten ausschalten, indem man auf der zweiten EMBM-Einheit einfach die Texturkoordinaten auf Null setzt.

Aber den simplen dependant read kriegt man damit trotzdem nicht hin. Das Problem ist einfach, daß das Sample aus der ersten Einheit meine nächste Texturkoordinate bestimmt, und nicht irgendeine Farbberechnung, die ich vorher gemacht habe. Das kriegt man nicht weg. Man kann dann eben nur pro Vertex an den Texturkoordinaten für die erste EMBM-Einheit spielen, aber eben nicht pro Pixel in diese Berechnung eingreifen. Dann kann ich mir das ganze auch gleich komplett sparen.

Lange Rede, kurzer Sinn,
EMBM kann man derzeit nur für EMBM einsetzen, und für nichts anderes :(

Möglicherweise stehe ich jetzt auch auf dem Schlauch aber was macht ein Dependent Read anderes als das Ergebniss eines vorhergehenden Textureread wieder als Koordinaten für einen weiteren Read zu benutzen.

Ach jetzt dämmert es mir. Du meinst die erweiterte Form eines dependent Reads bei dem man vor dem zweiten Read auch noch mit dem Ergebniss des ersten Reads rechnen darf bzw die Texturekoordinate im Fragmentbereich irgendwie berechnet, oder?

Aber du hast recht ausser EMBM kann man damit wirklich nicht allzu viel anfangen.

[Demirug]

Original geschrieben von Quasar
Weisst du zufällig, auch wenn es völlig OT ist, wie sich die Matrox G4xx/550 hier verhält? IIRC melden zumindest die D3D-Treiber 3 Textureinheiten auf der Pipeline, wovon eine eigentlich die EMBM-Einheit sein sollte.

Kann man die noch für etwas anderes gebrauchen?

Gemeldet werden 3 Textureinheiten. AFAIK habe wir Büro im Hardwarepool noch eine rumliegen. Könnte ich am Montag mal kurz einbauen und schauen ob man die auch für "normales" MT benutzen kann.

[zeckensack]

Original geschrieben von Demirug
Möglicherweise stehe ich jetzt auch auf dem Schlauch aber was macht ein Dependent Read anderes als das Ergebniss eines vorhergehenden Textureread wieder als Koordinaten für einen weiteren Read zu benutzen.Der erste Texturzugriff ist erstmal völlig optional, und definiert im Kern nicht den dependant read. Das kann auch eine Operation auf interpolierte Vertex-Attribute (Farben, ...) sein.

Was ich gerne hätte, wäre die Möglichkeit einfach die durch die vorhergehendenden (nicht weiter definierten) Berechnungen erzeugte Farbe als Texturkoordinate zu verwenden.

EMBM kann's nicht. Erstens erlaubt es nur eine Operation (Addition), zweitens gibt es mir den Anfang meiner Berechnung vor (ich werde eben auf ein über klassische Addressierung gewonnenes Textursample gezwungen).

Das sind doch logisch gesehen drei Schritte.
1)Textursample holen, ablegen
2)Textursample modifizieren
3)Textursample als Addresse benutzen

Auf 'klassischen' Architekturen erfolgt hier ein Übergang von einem Arithmetik-Register in ein Address-Register, irgendwo innerhalb dieser Kette von Operationen. Zumindest gehe ich davon aus, daß das Ziel des ersten Textursamples ein Arithmetik-Register ist, denn so funktionieren alle 'normalen' Texturzugriffe, das wäre von daher der natürlichste Weg das zu implementieren.

Und genau diesen Transfer ins Address-Register hätte ich gerne für sich alleine verfügbar.

[Demirug]

zeckensack, war ein reines Definitionsproblem. Ich habe hier Unterlagen rumliegen die auch schon EMBM als Dependent Read Operation anerkennen. Dort wird ein Dependentread so definiert das für den Textureread koordinaten benutzt werden welche nicht direkt durch die Interpolation von Vertexdaten entstanden sind.

Das was du beschreibst kann ja eigentlich erst der R200 weil die NV2X Chips machen das ja anders.

[zeckensack]

Die NV2x-Chips haben sehr schöne Farb-Operationen, aber die Address-Ops halte ich für zu kläglich, um sie als Diskussionsgrundlage überhaupt in Betracht zu ziehen ;)

[Pitchfork]

@Zeckensack: Ich bin mir noch nicht sicher, was du willst, oder ob du dich einfach verennst.

1. Dependant Reads arbeiten nur mit TexCoords als Input. Alle! Per Definitionem. Ob jetzt irgendwo eine Farbe in eine TexCoord kopiert wird, ändert nix an dieser Tatsache, sondern führt eher dazu, daß ich diese "Farbe" nicht als Farbe bezeichnen kann.

2. Wenn die Werte vom Vertex kommen und interpoliert werden, dann brauchst du keinen Dependent Read, sondern legst die Daten direkt als Tex Coord an.

3. Wenn du auf diesen Daten eine arithmetische Operation ausführen willst vor dem Read, dann muß man erstmal genau schauen, welche Operation das ist. Die meisten dürften eh interpolierbar sein, weil die wirklich interessaten Pixel Shader 2.0 vorausetzen. Also auch hier kein Dependent Read nötig mangels Möglichkeiten der Arithmetik.

4. Bleibt eigentlich nur das Verwenden einer Texture, die die Daten für den Dependent Read erzeugt oder modifiziert. Wo ist da also das Problem bei EMBM? Das die arithmetischen Operationen zwischen lesen der ersten Textur und dem dependent Read sich auf eine 2x2 Matrix beschränken?

Was du imho willst ist eine 2 Phasen Architektur wie sie r200 eingeführt hat, vorher gab es nie was ansatzweise vergleichbares. Und das ist der Grund, warum ich ps11 bis ps13 immer noch als Register Combiner betrachte und nicht als programmierbare Shader (auch wenn es sehr lustig ist aus 10 Zeilen ps11 asm Shadern einen 46 Zeilen HLSL Shader zu machen *bg*)

[zeckensack]

Original geschrieben von Pitchfork
@Zeckensack: Ich bin mir noch nicht sicher, was du willst, oder ob du dich einfach verennst.

1. Dependant Reads arbeiten nur mit TexCoords als Input. Alle! Per Definitionem. Ob jetzt irgendwo eine Farbe in eine TexCoord kopiert wird, ändert nix an dieser Tatsache, sondern führt eher dazu, daß ich diese "Farbe" nicht als Farbe bezeichnen kann.Joa, das ist vielleicht die Definition die mit DX8.0 geliefert wurde ... ;)
2. Wenn die Werte vom Vertex kommen und interpoliert werden, dann brauchst du keinen Dependent Read, sondern legst die Daten direkt als Tex Coord an.Nö. Zwei linear interpolierte Werte miteinander multipliziert ergibt eine nicht mehr linear interpolierbare Funktion. Mal als Minimalbeispiel
a b a*b
0.0 0.0 0.0
0.5 0.5 0.25
1.0 1.0 1.0



3. Wenn du auf diesen Daten eine arithmetische Operation ausführen willst vor dem Read, dann muß man erstmal genau schauen, welche Operation das ist. Die meisten dürften eh interpolierbar sein, weil die wirklich interessaten Pixel Shader 2.0 vorausetzen. Also auch hier kein Dependent Read nötig mangels Möglichkeiten der Arithmetik.Öhm, doch! :)

4. Bleibt eigentlich nur das Verwenden einer Texture, die die Daten für den Dependent Read erzeugt oder modifiziert. Wo ist da also das Problem bei EMBM? Das die arithmetischen Operationen zwischen lesen der ersten Textur und dem dependent Read sich auf eine 2x2 Matrix beschränken?Was ist mit Textursample*Konstante, aka interpolierte Vertex-Farbe? Ist mit einer Matrix nicht lösbar, wohl aber (zudem trivial) mit der Multitexturing-Pipeline. Das ganze ist schlicht nicht so flexibel, wie es sein könnte, das ist alles.

Wenn ich einen Textursampler so umkonfigurieren kann, daß er sein Ergebnis entweder in die Combiner-Pipeline oder in ein Addressregister stopft, ja warum geht das dann nicht auch mit Farbwerten aus der Combiner-Pipeline?
Die sind auch nicht 'teurer' zu berechnen, und die Synchronisierungsprobleme sind die gleichen (EMBM ist ja auch deutlich langsamer als kein EMBM).

Was du imho willst ist eine 2 Phasen Architektur wie sie r200 eingeführt hat, vorher gab es nie was ansatzweise vergleichbares.Jein. Sagen wir mal so, ich bin es gewohnt den R200 als Basis für Pixel-Shader-Zeugs herzunehmen, weil ich damit in die Materie eingestiegen bin.

Trotzdem geht's mir jetzt erstmal um EMBM. Auf aktuellen Chips ist mir das extremst wurscht, da komme ich auch leichter ans Ziel. Ich bin nur enttäuscht, daß EMBM eben so starr spezifiziert wurde. Die Infrastruktur ist definitiv da, ich kann sie halt nur nicht ansprechen.

Und das ist der Grund, warum ich ps11 bis ps13 immer noch als Register Combiner betrachte und nicht als programmierbare Shader (auch wenn es sehr lustig ist aus 10 Zeilen ps11 asm Shadern einen 46 Zeilen HLSL Shader zu machen *bg*) Ack *eg*

[Demirug]

Original geschrieben von Pitchfork
Was du imho willst ist eine 2 Phasen Architektur wie sie r200 eingeführt hat, vorher gab es nie was ansatzweise vergleichbares. Und das ist der Grund, warum ich ps11 bis ps13 immer noch als Register Combiner betrachte und nicht als programmierbare Shader (auch wenn es sehr lustig ist aus 10 Zeilen ps11 asm Shadern einen 46 Zeilen HLSL Shader zu machen *bg*)

Ja das ist auch lustig wenn man sich die Patente und einige Unterlagen von nVidia zu den NV2X Chips anschaut. Als Pixelshader wird da immer nur der Teil vor den Regcombiner bezeichnet. In einem DX-Pixelshader sind das aber gerade mal die ersten 4 "Texture"anweisungen.

PS: Wie expandiert man einen PS11 Shader auf 46 Zeilen HLSL? Oder meinst du jetzt mit allem und nicht nur den eigentlichen Funktionscode?

[Demirug]

Original geschrieben von zeckensack
Joa, das ist vielleicht die Definition die mit DX8.0 geliefert wurde ... ;)

Das ist die Definition die immer noch benutzt wird. Jede Textureoperation erhöht den Dependentlevel des Ergebnisses um 1. Bei den NV3X Chips spielt das keine Rolle mehr aber bei den R(V)3XX Chips muss man da noch aufpassen.

Trotzdem geht's mir jetzt erstmal um EMBM. Auf aktuellen Chips ist mir das extremst wurscht, da komme ich auch leichter ans Ziel. Ich bin nur enttäuscht, daß EMBM eben so starr spezifiziert wurde. Die Infrastruktur ist definitiv da, ich kann sie halt nur nicht ansprechen.

Ack *eg*

Wenn man bedenkt das die Color-ALUs keine besonders hohe Bittiefe hatten wäre es dabei sowieso zu einem massiven Verlsut an Genauigkeit gekommen. Und für mehr Bits waren wohl keine Transitoren mehr da.

[Pitchfork]

Ich denke wirklich, daß die keine Chance hatte EMBM als freieren Dependent Read einzuführen. Schau dir doch den Aufwand beim nv20 an, da wird die gesamte Dependent Read Arithmetik ja in den Tex Befehlen dupliziert, auch in Hardware. Das hat absolut nix mehr mit den Register Combinern weiter hinten zu tun.

Wg. den 46 Zeilen:

sampler2D DecalDiffuse;
sampler2D TerrainLightmap;
sampler2D EffectLightmap;
sampler2D Shadowmap;

float4 ShadowFactor : register(c2);

struct FragmentIn
{
float2 Texture0 : TEXCOORD0;
float2 Texture1 : TEXCOORD1;
float2 Texture2 : TEXCOORD2;
float2 Texture3 : TEXCOORD3;
};

struct FragmentOut
{
float4 Color : COLOR;
};


FragmentOut main(FragmentIn I)
{
float4 Diffuse;
float4 Light;
float Shadow;
FragmentOut O;

// sample diffuse color
Diffuse = tex2D(DecalDiffuse, I.Texture0);

// calc lighting values

// soften shadow
Shadow = saturate(dot(tex2D(Shadowmap, I.Texture3).xyz, ShadowFactor.xyz));

// scale shadowfactor by dotproduct between light and object normal
Shadow = saturate(Shadow * tex2D(TerrainLightmap, I.Texture1).w);

Light = tex2D(TerrainLightmap, I.Texture1) * (1 - Shadow) + tex2D(EffectLightmap, I.Texture2);

O.Color.xyz = Diffuse * Light * 2;
O.Color.w = Diffuse.w;

return O;
}


Das gibt am Ende 4 tex Befehle gefolgt von 4,5 arith Befehlen (afaik). Schon lustig.

[Demirug]

Original geschrieben von Pitchfork
Ich denke wirklich, daß die keine Chance hatte EMBM als freieren Dependent Read einzuführen. Schau dir doch den Aufwand beim nv20 an, da wird die gesamte Dependent Read Arithmetik ja in den Tex Befehlen dupliziert, auch in Hardware. Das hat absolut nix mehr mit den Register Combinern weiter hinten zu tun.

Ja und bei den Tex Befehlen wird mit höherer Genauigkeit gerechnet. Beim P10/P9 ist das übrigens auch getrennt. Da gibt es einen Bereich für alle Berechunungen vor dem letzten Read und einen für danach. Der Vor den Reads arbeitet mit Fliespunkt der danach nur noch mit Integer.

Wg. den 46 Zeilen:

--snip--


Das gibt am Ende 4 tex Befehle gefolgt von 4,5 arith Befehlen (afaik). Schon lustig. [/SIZE][/QUOTE]

Ja der ist recht gut dabei.

Jetzt will ich nur noch einen HLSL Compiler der DX7 Stage Setups erzeugen kann.

[Ailuros]

3DFX hat de facto die VS und PS 1.0 Standards gesetzt, aber ich absolut der Meinung, die "Charisma"-Engine hätte für VS 1.0 gereicht. Bei den PS solls nicht sonderlich viel gewesen sein.

Darf der Laie mal, da anscheinend das ganze von diesem Kommentar ab abgespaltet wurde?

3dfx hat beigetragen zu dx8, genauso wie alle anderen IHVs. Dabei kam im Prozess heraus dass 3dfx nicht hoeher als PS1.1 und VS1.0 hatte, da die address ops fehlten, als Microsoft die specs festgenagelt hat.

Als ich damals fragte ob die fehlenden address ops ein Problem sein koennten war die Antwort dass es zwar nicht ideal sei, aber sie hatten damals ein paar clevere workarounds dafuer.

Und da ich Probleme habe das meiste hier in ganzem Detail zu verfolgen, geht es hier darum ob Spectre EMBM faehig war oder was? Ich wuerde mir vorstellen dass EMBM ueberhaupt kein Problem sein sollte mit 8-layer MT.... (entschuldigt die Unterbrechung).

[Pitchfork]

Der Adressoperator im Vertex Shader ist ne völlig andere Geschichte als EMBM und wird zB. fürs Matrix Palette Skinning verwendet.

[Demirug]

Original geschrieben von Ailuros
Darf der Laie mal, da anscheinend das ganze von diesem Kommentar ab abgespaltet wurde?

3dfx hat beigetragen zu dx8, genauso wie alle anderen IHVs. Dabei kam im Prozess heraus dass 3dfx nicht hoeher als PS1.1 und VS1.0 hatte, da die address ops fehlten, als Microsoft die specs festgenagelt hat.

Sicher mit den PS 1.1? Nach meinen Informationen war 1.0 für 3dfx vorgesehen und wurde dann später entfernt als von 3dfx nichts mehr kamm. Oder anders gefragt wenn 1.0 nicht für 3dfx war für wenn denn dann?

Und da ich Probleme habe das meiste hier in ganzem Detail zu verfolgen, geht es hier darum ob Spectre EMBM faehig war oder was? Ich wuerde mir vorstellen dass EMBM ueberhaupt kein Problem sein sollte mit 8-layer MT.... (entschuldigt die Unterbrechung).

Nein es ging eigentlich nur darum ob das EMBM jetzt schon ein depended Read ist oder nicht und was ATI sonst noch so zum PS 1.0 fehlt.

Die Anzahl der Texturelayer ist bei der Frage bezüglich EMBM eigentlich eher nebensächlich. 2 würden schon reichen aber damit man keine komischen Multipassspiele machen muss sind 3 schon besser. Der entscheidende Unterschied zwischen normalenm MT und EMBM ist aber das beim normalen MT alle Texturekoordinaten interpolierte Werte aus dem Vertexprocess sind. Beim EMBM muss man aber die möglichkeit haben das ergebniss eines Texturzugriffs wiederrum als Texturekoordinaten für einen weieren zugriff zu benutzten.

NORMAL:

Vertex Koordinaten -> Texture -> Farbe
Vertex Koordinaten -> Texture -> Farbe

EMBM:

Vertex Koordinaten -> Texture -> Koordinate -> Texture -> Farbe

[Pitchfork]

Btw. was ist eigentlich aus ps_1_2 geworden? Dachte ja Matrox oder 3dlabs würden sich das schnappen, haben sie aber nicht....

[Demirug]

Original geschrieben von Pitchfork
Btw. was ist eigentlich aus ps_1_2 geworden? Dachte ja Matrox oder 3dlabs würden sich das schnappen, haben sie aber nicht....

3dlabs hat doch zugeschlagen:

Wildcat VP aka P10/P9

http://www.3dlabs.com/product/wildcatvp/vppro/specs.htm

[Pitchfork]

Ups... hätte schwören können, daß P10 nen ps_1_3 Teil ist wie Parhelia.

[Demirug]

Original geschrieben von Pitchfork
Ups... hätte schwören können, daß P10 nen ps_1_3 Teil ist wie Parhelia.

Nein, und wenn ich die Architektur von P10/P9 richtig verstanden habe liegt das daran das man dort keine Möglichkeit hat den Z-Wert nachtraglich im Pixelshader noch einmal zu ändern weil die gesamte Z-Buffer Verwaltung als eigenständige Einheit vor den Pixelpipelines angebracht ist.

[MadManniMan]

@Ailuros: Ich bin mir genauso wie Demi 100% sicher, daß Rampage und Sage PS und VS 1.0 gebracht hätten.
BTW: hätte Rampage "pur" dann wie der Xabre die VS in SW gebracht?

Und tja, Charisma und Pixeltapestry scheinen nun wirklich je <1.0 :ratlos:

@Demi: Seh ich das richtig, daß P9/10 lange nicht derlei flexibel waren/sind, daß mal eben DX>8 reingetreibert werden können?

[Demirug]

Original geschrieben von MadManniMan
@Demi: Seh ich das richtig, daß P9/10 lange nicht derlei flexibel waren/sind, daß mal eben DX>8 reingetreibert werden können?

Sie sind schon sehr flexibel nur das sie das mit dem Z-Buffer ändern in der Pixelpipeline nicht eingebaut haben verhindert das sie über PS 1.2 hinauskommen. Ansonsten wäre auch 1.4 und wahrscheinlich noch mehr gegangen. Mit glslang kann man aus dem Chip wohl noch einiges herausholen. Das dumme für 3dlabs ist nur das OpenGL in den letzten Jahren doch schwer an Popularität verloren hat. Wenn man das als hintergrund nimmt dürfte auch klar werden warum sich 3dlabs so dafür einsetzt das OpenGL wieder mit DX auf gleicher Augenhöhe ist ohne das man auf unzählige Hersteller Extensions zugreifen muss.

[MadManniMan]

Original geschrieben von Demirug
Wenn man das als hintergrund nimmt dürfte auch klar werden warum sich 3dlabs so dafür einsetzt das OpenGL wieder mit DX auf gleicher Augenhöhe ist ohne das man auf unzählige Hersteller Extensions zugreifen muss.

...womit sie ja wohl auch das Übel an der Wurzel gepackt haben! War ja gar nicht mehr feierlich... Von DER Hochglanz-API schlechthin zu nem kränkelnden etwas, was mit dem MS-Konkurrenten nicht mehr so recht mithalten will - ohne IHV-Extensions versteht sich.

[Ailuros]

Sicher mit den PS 1.1? Nach meinen Informationen war 1.0 für 3dfx vorgesehen und wurde dann später entfernt als von 3dfx nichts mehr kamm. Oder anders gefragt wenn 1.0 nicht für 3dfx war für wenn denn dann?

So sicher wie Killgariff damals sein konnte.

Hier ein Auschnitt aus einem e-mail vom 24.April 2000:

M-Buffer
128Tap anisotropic filtering
52bit Internal Color rendering/ 0 – 16.0 Color luminosity range
FXT1/DXT1-5 Texture compression
Higher Ordered Surfaces (HOS)
3D textures support
True PhotoShop filter effects in hardware
Non-Photorealistic rendering
Cube Environment Maps/EMBM/Dot3 BM
YUV Texture formats
DirectX8 1.1Compliant Pixel Shader
DirectX8 1.0Compliant Vertex Shader

(HOS= polynomial surfaces)

FEAR war dx8.1 compliant mit PS/VS1.1

***edit:

natuerlich war das ganze eine Aufgabe von SAGE. Die angegebenen Nummern waren 100MVPS theoretical/50MVPS sustained, aber ob die letztere erreichbar war hab ich keine Ahnung.

***edit2:

BTW: hätte Rampage "pur" dann wie der Xabre die VS in SW gebracht?

Entry level Spectre waere logischerweise nichtmal voll dx7 kompliant gewesen. Klar konnte rampage ein paar Transformationen nach deren Angaben aufnehmen, aber ohne Geometrie chip ergo SAGE, kein T&L, PS oder VS in Hartware.

[MadManniMan]

Original geschrieben von Ailuros
Entry level Spectre waere logischerweise nichtmal voll dx7 kompliant gewesen. Klar konnte rampage ein paar Transformationen nach deren Angaben aufnehmen, aber ohne Geometrie chip ergo SAGE, kein T&L, PS oder VS in Hartware.

Naja, man hätte imho wohl ne SW-Lösung durchgeprügelt :kratz2:

Nochwas: ich wollte dir schon seit Monaten mal sagen, daß man "Hardware" mit nem weichen "t" schreibt. Ich habs Ewigkeiten so gemacht wie du, aber irgendwann...

;)

[Demirug]

Original geschrieben von Ailuros
So sicher wie Killgariff damals sein konnte.

Hier ein Auschnitt aus einem e-mail vom 24.April 2000:



(HOS= polynomial surfaces)

FEAR war dx8.1 compliant mit PS/VS1.1

***edit:

natuerlich war das ganze eine Aufgabe von SAGE. Die angegebenen Nummern waren 100MVPS theoretical/50MVPS sustained, aber ob die letztere erreichbar war hab ich keine Ahnung.

***edit2:



Entry level Spectre waere logischerweise nichtmal voll dx7 kompliant gewesen. Klar konnte rampage ein paar Transformationen nach deren Angaben aufnehmen, aber ohne Geometrie chip ergo SAGE, kein T&L, PS oder VS in Hartware.

OK bleibt also die Frage wer sich die 1.0 Pixel-Shader in die Spec hat schreiben lassen und dann später den Chip doch nicht gebracht hat.

Die PS hätte aber auch ohne SAGE funktionieren müssen.

[Ailuros]

Original geschrieben von MadManniMan
Naja, man hätte imho wohl ne SW-Lösung durchgeprügelt :kratz2:

Nochwas: ich wollte dir schon seit Monaten mal sagen, daß man "Hardware" mit nem weichen "t" schreibt. Ich habs Ewigkeiten so gemacht wie du, aber irgendwann...

;)

SW Loesung oder nicht zu dem Zeitpunkt war T&L fuer budget chips nicht so wichtig. Das Ding haette ja an die 150$ kosten sollen, haette mehr Fuellrate/Bandbreite als die V5 5500 und MSAA/AF gehabt, wobei es zumindest gleich so schnell haette sein koennen, wenn nicht sogar schneller, zumindest bei >2-layer MT. Mit sage an die 250$ und dual chip+sage=500$. Wo ich nicht mit der ganzen Architektur uebereinstimme ist das fehlende occlusion culling oder hierarchical Z und die eher merkwuerdige Anisotropy.

Also HARDWARE dann auch in Deutsch? Danke fuer die Korrigierung, ich hab solche Tips wirklich noetig. ;)

[Ailuros]

Original geschrieben von Demirug
OK bleibt also die Frage wer sich die 1.0 Pixel-Shader in die Spec hat schreiben lassen und dann später den Chip doch nicht gebracht hat.

Die PS hätte aber auch ohne SAGE funktionieren müssen.

Zum ersten hab ich wirklich keine Ahnung; kann sogar sein dass sie es selber angestellt haben und spaeter nochmal erhoeht haben. Rampage war eine konstante redesign/feature-creep Geschichte. Erster Rampage (R1) seit 1998; der den wir hier meinen hatte einen internen Codenamen R4.

Zum zweiten hat der Laie wieder mal zuviel und zu schnell getippt. SAGE kam nie zum finalen tape out soweit ich weiss. Frag mich bitte nicht wie der Revenge-Quatsch zustande kam (siehe 3dhq).

Ich weiss nur dass die Vaeter von Rampage bei Quantum3D arbeiten. Kann sein dass da was heimlich herumgetueftelt wurde.

[aths]

Afaik war PS 1.0 und VS 1.0 für Rampage / Sage gedacht. Rampage konnte afaik 8x MT, aber war eben auf die 8 Texture Stages insofern festgelegt, dass der Shader bei 4 Sampling-Anweisungen dann nur noch 4 Instruktionen aufnehmen kann.

[Pitchfork]

Original geschrieben von Demirug
Sie sind schon sehr flexibel nur das sie das mit dem Z-Buffer ändern in der Pixelpipeline nicht eingebaut haben verhindert das sie über PS 1.2 hinauskommen. Ansonsten wäre auch 1.4 und wahrscheinlich noch mehr gegangen. Mit glslang kann man aus dem Chip wohl noch einiges herausholen. Das dumme für 3dlabs ist nur das OpenGL in den letzten Jahren doch schwer an Popularität verloren hat. Wenn man das als hintergrund nimmt dürfte auch klar werden warum sich 3dlabs so dafür einsetzt das OpenGL wieder mit DX auf gleicher Augenhöhe ist ohne das man auf unzählige Hersteller Extensions zugreifen muss.

Das mit dem potentiellen ps1.4 beim p10 bezweifle ich. Erstens bräuchte man eine höhere Präzision im Shadingbereich, um daraus sinnvolle TexCoords abzuleiten und zweitens einen Loopback von hinter dem Shader nach vorne. Und genau den sehe ich beim p10 genauso wenig wie beim nv20. Ich behaupte mal, daß der p10 auf ps1.2 Level designed wurde und diesen auch erreicht. Mehr nicht.

[aths]

Original geschrieben von Pitchfork
Das mit dem potentiellen ps1.4 beim p10 bezweifle ich. Erstens bräuchte man eine höhere Präzision im Shadingbereich, um daraus sinnvolle TexCoords abzuleiten und zweitens einen Loopback von hinter dem Shader nach vorne. Und genau den sehe ich beim p10 genauso wenig wie beim nv20. Ich behaupte mal, daß der p10 auf ps1.2 Level designed wurde und diesen auch erreicht. Mehr nicht. Sind die Units im P10 nicht recht flexibel schaltbar, so dass man zur Not statt Loopback zu realisieren einfach die Pipe strecken könnte?

[zeckensack]

Original geschrieben von aths
Sind die Units im P10 nicht recht flexibel schaltbar, so dass man zur Not statt Loopback zu realisieren einfach die Pipe strecken könnte? Soweit ich weiß, kann der P10 bei weitem längere Shader-Programme ausführen. Ob das jetzt per Loopback gelöst wurde oder nicht, daran wird's sicher nicht liegen.

Die Phasen bei PS1.4 kann ein Chip der auf sowas nicht angewiesen ist komplett ignorieren.

[Demirug]

Original geschrieben von Pitchfork
Das mit dem potentiellen ps1.4 beim p10 bezweifle ich. Erstens bräuchte man eine höhere Präzision im Shadingbereich, um daraus sinnvolle TexCoords abzuleiten und zweitens einen Loopback von hinter dem Shader nach vorne. Und genau den sehe ich beim p10 genauso wenig wie beim nv20. Ich behaupte mal, daß der p10 auf ps1.2 Level designed wurde und diesen auch erreicht. Mehr nicht.

OK, wenn ich Behauptungen aufstelle muss ich diese auch begründen.

US2002118202: Same tile method

http://l2.espacenet.com/espacenet/viewer?PN=US2002118202&CY=gb&LG=en&DB=EPD

Sheet 5 von 7: Man sieht hier das es einen Loopback gibt welcher das ergebniss nach dem Filtern wieder zurück zur "Texture Coordinate Unit" schicken kann.

In der Beschreibung findet man nun ab Absatz 0141 die Details:

[0143] The Texture Coordinate Unit is a programmable SIMD array and calculates the texture coordinates and level of detail for all valid fragments within a tile. The SIMD array is likely to be 4*4 in size and the program run once per sub tile for those sub tiles with valid fragments. All the texture calculations for a sub tile are done before moving on to the next sub subtile.

[0148] ... The filtered texel color can be feedback to the Texture Coordinate Unit for bump mapping or any other purpose.

[0152] In order to support some of the more complex operations such as high order filtering, convolution and go beyond 8 textures per fragment several programs can be run on the same sub tile, with different input data before the final fragment color is produced. This multi pass operation is controlled by the Texture Coordinate Unit. This works in a very similar way as the multi pass operation of the Pixel Unit.

Wichtig sind auch noch die beiden Absätze aus der "Basic Feature Set
" Liste
[0032] True floating point coordinate generation.
[0033] Programmable texture coordinate generation.

Mir reicht das als Indikator das die Anforderungen für einen PS 1.4 (bis auf das Z-Wert Problem) erfüllbar sind.

[Demirug]

Original geschrieben von aths
Sind die Units im P10 nicht recht flexibel schaltbar, so dass man zur Not statt Loopback zu realisieren einfach die Pipe strecken könnte?

Die Units sind schon fest in ihrer Rheienfolge. Aber jede Unit ist mehr oder minder ein SIMD Array und an den wichtigen Stellen gibt es Loopbacks.

[Demirug]

Original geschrieben von zeckensack
Soweit ich weiß, kann der P10 bei weitem längere Shader-Programme ausführen. Ob das jetzt per Loopback gelöst wurde oder nicht, daran wird's sicher nicht liegen.

Die Phasen bei PS1.4 kann ein Chip der auf sowas nicht angewiesen ist komplett ignorieren.

Intern hat der P10 wohl auch sowas wie Phasen (s. Absatz 152 aus meinen Post) dazu kommt noch der Loopback zurück zur Koordinaten Berechung. Wie das alles nun aber genau zusammenarbeitet ist nicht offengelegt.

[Pitchfork]

Wahrscheinlich hast du Recht Demirug. Ich frage mich bloß gerade anhand deiner Zitate, ob der Loopback rein im Texture Coordinate Calculation/Fetching Bereich stattfindet(I) oder ob er die Shading Operations(II) ebenfalls umfaßt. Einige Sätze lassen Variante (I) wahrscheinlicher erscheinen. Auch wenn ich mich dann ernsthaft frage, wieso er einen Integer Shading Bereich hat, wenn die Tex Units das gleiche können....
Denn welche arithmetischen Instructions gibt es, die nicht auch die TexUnits verarbeiten können außer cmp/cnd? Zumindest im ps_1_x Bereich finde ich nix. Das ließe schließen, daß der p10 doch schon einige Ops aus dem ps_2_x Bereich kennt (rcp, rsq etc.). Bloß wie bedeutend ist sowas mit Integer Units?
Ich verstehe diesen Chipaufbau einfach nicht. Ich sollte mich dann doch mal in glslang und die entsprechenden 3dlabs Extensions vertiefen....

[Demirug]

Original geschrieben von Pitchfork
Wahrscheinlich hast du Recht Demirug. Ich frage mich bloß gerade anhand deiner Zitate, ob der Loopback rein im Texture Coordinate Calculation/Fetching Bereich stattfindet(I) oder ob er die Shading Operations(II) ebenfalls umfaßt. Einige Sätze lassen Variante (I) wahrscheinlicher erscheinen. Auch wenn ich mich dann ernsthaft frage, wieso er einen Integer Shading Bereich hat, wenn die Tex Units das gleiche können....

Der Loopback umschliesst laut der Zeichnung und dem Text nur den Bereich von der Koordinaten Calculation bis zu den Texturefiltern.

Die Integer SIMD sind nicht mit eingeschlossen. Allerdings kann man die Gesammte Pixel-Pipeline pro Pixel mehrmals durchlaufen. Dabei scheint es aber primär darum zu gehen die 8 Texturen/Pass limitierung aufzuheben.

Ja der Sinn der Integer einheiten ist mir auch noch nicht ganz klar geworden aber ich habe da einen Verdacht. Performanceüberlegungen.

Die "Texture Coordinate Unit" und die "Shading Unit" laufen ja parralle. Würden man also alles nur in der "Texture Coordinate Unit" rechen müsste diese damit man den gleichen Ausgangsleistung erreicht ja wesentlich mehr SIMD-Zellen haben. Die FP32 Zellen in der "Texture Coordinate Unit" dürften aber sehr viel mehr Transitoren als die Int8 Zellen in der "Shading Unit" brauchen.

Denn welche arithmetischen Instructions gibt es, die nicht auch die TexUnits verarbeiten können außer cmp/cnd? Zumindest im ps_1_x Bereich finde ich nix. Das ließe schließen, daß der p10 doch schon einige Ops aus dem ps_2_x Bereich kennt (rcp, rsq etc.). Bloß wie bedeutend ist sowas mit Integer Units?

Ich glaube beim P10 dürfen wir uns nicht so sehr an DX festhalten. 3dLabs ist primär eine OpenGL Firma. Und der Druck den 3DLabs in Richtung glslang ausgeüpt hat lässt darauf schliessen das der Chip diese Schnittstelle braucht.

Ja er kennt sicher schon PS 2.X Ops aber IMHO nur innerhalb der "Texture Coordinate Unit"

Ich verstehe diesen Chipaufbau einfach nicht. Ich sollte mich dann doch mal in glslang und die entsprechenden 3dlabs Extensions vertiefen....

Die Pixelpipline getrennt betrachtet ist dem NV2X Design gar nicht zu unähnlich. Es gibt einen Einheit welche Texturekoordinaten berechnet gefolgt von der Einheit welche die Texuren ausliest. Um beide befindet sich ein Loopback. Die Ergebnisse werden dann als ganze der "Shading Unit" (beim NV2X Regcombiner) übergeben von der man aber nicht mehr zurück zum Berechnen der Texturekoordinaten kann. Der P10 kann ja API technisch einen NV2X Chips perfekt emulieren. 3DLabs war dabei ja sogar so gemein 8 Texturen pro Pass damit zur Verfügung zu stellen.