Variablen in HLSL

[TGGC]

dot schrieb:

[...]und hat das Problem entschärft...

Eben hast du noch behauptet, es gaebe Probleme nur mit Vegetation. Die Vegetation macht Optimierungen schwieriger, ist aber nicht der Grund des Problems.

Zeug zeichnen macht das Zeichnen langsamer. "Ich zeichne Zeug und das zeichnen wird langsamer, da ist was falsch?" - ach nein wirklich... f'`8k

Gruß, TGGC (der kostenlose DMC Download)

[Ishildur]

@dot

Die Screenshots sind recht dunkel

Es ist ja auch unter Wasser

Diese Screenshots sind nun mit ausgeschaltetem Alphablending entstanden (also nur Alphatesting), dadurch könnte man IMHO auch Front-To-Back rendern.

ich würde mal meinen dass hier kaum alle 9216 Pflanzen ständig sichtbar sind!?

Das ist leider völlig korrekt, ich würde mit einem viertel der Pflanzen auskommen, wenn ich nur diejenigen Zeichnen würde, die auch tatsächlich sichtbar sind. Das Problem ist, dass es überhaupt nichts gebracht hatte, weil der Flaschenhals im Moment noch das Zeichnen an sich ist (Wie du sagtest, schaue ich senkrecht von oben darauf, habe ich ca. 350 fps). Und der CPU Overhead um zu berechnen, welche Planzen sich im View befinden ist ziemlich gross (lohnt sich IMHO meistens nur dann, wenn man wenige Objekte mit viel Geometry hat).

Hat man sehr viele Objekte mit sehr wenig Geometry (wie in diesem Fall) ist es IMHO besser, das Culling von der Graka durchführen zu lassen.

Was ich allerdings versuchen könnte währe wie gesagt eine räumliche sortierung von Front-To-Back um zu sehen, um den Overdraw auf ein Minimum zu beschränken.

[Ishildur]

@TGGC
Ich empfehle dir diesen Artikel: developer.nvidia.com/docs/IO/8343/Performance-Optimisation.pdf

Danach wirst du sehen, dass "Zeug zeichnen" nicht gleich "Zeug zeichnen" ist und dass sich die resultierende Performance aus ganz unterschiedlichen Aspekten zusammensetzt (es gibt durchaus auch Situationen wo man mehr zeichnen kann, ohne den geringsten Performanceverlust, wenn man die momentan am meisten ausgelastete Stelle nicht noch zusätzlich beansprucht), also ist deine Pauschalaussage : "Zeug zeichnen macht das Zeichnen langsamer." IMHO einfach falsch!

Ausserdem ich unterhalte mich gerade so gut mit Dot, ich glaube mit ihm werde ich eine Lösung finden

[dot]

Ishildur schrieb:

Diese Screenshots sind nun mit ausgeschaltetem Alphablending entstanden (also nur Alphatesting), dadurch könnte man IMHO auch Front-To-Back rendern.

Wenn die Artefakte tolerierbar sind wäre das natürlich eine Option. Man müsste mal ausprobieren wieviel sich dadurch gewinnen lässt.

Ishildur schrieb:

Das Problem ist, dass es überhaupt nichts gebracht hatte, weil der Flaschenhals im Moment noch das Zeichnen an sich ist (Wie du sagtest, schaue ich senkrecht von oben darauf, habe ich ca. 350 fps). Und der CPU Overhead um zu berechnen, welche Planzen sich im View befinden ist ziemlich gross (lohnt sich IMHO meistens nur dann, wenn man wenige Objekte mit viel Geometry hat).

Das ist im allgemeinen schon richtig, vor allem da diese Optimierung in erster Linie für das Vertexprocessing was bringen würde das hier nicht direkt das Limit ist. Wenn du allerdings deine Pflanzen sowieso schon sortierst kannst du durchaus mal versuchen ob Frustrum Culling (oder zumindest ein einfacher Abstand zur Kamera Test, durch den Nebel fällt da ja in der Ferne schon vieles weg) was bringt, sofern deine CPU genug Zeit hat. Die Instanzdaten streamest du dann ja so oder so zur GPU und Culling würde dann die Datenmenge die über den Bus muss zusätzlich geringer halten...

[dot]

TGGC schrieb:

Eben hast du noch behauptet, es gaebe Probleme nur mit Vegetation. Die Vegetation macht Optimierungen schwieriger, ist aber nicht der Grund des Problems.

Ich sagte das Problem liegt vor allen in der Natur der Objekte und nicht rein in deren Anzahl. Natürlich kannst du genauso einen Haufen sich überdeckender Kisten zeichnen und hast das selbe Problem das durch die Transparenz nur noch verschärft wird. Mein Argument richtete sich aber eigentlich gegen deine ursprüngliche Aussage dass es rein an der Anzahl der Objekte liegt, was hier ganz klar nicht der Fall ist. Wenn du deine 10000 Würfel anders verteilt hast siehts schon ganz anders aus, weiters sind von einem Würfel immer nur max. 3 von 6 Flächen sichtbar wodurch du schon eine viel größere Menge an Dreiecken brauchst um in mit der Vegetation vergleichbare Bereiche zu kommen.

Wie gesagt, es wäre mit Sicherheit kein Problem auf seinem Rechner 9216 andere "Objekte" mit gleicher Anzahl an Dreiecken viel schneller zu rendern, was meine urspüngliche Aussage war...

[TGGC]

Ich habe auch nicht behauptet, das es an der Zahl der Objekte liegt. Ich sagte nur, das die Fauna nicht einem komplexen Objekt entspricht, nur weil sie wenig Vertices hat und in einem Call gezeichnet wird.

Ishildur schrieb:

Danach wirst du sehen, dass "Zeug zeichnen" nicht gleich "Zeug zeichnen" ist und dass sich die resultierende Performance aus ganz unterschiedlichen Aspekten zusammensetzt (es gibt durchaus auch Situationen wo man mehr zeichnen kann, ohne den geringsten Performanceverlust, wenn man die momentan am meisten ausgelastete Stelle nicht noch zusätzlich beansprucht), also ist deine Pauschalaussage : "Zeug zeichnen macht das Zeichnen langsamer." IMHO einfach falsch!

Das ist mir alles bekannt aber in dem Falle irrelevant da unzutreffend. Deine Pflanzen brauchen 10ms zum rendern, weil deine GraKa 10ms braucht um sie zu rendern - nicht weil du was falsch machst. Wenn es schneller sein soll, musst du weniger rendern. end of story. f'`8k

Gruß, TGGC (der kostenlose DMC Download)

[dot]

TGGC schrieb:

Ich habe auch nicht behauptet, das es an der Zahl der Objekte liegt. Ich sagte nur, das die Fauna nicht einem komplexen Objekt entspricht, nur weil sie wenig Vertices hat und in einem Call gezeichnet wird.

Tut mir leid da hast du natürlich recht, dann habe ich das

TGGC schrieb:

Wie kommst du darauf, das dein Rechner bei 9216 anderen Objekten, die gezeichnet werden, schneller waere? f'`8k

wohl falsch verstanden...

TGGC schrieb:

Deine Pflanzen brauchen 10ms zum rendern, weil deine GraKa 10ms braucht um sie zu rendern - nicht weil du was falsch machst. Wenn es schneller sein soll, musst du weniger rendern. end of story. f'`8k

Das haben wir auch anfangs schon festgestellt und suchen jetzt einen Weg damit es weniger als 10ms werden. "Weniger rendern" ist dabei eine relativ schwammige Aussage und kann (wie eben gerade von mir) wohl sehr leicht missverstanden werden, vor allem aber bietet sie keine direkte Lösung für sein Problem...

[Ishildur]

@TGGC

Deine Pflanzen brauchen 10ms zum rendern, weil deine GraKa 10ms braucht um sie zu rendern - nicht weil du was falsch machst

Ich bin eben der Meinung, dass es nicht ganz so einfach ist. "Meine GraKa braucht 10ms um sie zu rendern, OK, ABER unter den aktiven Umständen und Bedingungen.

Wenn ich jetzt bspw. den Systembus (an einer ganz anderen Stelle) total überlade, dann braucht meine Graka plötzlich 30ms, um diese 9216 Pflanzen zu rendern. Genauso gut ist es möglich, dass meine Graka diese Planzen bspw. mit anderen Renderstates, andere Sortierung, andere Reihenfolge, anderes Caching usw. in 5ms zeichnen kann... Und genau nach solchen möglichen Ansätzen suchen wir

[Ishildur]

@Dot
Ich glaube wirklich es findet ein massivstes Overdraw statt. Ein einziges zusätzliches tex2D im Pixelshader und die Framerate hat sich von 80fps auf 30fps reduziert

[TGGC]

Nein, das war eine Frage. Und die Antwort war (uebersetzt): "Ich erwarte nicht das 10000 Objekte schnell gezeichnet werden. Aber ich erwarte das meine Pflanzen 10000mal so schnell wie ein Objekt gerendert werden."

Die Pflanzen wurden nie langsam gezeichnet - es wurde erwartet, das sie unrealistisch schnell gezeichnet werden. Geht ja jetzt schon wieder los, "kann ich nicht einfach irgendein Flag setzen?!". Ja klar, ATI und nVidia haben da doch dieses "SCHNELL_RENDERN_FUER_ISHILDUR" Flag, das man nur auf true setzen muss. Bevor ich dann jemanden Tips gebe, moechte ich erstmal mitteilen, er hat falsche Erwartungen.

Wenn das schneller sein soll (warum ueberhaupt, 80fps ist doch ok), hilft nur prinzipiell weniger rendern und zwar weniger Pixel (das es nicht an Vertices on/offscreen liegt wurde ja genug breitgewalzt, keine Ahnung warum das immer noch in Frage steht). Und dann muss man halt sich der moeglichen Einschraenkungen klar werden, die sich daraus ergeben muessen:
- weniger Aufloesung (aka "SCHNELL_RENDERN_FUER_ISHILDUR" Flag)
- weniger Pixel pro Tri
- weniger Tris
- Pixel, die nicht gezeichnet werden (und daher auch nirgendswo mehr durchscheinen koennen)

Entweder gibts also gezeichnete Pixel, die am Ende unsichtbar sind oder die Optik auf dem Screen muss sich aendern. f'`8k

Gruß, TGGC (der kostenlose DMC Download)

[dot]

Naja das sagt nicht wirklich dass es am Overdraw liegt aber du bist definitiv Pixelbound. D.h. es gilt in erster Linie die Anzahl der Pixelfragmente zu reduzieren. Ich denke mal nicht dass du einen wirklich komplexen Shader auf den Pflanzen hast sodass man dort irgendwie was sparen könnte um einen merkbaren Geschwindigkeitsgewinn zu erzielen?

[dot]

TGGC schrieb:

Die Pflanzen wurden nie langsam gezeichnet - es wurde erwartet, das sie unrealistisch schnell gezeichnet werden. Geht ja jetzt schon wieder los, "kann ich nicht einfach irgendein Flag setzen?!". Ja klar, ATI und nVidia haben da doch dieses "SCHNELL_RENDERN_FUER_ISHILDUR" Flag, das man nur auf true setzen muss. Bevor ich dann jemanden Tips gebe, moechte ich erstmal mitteilen, er hat falsche Erwartungen.

Wenn das schneller sein soll (warum ueberhaupt, 80fps ist doch ok), hilft nur prinzipiell weniger rendern und zwar weniger Pixel (das es nicht an Vertices on/offscreen liegt wurde ja genug breitgewalzt, keine Ahnung warum das immer noch in Frage steht). Und dann muss man halt sich der moeglichen Einschraenkungen klar werden, die sich daraus ergeben muessen:
- weniger Aufloesung (aka "SCHNELL_RENDERN_FUER_ISHILDUR" Flag)
- weniger Pixel pro Tri
- weniger Tris
- Pixel, die nicht gezeichnet werden (und daher auch nirgendswo mehr durchscheinen koennen)

Entweder gibts also gezeichnete Pixel, die am Ende unsichtbar sind oder die Optik auf dem Screen muss sich aendern. f'`8k

Wunderbar, dann sind wir ja sowieso die ganze Zeit schon einer Meinung
War nur nicht ganz so einfach das aus deinen Postings rauszulesen...

[rapso]

wenn du schon tage dran sitzt, hast du sicherlich schonmal einen gpu profiler laufen lassen, was genau ist das bottleneck laut profiler?

ohne dieses wissen waere jegliche optimierung ein schuss ins blaue und per try&error zu optimieren koennte dich tage ohne fortschritt kosten... emm.

:schland:

[Ishildur]

@dot
Nein der Pixelshader ist nicht sehr komplex (habe auch mal die Beleuchtung abgeschaltet, aber das hat lediglich vielleicht 5fps ausgemacht).

Das hier ist der Code für die Bestimmung der Positionen der Planzen:

// check if we are almost at the bottom
 if(this->vcCnt.Y < 3000.0f){
  // declare and init local scope parameters
  float32 aPrm[4] = {this->hmSef->GetMapSize(),this->hmSef->GetMapSize()/2.0f};

  // lock the instance buffer
  uint32               sIns = this->cFlo*sizeof(FloraInstanceVertex);
  FloraInstanceVertex *pIns = 0x00;
  this->vbIns->Lock(0,sIns,reinterpret_cast<void**>(&pIns),D3DLOCK_DISCARD);

  // start a loop for walking each row
  for(uint32 i=0;i<96;++i){
   // start a loop for walking each column
   for(uint32 k=0;k<96;++k){
    // the plants have to be aligned within a fixed grid to give the
    // player the illusion that they do not move together with the camera
    float32 x = 20.0f*floorf((this->vcCnt.X-960.0f+20.0f*k)/20.0f);
    float32 z = 20.0f*floorf((this->vcCnt.Z-960.0f+20.0f*i)/20.0f);

    // add some spatial distortions (use the x and z coordinates within the cartesion space
    // as seed (this way the plants will always have the same distortions even if the camera moves)
    srand(static_cast<int32>(x*SEAFLOOR_SIZE+100*z));
    x += -20.0f+10.0f*(rand()/static_cast<float32>(RAND_MAX));
    z += -20.0f+10.0f*(rand()/static_cast<float32>(RAND_MAX));

    // finally setup the current instance
    pIns[i*96+k].Position = Vector3(x,this->hmSef->GetHeight(x,z),z);
    pIns[i*96+k].Texture  = Vector2(0.33f*floorf(3.0f*(rand()/static_cast<float32>(RAND_MAX))),0.0f);
    pIns[i*96+k].Normal   = this->hmSef->GetNormal(x,z);
   }
  }

  // unlock the instance buffer
  this->vbIns->Unlock();

Vielleicht hast du eine Idee, wie man dies sortieren könnte?
Ich habe lange versucht, mit dem Front und Right Vektor der aktiven Kamera zu arbeiten, aber dabei entstand ein Aliasing durch die Eingliederung der Pflanzen in das fixe räumliche Raster.

@TGGC
Ich hatte vor einigen Posts auf freundliche Weise versucht, dir mitzuteilen, dass ich wenig übrig habe für deine selbstinszenierenden Posts die an Überheblichkeit wohl kaum mehr zu überbieten sind, daher sage ich es nun etwas deutlicher: Du hörst dich für mich an wie ein unangenehmes Rauschen in meiner Kommunikationsleitung mit Dot...

[Ishildur]

@rapso
Naja, Tage sitze ich noch nicht drann, es handelt sich eher um Stunden, aber dein Vorschlag hört sich absolut vernünftig an. Kannst du mir einen GPU Profiler nennen, mit dem du gute Erfahrungen gemacht hast? Dann mache ich mich gleich an die Arbeit!

[dot]

Für dich wäre dann wohl der da interessant: http://developer.amd.com/gpu/perfstudio/Pages/default.aspx

Wenn du deinen Shader mal nur auf die Texturierung und sonst nichts beschränkst, wieviel Geschwindigkeit lässt sich dadurch gewinnen?

[Ishildur]

@Dot
Hmmm auf der Website steht Direct3D10, 10.1, 11 oder OpenGl3.0?? Wir arbeiten mit Direct3D9...

Das andere probiere ich gleich aus mom...

[Ishildur]

Naja, vielleicht 10fps, höchstens....
Texture Lookups hat er offenbar gar nicht gerne, der Rest scheint ihm ziemlich egal zu sein, habe sogar noch per Pixel lighting auf den Pflanzen.

// ##################################### define all needed functions #####################################
// ******************************************* function "main" *******************************************
void main(out Output Out,in float2 Tex:TEXCOORD0,in float3 Normal:TEXCOORD1,in float3 Lgt:TEXCOORD2,in float Fog:TEXCOORD3,in float Blend:TEXCOORD4){
 // simply compute the taking the fog into account
 float4 cOut = tex2D(FloraSampler,Tex);

 float3 cClr = clamp(dot(Lgt,Normal),0.2f,1.0f)*0.4f*cOut.rgb;
 float  cBld = lerp(cOut.a,0.0f,saturate(Blend));
 Out.Color   = lerp(float4(cClr,cBld),FogColor,saturate(Fog));
}
// *******************************************************************************************************
// #######################################################################################################

Ist ein riesen Hack ich weiss, ich schreibs dann schön, wenns funktioniert :p

[dot]

Oh, sry, ich ging davon aus dass es (wie sein NVIDIA Äquivalent) auch D3D9 unterstützt...

Was die Sortierung anbelangt, nimm doch einfach den Abstand zur Kamera?

[Ishildur]

Funktioniert das Nvidia Teil auch (zuverlässig) mit ATI Karten? Habe eben ein ATI Teil drinnen...