Tessellation Unit [Archiv]

reunion

2007-06-03, 18:53:18

Also bringt die TU im R600 nur was unter OGL und wenn die Programmierer sich die Mühe gemacht haben? Wieso verschwendet dann ATI Transistoren in die TU?

Die TU ist fest im Design verankert. Es wäre laut Ail zuviel Aufwand gewesen, sie wieder zu entfernen. Immerhin gibt es ja auch viele älterer D3D10-Dokumente, wo immer wie von einer Tesslation-Unit gesprochen wurde. Offensichtlich wurde das Ding nachträglich aus den Specs gestrichen.

Deshalb bin ich übrigens auch auf die Demos gespannt die ATI bisher nur als Video veröffentlicht hat. Müssten eigentlich fast OpenGL sein.

Du meinst den „Ninja-Kopf“? Auch das Ruby-Demo soll die Tessellation-Einheit laut ATi verwenden, und das ist definitiv D3D10.

ShadowXX

2007-06-03, 18:53:54

Wieso verschwendet dann ATI Transistoren in die TU?
Weil Sie vom C1 her schon vorhanden war, ein GS sowieso Pflicht bei D3D10 war und ATI wohl vorhat das Design zumindest bis zu D3D11 durchzuschleppen und irgendwann auf der Strecke dahin die schon fertige Einheit wohl ATIs Überlegungen nach nützlich sein wird.

Es kann auch einfach sein, das Sie wirklich einfach nur vom C1-Design übrig geblieben ist und es schwerer gewesen wäre Sie "auszubauen" (bzw. zurückzustufen) als Sie einfach drinne zu lassen.

Die TU ist fest im Design verankert. Es wäre laut Ail zuviel Aufwand gewesen, sie wieder zu entfernen. Immerhin gibt es ja auch viele älterer D3D10-Dokumente, wo immer wie von einer Tesslation-Unit gesprochen wurde. Offensichtlich wurde das Ding nachträglich aus den Specs gestrichen.
Wobei man sagen muss, das die Tesselationseinheit schon vor "Ewigkeiten" aus den D3D10-Specs gestrichen wurde.

Demirug

2007-06-03, 18:55:28

Deshalb bin ich übrigens auch auf die Demos gespannt die ATI bisher nur als Video veröffentlicht hat. Müssten eigentlich fast OpenGL sein.

Auch bei D3D10 sind API Hacks möglich.

Hauwech

2007-06-03, 18:56:02

Was man so gehört hat, soll die TU transistormäßig ja nicht gerade günstig sein.

Wunder mich ob ATI eventuell wesentlich früher mit Vista und dementsprechend DX10.x gerechnet hat.

Coda

2007-06-03, 18:58:34

Auch bei D3D10 sind API Hacks möglich.
In dem kranken Umfang? Das bringen sie nicht wirklich :|
Ich hab ja auch schon drüber nachgedacht, aber es dann eigentlich als Unsinn verworfen. Es gibt ja überhaupt keine Eintrittspunkte in diese Richtung.

Weil Sie vom C1 her schon vorhanden war, ein GS sowieso Pflicht bei D3D10 war und ATI wohl vorhat das Design zumindest bis zu D3D11 durchzuschleppen und irgendwann auf der Strecke dahin die schon fertige Einheit wohl ATIs Überlegungen nach nützlich sein wird.
Der GS sitzt an einer ganz anderen Stelle in der Pipeline. Ich weiß nicht ob man da soviel Baugruppen teilen kann.

AnarchX

2007-06-03, 18:58:36

Laut Ailuros (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5503832&highlight=R400#post5503832) soll sogar der R400 diese Tesselations-Einheit gehabt haben.

Da scheint es wohl bei den ATi-Entwicklern durchaus Fans dieser Technologie zu geben, immerhin versuchte man ja sie schon mit dem R200 in einer frühen Form durchzusetzen, was aber bekanntlich scheiterte.

Weiterhin soll sie auch laut Ailuros schon ohne Veränderungen für D3D11 nutzbar sein.

Aber naja wer weiß, wohlmöglich hat ATi noch Optimierungsbedarf entdeckt bzw. es erfordert gewisse Veränderungen für den Einsatz in den kommenden GPUs.

reunion

2007-06-03, 19:00:29

Wobei man sagen muss, das die Tesselationseinheit schon vor "Ewigkeiten" aus den D3D10-Specs gestrichen wurde.

Eine Grafikchip entwickelt man auch nicht von heute auf morgen. Offensichtlich war es da schon zu spät.

Demirug

2007-06-03, 19:18:10

In dem kranken Umfang? Das bringen sie nicht wirklich :|
Ich hab ja auch schon drüber nachgedacht, aber es dann eigentlich als Unsinn verworfen. Es gibt ja überhaupt keine Eintrittspunkte in diese Richtung.

Dank User Mode Treiber kann man sich leicht eigene Eintrittspunkte schaffen.

Coda

2007-06-03, 19:26:44

Wie ist die Haltung von Microsoft was das angeht bzgl. WHQL, etc.?

Demirug

2007-06-03, 19:29:27

Wie ist die Haltung von Microsoft was das angeht bzgl. WHQL, etc.?

Sie können dagegen genau so wenig tun wie gegen die bisherigen Hacks.

Coda

2007-06-03, 19:45:40

War nicht mal die Sache so, dass das SM2-Instancing bei den Catalysts standardmäßig abgeschaltet war um WHQL zu bekommen?

deekey777

2007-06-03, 20:03:03

War nicht mal die Sache so, dass das SM2-Instancing bei den Catalysts standardmäßig abgeschaltet war um WHQL zu bekommen?
Ich glaub, ja.

Gast

2007-06-03, 20:33:56

War nicht mal die Sache so, dass das SM2-Instancing bei den Catalysts standardmäßig abgeschaltet war um WHQL zu bekommen?
Was isn an sonem Vorgehen so böse?

Coda

2007-06-03, 20:36:05

Naja manchmal meint man ATI würde nicht im DirectX-Gremium sitzen. Das ist ja nicht das erste Mal das sowas vorkommt.

TheRealTentacle

2007-06-09, 13:18:06

Da scheint es wohl bei den ATi-Entwicklern durchaus Fans dieser Technologie zu geben, immerhin versuchte man ja sie schon mit dem R200 in einer frühen Form durchzusetzen, was aber bekanntlich scheiterte.

Witzigerweise sind es immer die geraden Generationen bei ATI die diese Einheit haben und generell technisch nicht so ausgereift sind :D

=Floi=

2007-06-10, 20:25:15

kann mir mal ein guru erklären warum man ausgerechnet mehr polygone braucht?
imho stagniert seit dem G70 die polygon "leistung" und beim G80 hat man diese auch nicht aufgebohrt und ich dachte mehr polygone werden nicht mehr benötigt weil andere bereiche limitieren und es mehr auf die aritmetische rechenleistung wegen der shader ankommt....

Gast

2007-06-10, 20:52:37

kann mir mal ein guru erklären warum man ausgerechnet mehr polygone braucht?

was willst du sonst verwenden?

imho stagniert seit dem G70 die polygon "leistung" und beim G80 hat man diese auch nicht aufgebohrt und ich dachte mehr polygone werden nicht mehr benötigt weil andere bereiche limitieren und es mehr auf die aritmetische rechenleistung wegen der shader ankommt....

was meinst du mit "polygon-leistung"?

den theoretischen vertexdurchsatz? der hat sich insbesondere mit den unified-shader-karten extrem erhöht.

Gast

2007-06-10, 23:26:19

Diese Tesselation Unit stammt noch aus der Zeit als die Matrox Parhelia auf den Markt gekommen ist.
Sie hatte zwei wesentliche Vorteile gegenüber allen anderen Grafikkarten:
- Displacement Mapping per Hardware
- Depth Adaptive Tesselation
Damit hätten sich zu Zeiten von DirectX8.1 grafische Leckerbissen realisieren lassen die man bis heute in keinem Spiel findet. Meines Wissens gibt es bis heute kein Spiel das von der Technologie gebrauch gemacht hätte.

Auch der Parhelia Chip hatte um einiges mehr an Transistoren und eine bessere Speicheranbindung als die Mitbewerber. Trotzdem konnte er im Vergleich nicht mithalten. Ich nehme an dass viel von der Rechenleistung für die Tesselation Unit vorgesehen war.

Und auch das von Matrox damals vorgestelle Head Casting wurde von ATI wieder aufgegriffen.

Infos zu diesem Chip gibts hier
http://www.3dcenter.org/artikel/parhelia/index4.php

Auf dieser Seite ist eine Figur zu sehen die durch Displacement Mapping in viele verschiedene Polygone unterteilt wird und je nach Displacement Map auch ein unterschiedliches Aussehen bekommt. Ohne Depth Adeptive Tesselation müßten immer alle Polygone berechnet werden egal ob die Figur ganz bildschirmfüllend oder nur als kleiner Punkt dargestellt wird.
http://archiv.chip.de/artikel/c1_archiv_artikelunterseite_17133728.html?tid1=33105&tid2=0

Eigentlich bin ich ja seit dem Erscheinen der R600 auf der Suche nach 2 Demovideos von Matrox die sehr anschaulich zeigen was der Sinn dieser Technologie ist nur konnte ich keines der beiden mehr im Netz finden.

Die Beschreibungen zur Parhelia finden sich noch massenweise im Netz aber leider nicht mehr diese zwei Videos, und ich hab schon Stunden gesucht!
Noch ein Link. Vielleicht hilft euch der ja weiter, ich finde sie einfach nicht.
http://www.anandtech.com/video/showdoc.aspx?i=1620&p=5

Demirug

2007-06-10, 23:37:50

Matrox hat vielleicht mehr Transistoren verbraten aber dadurch wird das Design auch nicht besser. Man hat versucht mit einem fixed function design einen Shader chip zu bauen. Das musste ja in die Hose gehen. Das gleiche gilt für die Speicheranbindung. Die war zwar breit aber reichlich ineffektiv.

Mit ihrer Tesselationseinheit hätten sie vielleicht punkten könnte aber sie haben es nie geschafft einen DX9 Treiber heraus zu bringen mit dem man sie auch hätte nutzen können.

Gast

2007-06-11, 00:04:21

Sagen wir so: Das Grafikkartengeschäft im Spielebereich ist Matrox "eine" Nummer zu groß geworden. Matrox ist zwar sehr bekannt aber im Entwicklungsbudget immer noch eine kleine Firma im Vergleich zu Nvidia und ATI. Viele wissen nicht dass es sich bei Matox um eine Firma in Privatbesitz und nicht um ein wie üblich börsennotiertes Unternehmen handelt. So gesehen war es nur eine Frage der Zeit bis sich Matrox zurückgezogen hat. Unter anderem sicher auch um sein Image nicht zu gefährden.
Matrox entwickelt und erzeugt hochwertige und auch hochpreisige Qualitätsprodukte für Spezialanwendungen.

Übrigens für alle die an der Tesselation interessiert sind, ich hab doch noch ein sehr gutes Video gefunden :-)
Ich schick euch allerdings nur den Link zum Artikel, das Video müßt ihr euch selbst raussuchen :-)
http://techreport.com/etc/2002q2/parhelia/index.x?pg=1

Hallo

2007-06-11, 00:17:51

was meinst du mit "polygon-leistung"?

Eine gute Frage.
Die Rohleistung einer PS2 wurde ca.55mio Polygone/sec beziffert.Ingame mit"allen"Effekten waren es dann nur noch ein Zehntel.

Ich finde Polygonleistung sollte immer unter Last(in einem angemessenen Setting) angegeben werden.Und genau hier wundert es mich wo all die Polygone bleiben bei aktuellen GKs?Es gilt immer noch: sobald eine Szene vom Polygoncount komplex wird gehts in die Knie.Oder warum sind der Boden bei FPS oder Racinggames immer noch riesengrosse platte Polygone?Bei dem Count den heutige GKs liefern, könnte man viele Unebenheiten polygonisieren statt zu bump/parallaxmappen,AA drüber und gut oder nicht?

Coda

2007-06-11, 00:22:47

Das Problem ist da eher dass es anfängt zu flimmern. Bei Geometrie gibt's kein automatisches LOD.

KiBa

2007-06-11, 00:35:08

den theoretischen vertexdurchsatz? der hat sich insbesondere mit den unified-shader-karten extrem erhöht.
Eine 8800er gtx hat unter opengl eine nur etwas höhere vertex-leistung als eine 7900 gtx. Sieht ganz so aus, als ob diese zugunsten der Quadro Karten erheblich eingebremst wurde, genauso wie der Vertexdurchsatz auf 1/5 einbricht, wenn man two-sided lighting benutzt (bzw. die entsprechende glsl variable liest).
AMD hat hier im Moment einen großen Vorteil, da deren "billige" Retail-Karten wohl deutlich mehr Vertexpower haben (2 oder 3fache?).
Diese Treiberpolitik von nVidia kann ich zwar nachvollziehen (melken des Profi-Marktes), aber nicht gut heißen, da auch Spieleentwickler in Zukunft wegen der miserablen Performance nicht mit deutlich höheren Vertexmengen experimentieren werden. (Henne-Ei-Problem)

Hallo

2007-06-11, 10:55:20

Das Problem ist da eher dass es anfängt zu flimmern. Bei Geometrie gibt's kein automatisches LOD.

Wieso?MSAA glättet doch gerade die vielen Kanten und bei entsprechend hoher Auflösung verkommen auch die kleinsten Dreiecke nicht im Matsch.
Ausserdem hat man doch schon immer mit Geometrie-LOD gearbeitet,wenn auch nicht automatisch tesseliert.Doch zwei bis drei gute"handgemachte"Stufen wären drinn.
SegaRallyEvo geht dahingehend den richtigen Schritt und polygonisiert erstmals die Reifenspuren mit entsprechender Physik.Denn Shader-Reifenspuren(ala MotorStorm) flimmern noch mehr,ausser man haut SSAA drüber.

Coda

2007-06-11, 11:00:50

Wieso? MSAA glättet doch gerade die vielen Kanten und bei entsprechend hoher Auflösung verkommen auch die kleinsten Dreiecke nicht im Matsch.
Man kann auch kein Mipmapping weglassen wenn man Supersampling verwendet. Es flimmert trotzdem irgendwann, wenn auch nicht so schnell.

Ausserdem hat man doch schon immer mit Geometrie-LOD gearbeitet,wenn auch nicht automatisch tesseliert.Doch zwei bis drei gute"handgemachte"Stufen wären drinn.
Feinstrukturierte Polygongeometrie ist inpraktikabel, auch mit handgemachtem LOD. Die Übergänge wären viel zu hart.

SegaRallyEvo geht dahingehend den richtigen Schritt und polygonisiert erstmals die Reifenspuren mit entsprechender Physik.
Ich kenn das Spiel nicht. Screenshot bitte. Ich bezweifel dass da was tesseliert wird.

Denn Shader-Reifenspuren(ala MotorStorm) flimmern noch mehr,ausser man haut SSAA drüber.
Nicht wenn der Shader das Abtasttheorem einhält. Ist schwer bei RSX weil der kein gescheites dyn. branching kann. Es ist in einem Shader auf heutigen GPUs aber definitiv viel einfacher einzuhalten als Polygon-LOD zu machen.

Gast

2007-06-11, 14:38:17

Es gilt immer noch: sobald eine Szene vom Polygoncount komplex wird gehts in die Knie.Oder warum sind der Boden bei FPS oder Racinggames immer noch riesengrosse platte Polygone?

einerseits steigt die cpu-last bei großen polygonmengen stark an, weiters das von coda angesprochene problem dass die grafik zu starkem flimmern neigen würde. auch 8xMSAA ist machtlos wenn es in einem pixel 10 überlappende polygone gibt.

weiters rendern heutige GPUs quads, dadurch wird das rendering mit kleinen polygonen verdammt ineffizient.

Gast

2007-06-12, 01:02:24

Klingt alles sehr theoretisch... und so lange niemand, und damit ist jetzt ATI gemeint ein ordentliches Demo zur Verfügung stellt wird es das auch bleiben.

Die beiden Videos von ATI und Matrox zeigen eine eindrucksvolle Technologie aber es wäre interessant wie das in der Praxis, zB. in einem First Person Shooter wie Quake, FarCry oder Halfe Life aussieht.

Man fragt sich wieso niemand diese Technik aufgegriffen hat. War der Entwicklungsaufwand für die relativ kleine Anzahl an möglichen Kunden zu groß? Oder war es gar kein großer Aufwand eine zusätzliche Displacement Map zu erstellen und der Chip war einfach zu langsam?

Wenn man bedenkt dass diese Technik zu Zeiten von R2CW, den HL Add-Ons oder Chaser entwickelt wurde. Das ist jetzt 6 Jahre her und wir müssen uns teilweise immer noch mit platten Böden, Fenstern, Türen und vor allem Wänden herumquälen.

Grundsätzlich finde ich diese Technologie toll und schätze die Bedeutung auch auf HDR hoch 10 ein, aber wieso wurde sie in noch keinem einzigen Spiel oder auch nur einer Demo eines einzigen Levels oder Map verwendet?

Hallo

2007-06-12, 06:23:49

Man kann auch kein Mipmapping weglassen wenn man Supersampling verwendet. Es flimmert trotzdem irgendwann, wenn auch nicht so schnell.

Jupp,aber später/weniger,besser als gar nichts:smile:

Feinstrukturierte Polygongeometrie ist inpraktikabel, auch mit handgemachtem LOD. Die Übergänge wären viel zu hart.

Stimmt,aber auch hier: besser als nix und Optimierungspotenzial bei"handgemachten"Sachen ist immer drinn.

Ich kenn das Spiel nicht. Screenshot bitte. Ich bezweifel dass da was tesseliert wird.
Mir ging es bei SRallyEvo nicht um Tesselation,sondern um einen sinnvollen/sichtbaren Umgang mit den vielen Polygonen die uns heute zur Verfügung stehen.Nämlich bei einem Rennspiel einen komplexen/dynamischen Boden zu bekommen der sich auch physikalisch auf die Fahreigenschaft des Fahrzeugs auswirkt.Da kann man so richtig schön viele Polys verbraten:tongue:

Ist vielleicht ein bisschen gewagt,doch ein Daytona2(1998) mit nur 1mio Polys/sec@60fps mit ALLEN Effekten on sieht vom Count garnicht sooo viel schlechter aus als heutige Rennspiele,auch wenn es dumm und dämlich optimiert ist.

Nicht wenn der Shader das Abtasttheorem einhält. Ist schwer bei RSX weil der kein gescheites dyn. branching kann. Es ist in einem Shader auf heutigen GPUs aber definitiv viel einfacher einzuhalten als Polygon-LOD zu machen.
Hmm,meinst du damit Poly-LOD ist schwieriger als Bumpmap-Shaderflimmern in den Griff zu bekommen ist?
Nunja,bei MotorStorm ist dies(Bumpmapping) leider nicht gelungen.

Hallo

2007-06-12, 06:37:04

einerseits steigt die cpu-last bei großen polygonmengen stark an, weiters das von coda angesprochene problem dass die grafik zu starkem flimmern neigen würde. auch 8xMSAA ist machtlos wenn es in einem pixel 10 überlappende polygone gibt.

weiters rendern heutige GPUs quads, dadurch wird das rendering mit kleinen polygonen verdammt ineffizient.

Genau das mit der Ineffizienz bei kleinen Dreiecken hat mich schon immer gestört.
Doch meine Frage lautet:Wozo hunderte Mios von Polys wenn nur wenige grosse dargestellt werden können weil nicht mehr auf den Schirm passen?
Nö,ich will endlich detailierte Objekte und Personen*schmoll*

Und zum Ruckeln bei hohem Count,es muss endlich alles auf die GK ausgelagert werden damit nicht der PCIe-Bus/CPU limitiert wenn Unmengen an Rohgeometrie hin und her verschoben werden muss.

:o)Uhummel

2007-06-16, 21:07:13

ATI bot doch schon bei der 8500er ein Feature in HW an (Trueform), das natl. stark vereinfacht der neuen Einheit in einigen Punkten ähnelt,oder?.-Deshalb wahrschl. auch 2nd Generation ... Trueform: http://www.3dconcept.ch/artikel/npatches/2.htm

R300

2007-06-17, 23:07:49

Richtig, aber der Nachteil von Truform der 8500 war, dass die Objekte aufgeblasen wurden. Also Objekte, die gleichzeitig Rundungen und Ecken enthielten waren nicht so einfach möglich, weil die Ecken von Truform rund gemacht wurden.
Vllt hat sich das deshalb nicht durchgesetzt?

Gast

2007-06-18, 15:15:34

Richtig, aber der Nachteil von Truform der 8500 war, dass die Objekte aufgeblasen wurden.

und die funktionalität ist mit dem "gewöhnlichen" GS von DX10 auch erreichbar.

was kann die tesselationseinheit vom R6xx eigentlich mehr als der herkömliche GS?

Coda

2007-06-18, 15:19:17

Die Tesselationseinheit ersetz den Input-Assembler. Das ist schon noch ein Stückchen was anderes.

deekey777

2008-03-04, 19:45:28

http://ati.amd.com/developer/gdc/2008/Tessellation_in_a_Low_Poly_World.pdf

•The tessellator is available now on the Xbox 360 and the latest ATI Radeon and FireGL graphics cards.
–PC Driver available with March Catalyst release.
Seite 27.
Und wasnun?

Chris Lux

2008-03-04, 19:59:16

Und wasnun?
das ist leider nichts so aufregendes. das ist eine festverdrahtete tesselierungseinheit und nicht frei programmierbar. quadi n-patches reloaded.

AnarchX

2008-03-04, 20:07:34

Also wohl eher nichts, was man gleich für D3D11 übernehmen kann.;) ;D

Vielleicht bieten ja ein paar Xbox360 Ports entsprechende Optionen für die Radeons.

deekey777

2008-03-04, 21:07:23

Also wohl eher nichts, was man gleich für D3D11 übernehmen kann.;) ;D

Vielleicht bieten ja ein paar Xbox360 Ports entsprechende Optionen die Radeons.
Hm, Viva Pinata nutzt auf der Xbox360 die Tesselationseinheit, vielleicht wird das nachgeliefert.:)

LovesuckZ

2008-03-04, 21:12:56

Vielleicht bieten ja ein paar Xbox360 Ports entsprechende Optionen für die Radeons.

Ohne API? :confused:

AnarchX

2008-03-04, 21:15:09

Ohne API? :confused:

Hack?

http://img139.imageshack.us/img139/9556/hackek4.png (http://imageshack.us)

deekey777

2008-03-04, 21:16:22

Ohne API? :confused:
Schaue mal in die Präsentation rein, Seite 15.

Coda

2008-03-04, 21:44:34

Parhelia Revival...

Und ein paar passende Worte zu den Quads:
Displacement mapping. Sigh. I am disappointed that the industry is still pursuing any quad based approaches. Haven't we learned from the stellar success of 3DO, Saturn, and NV1 that quads really suck?

Ich hab von dem Tesselationszeug eh auch noch nie was gehalten. Das Problem ist, dass die komplette Artist-Pipeline fehlt um das zu supporten. Kein 3D-Programm kann das.

deekey777

2008-03-11, 18:31:53

http://ati.amd.com/developer/gdc/2008/Tatarchuk-Tessellation_GDC08.pdf
Seite 49.
Warum hat die HD3870 deutlich niedrigere FPS? Treiberproblem oder wurde die Tesselationseinheit geschrumpft?

reunion

2008-03-11, 18:45:50

Was ist denn eine HD 3750?

Gast

2008-03-11, 18:48:39

Was ist überhaupt Tesselation? Oo

][immy

2008-03-11, 19:17:51

Was ist denn eine HD 3750?

sind das vielleicht die FireGL Versionen?

deekey777

2008-03-11, 19:19:15

Was ist denn eine HD 3750?
Hm, darauf habe ich nicht geachtet, könnte eine 3850 sein (also ein Verschreiber)
[immy;6346607']sind das vielleicht die FireGL Versionen?
Eigentlich nicht.

Gast

2008-03-11, 19:25:06

Brauchen wir jetzt ne Tesselation Einheit oder langt es die alt herkömmlichen Teile entsprechend aufzubohren. Bis 2012 is das eh uninteressant, da keine Hardware/API vorhanden ist, und bis DX11 sich durchsetzt... wir haben ja nichtmal eine DX10 Engine bisher gesehen. Ich halte das für heiße Luft, denn erst die 4. Generation ihrer Implementierung wird wohl genutzt werden.
Aber bis dahin haben die GPUs doch soviel Power das sie eine Spezielle Recheneinheit nicht mehr brauchen, der Weg ist doch eine andere Richtung oder? (Siehe Vereinigung ROPs/SI)

Gast

2008-03-13, 10:22:24

Stand nicht in den Release Notes der 8.3-Catalysts irgendwas von Tesselation Units?

Bokill

2008-03-13, 11:30:26

Weil Sie vom C1 her schon vorhanden war, ein GS sowieso Pflicht bei D3D10 war und ATI wohl vorhat das Design zumindest bis zu D3D11 durchzuschleppen und irgendwann auf der Strecke dahin die schon fertige Einheit wohl ATIs Überlegungen nach nützlich sein wird. ... AMD hat beim Start der AMD 780 Chipsatzplattform parallel verlautbart, dass im ATI Catalyst 8.3 die Tesselations-Einheit für Entwickler auf der Radeon HD 3xxx-Familie "freigeschaltet" ist.

Das spricht vorerst gegen die These, dass die Tesselationseinheit schnell wieder aus der Nachfolgegeneration der ATI 6xx-GPUs verschwindet.

MFG Bobo(2008 )

][immy

2008-03-13, 17:33:25

Könnte man mit intelligenten algorythmen die tesslations-einheit verwenden um den speicherinhalt zu komprimieren?
also jetzt nicht texturen, aber die dreiecksinformationen

oder würde das dann zu viel leistung kosten?

Captain Future

2008-03-13, 23:30:22

Ja. Aber vermutlich nicht dynamisch, sondern die Anwendung muss eine Low-Poly-Version für den Tesselator von sich aus anbieten.

Bei XBox360-Ports sollte das ja kein Problem sein.

][immy

2008-03-14, 18:48:04

Ja. Aber vermutlich nicht dynamisch, sondern die Anwendung muss eine Low-Poly-Version für den Tesselator von sich aus anbieten.

Bei XBox360-Ports sollte das ja kein Problem sein.

naja, genau das meinte ich ja, ob man dafür nicht einen algorithmus schreiben könnte, der ein high-poly-modell automatisch runterrechnet, so das es durch die tesslationseinheit wieder in den ursprungszustand gebracht werden kann.

eine manuelle anpassung wird sich vermutlich auf dem pc nicht durchsetzen (auf einer konsole schon eher) aber wenn man eine automatik hätte, würde das ganze vermutlich anders aussehen.

Coda

2008-03-14, 19:30:14

[immy;6354814']naja, genau das meinte ich ja, ob man dafür nicht einen algorithmus schreiben könnte, der ein high-poly-modell automatisch runterrechnet, so das es durch die tesslationseinheit wieder in den ursprungszustand gebracht werden kann.
Das wird schon lange gemacht mit Normalmaps. Zumindest das Brechnen der Displacement-Maps. Das Low-Poly-Model muss der Artist aber noch selber anlegen. Der Algorithmus ist 1zu1 übertragbar.

_DrillSarge]I[

2008-03-23, 20:02:07

gibt wenigstens mal was dafür
http://ati.amd.com/developer/gpumeshmapper.html
€: die haben ja ihre tools seiten ganz schön aktualisiert

deekey777

2010-01-14, 21:23:44

Zuerst: Ich liebe es, wenn man einen Begriff falsch schreibt und die Suche deswegen nichts bringt. ;(
Catmull-Clark subdivision surfaces.

Siehe auch hier ab Seite 61 die Source-Engine-Implementation: http://www.nitianyun.com/notes_woch4.pdf

Wenn ich das richtig verstanden habe, gibt es einen Funken Hoffnung, dass wir die "R400-TU" doch in Äkschn sehen werden, wenn Valve ihr Verfahren in die Source-Engine einbauen.

Coda

2010-01-14, 21:26:20

Erm, not?

In our tests, we have often seen the instanced path perform twice as fast as the native path

deekey777

2010-01-14, 21:34:42

Erm, not?
Da habe ich zu kurz gedacht.

Wenn man davon ausgeht, dass VALVe nie mehr tut als nötig, wird die TU der Xbox360 nicht verwendet, selbst wenn diese Lösung besser wäre als die Instanced Tessellation, denn diese läuft ja überall.

Coda

2010-01-14, 21:35:50

Warum sollten sie es überhaupt verwenden, wenn es sogar langsamer ist?

deekey777

2010-01-14, 21:38:40

Warum sollten sie es überhaupt verwenden, wenn es sogar langsamer ist?
Wurde das Verfahren auf der Xbox360 angewendet?

Oder erwartest du, dass der Xenon da besser ist als eine gewöhnliche CPU?

Coda

2010-01-14, 21:42:10

Das versteh ich jetzt nicht.

deekey777

2010-01-14, 21:48:49

Das versteh ich jetzt nicht.
Na, vergiss es.
Ich hab mich vertan.
Egal, welcher Path, die CPU liefert immer die Daten an die Grafikkarte, das habe ich übersehen.

Coda

2010-01-14, 22:10:34

Naja liefern würde ich es nicht nennen. Geometriedaten liegen auch im VRAM (bei der Xbox 360 ist das natürlich das selbe wie RAM).

HarryHirsch

2010-02-05, 01:00:26

als absoluter nixblicker frag ich mich gerade wie es eigentlich mit tesselation und afr aussieht?
laufen bei afr automatisch alle verfügbaren tesselation einheiten oder nur die von einer karte?
und muss die software speziell für afr + tesselation angepasst werden?
google spuckt leider nix passendes aus.

Coda

2010-02-05, 01:27:54

Bei AFR funktioniert immer alles, weil die GPUs abwechselnd komplette Bilder bearbeiten.

Gast

2010-02-06, 15:02:06

Ich hab ein Matrox Video aus dem Jahr 2002 zur Tesselation-Funktion der Parhelia gefunden:
http://www.youtube.com/watch?v=ub8ZyUyaEww
Man glaubt es kaum, diese Technik gibt es schon seit 8 Jahren auf ganz normalen Grafikkarten.

Coda

2010-02-06, 15:03:43

Das war aber nicht programmierbar.

Gast

2010-02-06, 15:46:01

Na zumindestens hat es funktioniert. Und jeder Spieleentwickler hätte diese Funktion nutzen können inkl. hardware bump mapping und LOD. Das alles wurde über die Hardware realisiert.
Für den Anwender hätte das eine bessere Grafik in Spielen bedeutet.
Was man jetzt unter "programmierbar" im weiteren Sinne darunter versteht wird kaum einen Konsumenten interessieren.
Der Aufwand für Spiele Entwickler hält sich auch in Grenzen wenn es nur erforderlich ist eine zusätzliche High-Map mit Höheninformationen zu erstellen um ein optisch deutlich besseres Ergebnis zu erzielen.

Coda

2010-02-06, 15:55:05

Na zumindestens hat es funktioniert. Und jeder Spieleentwickler hätte diese Funktion nutzen können inkl. hardware bump mapping und LOD.
Es wurde nie ein Treiber von Matrox ausgeliefert der diese Funktionen auch wirklich anbot.

Was man jetzt unter "programmierbar" im weiteren Sinne darunter versteht wird kaum einen Konsumenten interessieren.
Nö, aber die Entwickler und IHVs. Matrox' System war für den weiten Einsatz einfach zu unflexibel.

Klar, ist es reizvoll das jetzt zu verklären, aber wirklich brauchbar war es damals wirklich nicht.

Gast

2010-02-06, 19:48:24

Keine Treiber? Woher weißt du dass so genau?
Außer der Matrox-Demo für "hardware displacement mapping" gab es ja zumindestens ein Spiel an das ich mich erinnern kann dass von HDM gebrauch gemacht hat.
In dem Spiel sollte damit die Wasseroberfläche realistischer dargestellt werden. Meiner Meinung nach war das völliger Unsinn. Das beste Anwendungsgebiet wären FPS gewesen die sich damals fast ausschließlich in engen Gängen und Räumen abgespielt haben. Damit hätte man aus flachen Texturen tatsächlich 3D-Objekte ohne viel Aufwand machen können.

Das Problem war meiner Meinung nach dass Matrox die Karte auf den Markt gebracht hat als noch DX8.1 aktuell war und gehofft hat dass ihre Funktionen in das zukünftige DX9 übernommen werden.

Auf 3D-Center gibt es eine Beschreibung der Parhelia:
http://alt.3dcenter.org/artikel/parhelia/index4.php

Und noch einmal auf Chip.de:
http://www.chip.de/artikel/3D-Features-Matrox-Parhelia-512-2_12856795.html

Ohne Unterstützung durch Direct-X bringen auch die besten Treiber nichts. Bei ATI gibt es die Tesselation mittlerweile ja auch schon in der dritten Generation.

deekey777

2010-03-24, 21:39:50

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7926141#post7926141

Wie es aussieht, nutzt(e) Heaven 2.0 RC1 den alten Tessellator unter OpenGL.
Faszinierend.

Spasstiger

2010-03-25, 01:28:53

In dem Spiel sollte damit die Wasseroberfläche realistischer dargestellt werden.
Auch wenn das Posting mehrere Wochen alt ist: Ich glaube, da bringst du was durcheinander. Vermutlich meinst du die Matrox G400, die in Expandable das Wasser mit Environment Mapped Bumpmapping renderte, was bei Nvidia erst mit der GeForce 3 1,5 Jahre später möglich war.

Coda

2010-03-25, 02:58:42

Ohne Unterstützung durch Direct-X bringen auch die besten Treiber nichts. Bei ATI gibt es die Tesselation mittlerweile ja auch schon in der dritten Generation.
Das ganze ist in DirectX 8 enthalten, es gab aber nie Treiber+Hardware auf der es gelaufen wäre.

Ich war auch sehr erstaunt als mich das mal in der Dokumentation angeschaut hat.

Ailuros

2010-03-25, 07:15:09

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7926141#post7926141

Wie es aussieht, nutzt(e) Heaven 2.0 RC1 den alten Tessellator unter OpenGL.
Faszinierend.

Technisch "faszinierend" vielleicht, aber man braucht auch eine Unmenge an Geduld fuer den gesamten Ablauf der timedemo.

Wem die Unterschiede zwischen displacement mapping und Tessellation nicht klar sind sollte sich bitte dementsprechend richtig informieren. Es geht hier im Thread um Tessellation und dabei wird es auch bleiben.

Und wer sich dann erstmal bemueht etwas besser nachzuforschen kann vielleicht herausfinden warum parallax mapping (oder anders "virtual displacement mapping") von vielen Entwicklern als Methode bevorzugt wurde.

So und jetzt zurueck zum Thema bitte.

mboeller

2010-03-25, 07:29:12

aus dem Beyond3D-Forum:

Hi. I'm NoahDiamond, from the OCN forums. Yes, the engine uses CUDA calls. No, the engine does not support 64-bit. Yes, it is nVidia optimized, no it won't break any records. The Unigine is poorly written, and depends on only a handful of custom libraries.

Replication is a feature used for graphics processors below Directx 11 that can gain a performance boost. Some cards support it native, and others do not. The HD 5000 series does, but it is not readily activated. You can activate it in either the .bat files, or by starting up the benchmark, pressing the ~ (tilde) key, and entering the following command.

d3d11_render_use_replication 1

You can simply enter d3d11_render_use_replication to see if the feature is active.

"PSSM shadow geometry replication by geometry shader (controlled by the folowing console variables: gl_render_use_geometry_replication, d3d10_render_use_replication, d3d11_render_use_replication)."

It is a shortcut in rendering shadows, and can cause artifacts in the current release of Heaven 2.0 Benchmark. When benchmarking against cards that cannot properly handle this feature, it can cause artifacts in shadow areas, and can cause shadows to clip in and out, depending on the cache usage of the GPU.

The 5870/5970 cards handle it rather well due to their cache use, but it is really written for the Fermi cards that have separate cache levels to store instructions.

As for Tessellation... Voxels (volumetric pixels) are a more efficient method of rendering complex details, saves an ENORMOUS amount on processing power and memory, and can be run directly on dedicated tessellation units. Tessellation was a great idea, but it requires separate model and texture sets, as seaming is a problem when they don't exist as a duality in the program data sets. To avoid seaming gaps, the models/textures need to overlap, and Unigine are not bothered by that issue.

The tessellation seam gap problem is not existent in the 4A engine used in Metro 2033, Dirt 2 or Aliens vs. Predator 2010. The authors of these programs took the issue into account and worked with the functions of Tessellation.

The id Tech 5 engine took a different approach, and is still an amazing looking engine to this day. I don't want to sound like a John Carmack fanboy, but he does take his time in writing his software, and the id Tech Engines have always been on top of the charts, using existing technology.

Fermi will ROCK in the Unigine Heaven benchmarks, but it won't be anything in the real world, as the engine does not take into account that Tessellation, Physx, Render and Shader processes all have to work on the same CUDA cores together.

.......[Den Rest des Rants spare ich mir]

Link: http://forum.beyond3d.com/showpost.php?p=1412624&postcount=77

Da findet jemand Tesselation nicht besonders gut. Er steht anscheinend mehr auf Voxel. Seine Anmerkungen zu dem angeblich schlecht geschriebenen Heaven1.0-2.0 Benchmark passen aber IMHO hier rein. Wenn es jemand anders sieht, bitte löschen.

Aquaschaf

2010-03-25, 08:45:01

Das läßt sich aber kaum vergleichen. Mit voxels ließen sich z.B. nicht so einfach animierte Charaktere darstellen. Voxel sind eventuell was für Terraindarstellung, für viel mehr denke ich nicht.

LovesuckZ

2010-03-25, 10:12:49

aus dem Beyond3D-Forum:

Link: http://forum.beyond3d.com/showpost.php?p=1412624&postcount=77

Da findet jemand Tesselation nicht besonders gut. Er steht anscheinend mehr auf Voxel. Seine Anmerkungen zu dem angeblich schlecht geschriebenen Heaven1.0-2.0 Benchmark passen aber IMHO hier rein. Wenn es jemand anders sieht, bitte löschen.

Ist unsinn. Der Typ hat auch behauptet, er hätte ein GF100 und machte folgendes Bild: http://www.xtremesystems.org/forums/showthread.php?p=4245674#post4245674

moBi

2010-03-25, 16:35:14

Was drückt eigentlich mehr auf die Performance: Das Tesselieren an sich, oder das Rendern der dadurch entstandenen vielen kleinen Dreiecke?

Ich hab mal irgendwo gelesen, oder in einem Video gehört, dass Supreme Commander 1&2 so eine Art software Tesselation macht, damit man beim Zoomen keine spontanen Übergänge hat. Weiß hier jemand mehr? Falls das stimmt, ist wohl der erste sinnvolle Einsatz von Tesselation auf dem PC.

Gast

2010-03-25, 21:38:44

Das ganze ist in DirectX 8 enthalten, es gab aber nie Treiber+Hardware auf der es gelaufen wäre.

Gab es nicht auf der Geforce3 auch schon irgendeine Form von Tesselation (R-Patches oder so ähnlich)?

Gast

2010-03-25, 21:46:18

Was drückt eigentlich mehr auf die Performance: Das Tesselieren an sich, oder das Rendern der dadurch entstandenen vielen kleinen Dreiecke?

Hängt von der Hardware ab, auf RV870 auf jeden Fall die kleinen Dreiecke, bei Fermi könnte es anders sein, aber auch er verliert an Effizienz durch kleine Dreiecke, auch wenn das natürlich durch das mehrfache Tri-Setuap ausgeglichen wird.

Ich hab mal irgendwo gelesen, oder in einem Video gehört, dass Supreme Commander 1&2 so eine Art software Tesselation macht, damit man beim Zoomen keine spontanen Übergänge hat.

Schon möglich, wäre auch nicht das erste Mal. Wenn ich mich recht erinnere hat Messiah als eines der ersten Spiele den Detailgrad der Modelle dynamisch berechnet. So richtig gut war das aber nicht, es kostete viel Performance und man hatte natürlich keine LOD-Sprünge, dafür aber ein ständiges "wabbern"

Coda

2010-03-25, 21:53:21

Das läßt sich aber kaum vergleichen. Mit voxels ließen sich z.B. nicht so einfach animierte Charaktere darstellen. Voxel sind eventuell was für Terraindarstellung, für viel mehr denke ich nicht.
Man braucht für Tesselation auch keine anderen Models, und wie er drauf kommt dass man mit Tesselation Voxels rendern kann versteht auch kein Mensch.

Und das Voxel Speicher sparen ist auch sehr gewagt.

VinD

2010-03-25, 22:30:00

Gab es nicht auf der Geforce3 auch schon irgendeine Form von Tesselation (R-Patches oder so ähnlich)?

"Adaptive Tesselation

Adaptive Tesselation nennt man ein Verfahren, welches den Detailgrad von N-Patches, RT-Patches oder andere HOS (Higher Order Surfaces) in Abhängigkeit von x,y,z, oder / und w verändert. Leider ist hier noch kein Hardwaresupport bei den Herstellern zu finden. Zwar sollten die Radeon 9500/9700 und die Matrox Parhelia dazu in der Lage sein, bisher wird dieses Feature jedoch noch nicht mit den DirectX 9.0 Treibern unterstützt."

Nach dem Laden der Google-Suchergebnisse sofort gefunden ;)

http://www.tommti-systems.de/go.html?http://www.tommti-systems.com/main-Dateien/previews/dx9/NV30_R300_DX9_overview.html

Gast

2010-03-26, 00:36:14

Gab es nicht auf der Geforce3 auch schon irgendeine Form von Tesselation (R-Patches oder so ähnlich)?

Es gab auch schon zu DX8 Zeiten auf der R8500 einen ersten Versuch mit Tesselation. Wurde damals Truform getauft und hat zum Beispiel in Counter Strike die Helme abgerundet (und auf hoher Stufe ein paar Waffen zu Blechtonnen aufgeblasen X-D).

Schade, dass das damals nicht weiter verfolgt wurde.

deekey777

2010-03-26, 14:16:20

Technisch "faszinierend" vielleicht, aber man braucht auch eine Unmenge an Geduld fuer den gesamten Ablauf der timedemo.

Wenn die Tessellation ins Bild kommt, bricht die Framerate tatsächlich auf 4-5 fps. Warum eigentlich?
Die Frage klingt irgendwie kindisch, aber wird wirklich der alte Tessellator benutzt? Im Vergleich zur DX11-Tessellation ist das eine ganz andere Rendering-Pipeline (unter OpenGL 4.0 wohl auch?). Der alte Tessellator beherrscht maximalen Tessellationsfaktor 15, während der neue bis 64 geht. Da frage ich mich die ganze Zeit, wie das möglich ist: Man bekommt unter OpenGL mit dem alten Tessellator die gleiche Tessellation wie mit dem neuen Tessellator unter DX11? Geht Heaven etwa nicht über max. TF von 15 nicht hinaus? Oder läuft die Tessellation gar über die CPU?

deekey777

2010-05-21, 23:38:14

(Oh Mann, gibt es aktuell lustige Sachen über Tessellation, Streamprocessors und Cat. 10.5...).

Frage aus Faulheit: Kennt jemand die nackten Zahlen einer HD5800 in der Froblins-Demo sowie DX9-Tessellation-Demos im Vergleich zu HD4800?

Coda

2010-05-22, 08:51:46

Die Frage klingt irgendwie kindisch, aber wird wirklich der alte Tessellator benutzt? Im Vergleich zur DX11-Tessellation ist das eine ganz andere Rendering-Pipeline
Nein ist es nicht - das habe ich dir schonmal versucht zu erklären.

Es ist die selbe Hardwareinheit. Die "alte" Tesselation wird unter OpenGL nur auf Faktor 15 begrenzt, damit der Code auch auf alten Radeons noch läuft.

Sowas ist üblich. Du kannst per fixed function auch auf einem Fermi nur mit vier Texuren Multitexturing machen, obwohl der Chip theoretisch mindestens 128 binden und diese beliebig oft samplen kann.

Deine Quelle hat es schlicht und einfach falsch interpretiert.

(Oh Mann, gibt es aktuell lustige Sachen über Tessellation, Streamprocessors und Cat. 10.5...).
Ja. Verdammt viel Blödsinn. Da lang ich mir echt an den Kopf wenn ich es lese.

Nein HD5000 hat keine "versteckten" Tesselatoren und nein NVIDIA macht auch keine Tesselation mit den Streamprozessoren.

deekey777

2010-05-22, 09:42:34

Da hat sich Geeks3D vertan.
Bezüglich Unigine:
http://forum.beyond3d.com/showpost.php?p=1414107&postcount=90
In theory they needn't be different, from what I've seen in their DX11 shaders they don't go beyond 15x amplification so the old tessellator should be "compliant". However, it'll be less efficient since you have to perform some R2VB shenanigans to emulate the HS and DS. Also, I don't think their OGL implementation is as robust as the DirectX one to start with, at least not yet, since performance doesn't seem equivalent, at least in my brief experience.
(Die Antwort kam einen Tag später nach meiner Frage in diesem Thread)

Hier sind einige Zahlen der Radeons in Terrain-SDK-Sample: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=457346
Da fehlt wirklich nur noch ein Vergleich mit gleichem Chiptakt. Ich hab das Gefühl, dass sich die Radeons (egal ob HD2900 oder HD5870) nichts nehmen und in etwa die gleiche Performance liefern.