Performance...

[tivolo]

haha, so lustig, es ist echt zum auszucken.

sitz grad vorm abgaberechner um unser spiel zu testen.
bei mir zuhause auf einer geforce 4: ~30 frames, ganz sicher fillrate-limitiert, weil er für jede lichtquelle die ich reingeb' konstant seine frames verliert.

auf dem abgaberechner, geforce FX: < 10 frames. WTF?

ich hab eigentlich geglaubt, dass NVIDIA die p-buffer unterstützung verbessert hat - offensichtlich nicht...

mfg,
tivolo

[tivolo]

ok, alles rausgeschmissen was CPU-zeit beansprucht -> geht merklich schneller.
aber meine shadowmapping und bumpmapping koordinaten muss ich doch irgendwie berechnen...*jetztkeinevertexprogrammemehrschreibe nwill*

schnellere CPU in den abgaberechner? biiiiiiiitte....

mfg,
tivolo

[Chuck]

jau die cpu auf dem abgarechner ist echt ne herausforderung :)) (insofern wird bei uns jeder kleinste mist der per vertex berechnet werden muss auf der gpu berechnet...)
trotzdem ist das ganze auch bei unserem spiel sehr langsam, weil viele dinge unabhängig voneinander animiert werden müssen und auch die spielmechanik mittlerweile einiges an rechenleistung braucht :/

[grimreaper]

*jetztkeinevertexprogrammemehrschreibenwill*ist doch noch genug zeit, und ihr seid ja eh zu 2. oder? :D

btw,... hab ich ein release-build gemacht?

ich hab ja keine ahnung wies bei euch ist, aber bei mir macht release build im gegensatz zu debug build, fast einen faktor 10 an geschwindigkeit aus (fragt mich jetzt aber nicht warum,.. hab nämlich keine ahnung warum der unterschied _so_ extrem ist)

[Chuck]

ist doch noch genug zeit, und ihr seid ja eh zu 2. oder? :D

btw,... hab ich ein release-build gemacht?

ich hab ja keine ahnung wies bei euch ist, aber bei mir macht release build im gegensatz zu debug build, fast einen faktor 10 an geschwindigkeit aus (fragt mich jetzt aber nicht warum,.. hab nämlich keine ahnung warum der unterschied _so_ extrem ist)schau dir mal die dateigröße der debug und der release exe an, dann weisst du warum :) (da wird vom neuen vc7 so viel debug info zeugs reingestopft, dass selbst die modernste cpu den dienst quittiert *g* ... war im vc6 übrigens nicht so schlimm, hat dafür allerdings auch nicht so gut debuggen können)

[grimreaper]

da wird vom neuen vc7 so viel debug info zeugs reingestopft, dass selbst die modernste cpu den dienst quittiert *g* ... war im vc6 übrigens nicht so schlimmyup, das stimmt,... aber wie gesagt,.. ein faktor 10 hat mich doch geschreckt, hab schon muffensausen bekommen, daß meine dämliche engine ne simple q3 map mit nur 50 frames rendert, wo andere über 300 haben :D
aber zum glück ist das problem aus der welt,.. bleiben no 1000000 andere,.. :tongue1:

[tivolo]

ja, alles im release-build.

habs jetzt auch g'scheit getestet:
5 lichtquellen, dynamische schatten, bumpmapping - ~ 55 frames wenn ich die models einfach rausnehm (keine berechnungen, keine animationen, werden nicht gezeichnet).

WENN ich die models aber reinnehm, dann sind die FPS kaum noch messbar :ahhh:

@vertexprogramme: ich weiss, es sind noch 3 wochen zeit. jedoch fehlt noch content, und ein paar andere sachen warten auch noch (CG23 ist ja nicht die einzige LVA)

mfg,
tivolo

[grimreaper]

[...] und ein paar andere sachen warten auch noch (CG23 ist ja nicht die einzige LVA)kenn ich,.. geht mir genauso,.. und traurigerweise bin ich allein am cg23 programmieren.
aber wenn ichs die woche noch hinkrieg die anderen idioten endlich abschießen zu können und scheibtruhen einzukaufen, bin ich,.. ähm sind wir, der 3. abgabe einen großen schritt näher :thumb:

[ChrisChiu]

ja, alles im release-build.

habs jetzt auch g'scheit getestet:
5 lichtquellen, dynamische schatten, bumpmapping - ~ 55 frames wenn ich die models einfach rausnehm (keine berechnungen, keine animationen, werden nicht gezeichnet).

WENN ich die models aber reinnehm, dann sind die FPS kaum noch messbar :ahhh:

@vertexprogramme: ich weiss, es sind noch 3 wochen zeit. jedoch fehlt noch content, und ein paar andere sachen warten auch noch (CG23 ist ja nicht die einzige LVA)

mfg,
tivolo

5 Lichtquellen find ich aber doch etwas viel... sind die während der gesamten Renderzeit aktiv?

[tivolo]

5 Lichtquellen find ich aber doch etwas viel... sind die während der gesamten Renderzeit aktiv?ja, sind sie. find ich aber nicht so arg, da für jede lichtquelle genau bestimmt wird, welche flächen sie beleuchtet, wie weit der schatten "reicht", etc. es ist also schon optimiert worden. jedesmal die ganze geometrie brute-force zeichnen wär nicht so toll :) deshalb ist es bei uns ziemlich egal, ob man z.b. 2 riiiiesige lichtquellen oder 5 kleinere nimmt - es kommt nur auf die anzahl der betroffenen flächen an.

außerdem machen dynamische lichtquellen einiges her (bewegung, flackern, etc.) - ich brauch einfach ein paar, um das ganze level auszuleuchten, da die vorberechneten lightmaps nicht mehr drin sind, weil das ganze einfach nicht gut aussieht (kein bumpmapping bei den lightmaps). desweiteren dürfts anstrengend sein, in die vorberechneten lightmaps dann die schatten für die spieler "reinzustopfen" ---> ich hab sie rausgeschmissen ;)

mfg,
tivolo

[grimreaper]

ich brauch einfach ein paar, um das ganze level auszuleuchten, da die vorberechneten lightmaps nicht mehr drin sind, weil das ganze einfach nicht gut aussieht (kein bumpmapping bei den lightmaps).nicht das ichs unterstützen würd, aber deluxemaps können genau das. (werden von q3map2 generiert, falls du das ding kennst ;] )

[tivolo]

ich weiß, ich kenn das teil.

nachteil:
- lichtquellen, dessen beleuchtung schon in der lightmap/deluxemap steckt, können nicht mehr bewegt werden (kein flackern, keine bewegung).

mfg,
tivolo

[grimreaper]

hmm,.. ja daß sich nichts bewegt und nichts flacker ist so bei statischen lichtquellen. wenn ihr nur dynamische habt hilfts nichts, klar. nur krampfhaft dynamische lichtquellen für statische zu verwenden, weil "das ist cool und d3 machts auch so" find ich nicht sinnvoll, weils vergeudete rechenzeit für nichts ist.

wie gesagt,... war nur ein vorschlag falls ihrs brauchen könnts ;]

[tivolo]

nur krampfhaft dynamische lichtquellen für statische zu verwenden, weil "das ist cool und d3 machts auch so" find ich nicht sinnvoll, weils vergeudete rechenzeit für nichts ist.
ich persönlich bin der meinung, dass dynamische lichtquellen SEHR viel an stimmung ausmachen können. wenn ich durch's freihaus renn, wo ich terroristen über'n haufen schiessen soll, dann isses net so super wenn dauernd alles beleuchtet is und ich eventuell wichtige gegenstände (wie z.b. mathematische bücher für bessere waffen) überall herumliegen seh. dann bewegt sich nämlich ausser unseren models genau GAR NIX.

zweitens: bin selber kein großer fan von D3, da das ganze
1. zu dunkel ist
2. zu sehr nach "plastik" aussieht

wenn schon, dann würd ich UE3 als "vorbild" angeben.

nichts desto trotz: wenn ich zeit hab, werd ich das ganze wahrscheinlich noch mal in erwägung ziehen und den level grundsätzlich mit statischen lichtquellen + lightmaps + deluxemaps ausleuchten, und den rest "von hand" als dyn. lichtquellen implementieren.

mfg,
tivolo

[MarianSchedenig]

wenn ich durch's freihaus renn, wo ich terroristen über'n haufen schiessen soll, dann isses net so super wenn dauernd alles beleuchtet is

Aber realistisch - im echten Freihaus ist ja auch überall Licht. ;)

Die CPU am Abgaberechner ist mir auch ein bissl unheimlich... vor allem, weil wir jetzt die World- (und teilweise View-)koordinaten für jedes Model mit der CPU berechnen, um sie sortieren zu können. Langsam ist das ganze eh immer noch (unsere Skybox alleine kostet 10 FPS, die Schatten dann noch so 40 oder so)... Seit bald zwei Wochen nur am Bugsuchen/Optimieren, dabei fehlen noch etliche Features.

Vielleicht kann man auch VSync deaktivieren am Abgaberechner? Sonst bau ich das halt ins Spiel ein, aber eigentlich sollte man das ja einfach im Treiber einstellen... beim Spieleevent ist unser Spiel doch arg langsam gelaufen, deutlich langsamer als bei mir am P3 mit mobil 800 MHz und einer Geforce 2 Go...

[tivolo]

edit hoppla als falscher user hier drinen :)

[Chuck]

so jetzt mit richtiger identität :D
ich hab jetzt grad ne schöne performance steigerung aufm abgaberechner hinlegen können (wenigstens 50 fps statt 10 mit aktivierten fragment programs) indem ich die user defined clipping planes deaktiviert habe (und im endeffekt im fragment program über den alphatest geclippt hab...). die werden nämlich scheinbar auf nv hardware nicht auf der gpu ausgewertet sondern auf der cpu, was den armen rapunzel scheinbar doch etwas überfordert *g*

insofern an alle die clipplanes drin haben denk ich mal sollten schleunigst versuchen die durch was anderes ersetzen...

[Fup]

Hi

Einige Figuren im Spiel sind mittels Milkshape animiert. Mein Problem derzeit ist, dass durch die Animation recht viel Zeit verloren geht, da er für jedes Frame die Bones durchgeht und die Matrix berechnet. Hab die Anleitungen von Nehe verwendet.

Weiß vielleicht jemand, wie man die Animation beschleunigen kann? Bzw. die Berechnung günstiger und schneller bewerkstelligt?

[tivolo]

hehe, du bist nicht allein. war gestern wieder auf dem abgaberechner und musste staunen, wie schnell ein athlon 900 bei ein paar models gleich voll beansprucht wird.

hab mir gestern eigentlich mehr performance erwartet, weil ich mittlerweile alles auf vertex-shaders umgeschrieben hab, sodass die CPU wirklich nur mehr ein einziges mal pro frame die models animiert.
fazit nach einem ärgerlichen tag gestern -> auf meiner geforce 4 rennts immer noch schneller :ahhh:

bin mit der rapunzel auch schön langsam am verzweifeln, vor allem weil die grafikkarte allein im reinen rendering ca. doppelt so schnell ist wie meine geforce 4... irgendwie traurig.

mfg,
tivolo

[grimreaper]

hmm,.. schau mal durch, was du alles auf der cpu machst, und versuch einiges wegzuschmeißen...
z.b. frustum culling (ist zwar nicht recht aufwendig ein paar bb zu testen, aber wenn die cpu so langsam ist, kann alles einen pos effekt haben... und da die graka wahrscheinlich nicht überfordert ist, dürft das kein problem sein,... dann könnte wieder der bus das problem werden, aber wenns wirklich cpu limitiert ist,.. einfach ausprobieren)

schau ob du einige dinge entweder gar nicht brauchst, oder nur für bestimmte objekte

versuche die geeigneten funktionen zu inlinen (wenn du das nicht schon getan hast,.. inlining meiner funktion die mir den camera-cluster in der map bestimmt bringt einen performancefaktor von ca 2-3...)

sonst kann ich auch nicht wirklich was sagen,.... einfach die ohren steif halten, in 1 1/2 wochen ist der spuk vorbei :D

sollte auch mal testen gehn, und schaun was meine aktuelle vers für ne performance hat, bei mir läufts durchschnittlich mit 180-200 fps...

[tivolo]

hmm,.. schau mal durch, was du alles auf der cpu machst, und versuch einiges wegzuschmeißen...
z.b. frustum culling (ist zwar nicht recht aufwendig ein paar bb zu testen, aber wenn die cpu so langsam ist, kann alles einen pos effekt haben... und da die graka wahrscheinlich nicht überfordert ist, dürft das kein problem sein,... dann könnte wieder der bus das problem werden, aber wenns wirklich cpu limitiert ist,.. einfach ausprobieren)
das frustum culling muss ich definitiv drinlassen, da die graka ansonsten viel zu viel zu tun hat.


schau ob du einige dinge entweder gar nicht brauchst, oder nur für bestimmte objekte
z.b.? meinst du beleuchtung, culling, etc.?


versuche die geeigneten funktionen zu inlinen (wenn du das nicht schon getan hast,.. inlining meiner funktion die mir den camera-cluster in der map bestimmt bringt einen performancefaktor von ca 2-3...)

ich denke mal, dass das sehr stark situationsabhängig ist. die funktion mit dem camera-cluster zu inlinen bringt bei mir genau gar nix, weil der rechner (CPU + GPU) ziemlich ausgelastet ist.


...bei mir läufts durchschnittlich mit 180-200 fps...
das waren noch zeiten :D - von solchen framerates kann ich nur träumen.

mfg,
tivolo

[grimreaper]

z.b.? meinst du beleuchtung, culling, etc.?hmm,.. z.b. physik, ai... berechnungen nur für relevante objekte, wenn das bei euch möglich ist, kann das durchaus einiges bringen

ich denke mal, dass das sehr stark situationsabhängig ist.klar,.. das kommt natürlich auf die anzahl der cluster draufan, und wie oft die funktion aufgerufen wird,.. tendenziell bringst bei mir einiges (ok,.. nicht auf der rennstrecke die ich jetzt hab, aber sonst ;) , da es einfach ein bissl bit-shiften ist, und dafür den function-call overhead wegzukriegen ist schon einiges)

weil der rechner (CPU + GPU) ziemlich ausgelastet ist.ja ok,.. wenn beides ausgelastet ist, hilft das natürlich das meiste nicht viel weil boost für den einen meistens mehr arbeit für den anderen heißt (außer man läßt bestimmte sachen ganz weg,.. siehe oben)



...bei mir läufts durchschnittlich mit 180-200 fps...
das waren noch zeiten :D - von solchen framerates kann ich nur träumennaja,.. der fairness halber muß ich schon sagen daß ich keine vertex und fragment progs habe, und die strecke recht klein ist, .. aber ich komm einfach nicht dazu viel mehr spezialeffekte einzubaun. so ein spiel allein zu machen, neben normalem uni-betrieb ist extrem schwer ,/

naja,. mal schaun,.. derzeit läuft mein partikelsystem ja auf der cpu, und da hat mein rechner hier dem ue-rechner einiges voraus,.. wahrscheinlich bringt ihn das eh in die knie hehe,.. muß ich nächste woche mal testen, sonst werden die halt einfach um ein paar tausend minimiert :D