Ansatz zum Terrain-Rendering - noch Probleme beim Textur-Blending
-
mag sein.. Ich behaupte aber, dass das es ein Spezialfall ist (mal abgesehn, dass ich es eher als stumpf ansehn würde 1000 buffer mit je 1 triangle durchzulocken)..
Da du aber behauptest es gilt im Allgemeinen, musste schon beweisen, dass es für *jeden* Fall gilt bzw. unabhängig von Fall. Du wirst also schnell merken, dass deine Aussage so nicht haltbar ist
rapso schrieb:
natürlich, ist absolut unnötig und ein überbleibsel aus lowlevel zeiten. hab ich in den letzten 10jahren mit 100%iger sicherheit nicht einmal in c/c++ benutzen müssen.
ob du es glaubst oder nicht: Es gibt immernoch Leute die teilweise auf lowlevel Ebene arbeiten (müssen)..
[edit]wobei wir für nen echten test dein terrain gegen die bruteforce methode antretten lassen müßte, dann wäre es kein blosser schwanzvergleich, sondern wäre lehrreich für die user hier
wenn du Lust dazu hast, können wir das tatsächlich machen.. Kannst ja nen Bruteforce algorithmus schreiben, dann schreib ich dir ne abgespeckte version von meiner terrainengine (ohne texturierung (erstmal), belichtung etc)..
Dann kann man das ganze an unterschiedlich großen Terrains und unterschiedlichen Fehlertoleranzen (LOD) durchtesten und überprüfen, ab welcher terraingröße mein Algorithmus die Nase vorn hat (oder ob Bruteforce im Allgeimeinen besser ist :p)
-
life schrieb:
mag sein.. Ich behaupte aber, dass das es ein Spezialfall ist (mal abgesehn, dass ich es eher als stumpf ansehn würde 1000 buffer mit je 1 triangle durchzulocken)..
ich würde es schon als stumpf und verschwendung ansehen überhaupt nur ein tri in nem buffer zu haben, unter 200tris (bzw bis 64kb) werden buffer gebatched (ja, für diese locks sind treiber ausgelegt und wenn man es richtig macht, ist es dann schneller, wenn weitere eklärungen nötig sind, pingt)
life schrieb:
Da du aber behauptest es gilt im Allgemeinen,
nein, ich erleutere, dass für den fall, dass das bottleneck der polycount ist, dass dann bufferlocks pro frame sehr evil sind und genau darum dreht sich ja die loddinggeschichte hier.
Du wirst also schnell merken, dass deine Aussage so nicht haltbar ist
du wirst lesen können, dass ich mich in einem der vorherigen posts gegen solche exploitversuche meiner tatsachenaussage abgesichert habe;)
-
rapso schrieb:
life schrieb:
hm.. sagen wirs so: im allgemeinen nicht! Mag natürlich für einige spezialfälle gelten..
ist im allgemeinen so[...]!
btw. lass dann lieber den ultimaten bruteforce vs lod test machen, als diese sinnlosigkeiten fortzusetzen (so leicht kannste dich jetzt nicht mehr rauswinden :p)..
-
Wenn man sich so die ganze Systematik der rendering pipeline ansieht, muss eigentlich sofort völlig klar werden, wie evil ein Lock ist. Selbst bei meiner neuen Grafikkarte in 10 Jahren mit 1024 Vertextransformationen gleichzeitig ist der Lock immer noch genauso schlimm, weil die dann u.U. alle lahmliegen.
Optimieren bei der rendering pipeline funktioniert aber so, dass man nachschaut, was überbeansprucht wird (Pixelfüllrate, Vertextransformationen, Shader, CPU, Bus zur Grafikkarte) und dann dort für Entlastung sorgt, was an anderer Stelle wieder was kostet. Beispielsweise kostet Backface Culling bei den Vertextransformationen zusätzlich für die Tests, entlastet dann aber den Rasterizer und die Beleuchtungsberechnung. Man versucht also, alle Komponenten gleichmäßig auszulasten.
Was bringt es jetzt aber, durch einen Lock alles komplett lahmzulegen (ab den Vertextransformationen)? Das kann doch nur böse sein, weil ein großer Teil der Pipeline jetzt überhaupt nicht mehr ausgelastet wird und auf die lahme Kommunikation zwischen CPU und GPU warten muss. Auch mir scheint der Ansatz, manche Buffer je nach Sichtbarkeit einfach gar nicht zu rendern, vielversprechender zu sein.Davon abgesehen kann auch der Bus zur Grafikkarte zur Engstelle werden. Es ist besser, man interagiert möglichst wenig zwischen CPU und GPU. Wenn rapso das aus Erfahrung sagen kann und mir das aus meinem theoretischen Wissen schon völlig einleuchtet, ist der Fall für mich klar.
-
Btw. danke für eure Informationen bzgl. des Terrain-Renderings. Ich schau mir am Wochenende das mit den Blendmaps noch an und dann entscheide ich, was ich wie mache.
-
Es hindert dich niemand die kompletten Vertexdaten in die GPU zu schieben, wenn du meinst das bringt den performancehit.. Ob du dabei LOD oder nicht benutzt hat damit eigentlich wenig zutun...
Wenn man meine Posts aufmerksam liest, habe ich auch gleich am anfang einräumt, dass das locken der buffer bei jedem frame sicherlich nicht die beste Lösung ist..Fakt ist aufjedenfall, dass jedes Spiel, das eine größere Landschaft beinhaltet und das ich kenne irgendeinen LOD Algorithmus benutzt und nicht das ganze mit Bruteforce zeichnet. Ob sie dabei jedesmal die buffer locken kann ich natürlich nicht beurteilen
Ich biete aber natürlich weiterhin an hier einen kleinen performancetest mein (unoptimiertes) LOD vs Bruteforce zu starten.
-
life schrieb:
...
wenn du aufmerksam gelesen hast, hast du sicher gemerkt, dass es hier nicht darum geht ob LOD verwendet werden soll oder nicht, sondern lediglich darum, dass locken von buffern und neufüttern mit daten evil/unperformant ist.
Du hattest behauptet
wo auch vieles auf die GPU verlagert wurde (z.B. auch das Geomorphing) ...Geschwindigkeithit brachte es auch nicht
wohingegen hier behauptet wird, wenn der polycount das problem ist, sind statische buffer auf der graka viel performanter als LOD mit der cpu (und bufferlocks):
ein wenig culling und meshlods kommt man wohl besser weg als buffer per cpu zu manipulieren.
btw. hätten wir beim performancetest aufgrund von lodding das problem die gleiche qualität zu erreichen um objektiv die framerate testen zu können.
-
rapso schrieb:
wenn du aufmerksam gelesen hast, hast du sicher gemerkt, dass es hier nicht darum geht ob LOD verwendet werden soll oder nicht, sondern lediglich darum, dass locken von buffern und neufüttern mit daten evil/unperformant ist.
natürlich sollte man nach möglichkeit locks vermeiden soweit möglich (hab nie etwas anderes behauptet).. Es gibt allerdings Fälle, bei denen man ohne locks nicht sinnvoll auskommt. Nichts anderes behaupte ich..
Du hattest behauptet
wo auch vieles auf die GPU verlagert wurde (z.B. auch das Geomorphing) ...Geschwindigkeithit brachte es auch nicht
Das ist keine Behauptung, sondern eine Tatsache. Wenn du willst, kannste dir den Sourcecode selber runterladen (zu finden auf meiner HP) und es gerne einmal auf deinem PC durchtesten.
Vielleicht hätte ich besser schreiben solln, dass des den Geschwindigkeitshit bei mir zumindest nicht brachte.. Mag sein, dass du mich da missverstanden hast..btw. hätten wir beim performancetest aufgrund von lodding das problem die gleiche qualität zu erreichen um objektiv die framerate testen zu können.
Natürlich. Deswegen schrieb ich auch, dass man es mit unterschiedlichen Fehlertoleranzen für die LODs testen müsste (aufmerksam lesen etc.)..
-
life schrieb:
natürlich sollte man nach möglichkeit locks vermeiden soweit möglich (hab nie etwas anderes behauptet).. Es gibt allerdings Fälle, bei denen man ohne locks, nicht sinnvoll auskommt. Nichts anderes behaupte ich..
du hast behauptet, dass du trotz locken in jedem frame keinen geschwindigkeitsverlust hast.
Das ist keine Behauptung, sondern eine Tatsache. Wenn du willst, kannste dir den Sourcecode selber runterladen (zu finden auf meiner HP) und es gerne einmal auf deinem PC durchtesten.
Vielleicht hätte ich besser schreiben solln, dass des den Geschwindigkeitshit bei mir zumindest nicht brachte.. Mag sein, dass du mich da missverstanden hast..wenn das performanceproblem bei dir nicht der polycount sondern etwas anderes ist, wirst du den stall der graka natürlich kaum bemerken bei dir.
Deswegen schrieb ich auch, dass man es mit unterschiedlichen Fehlertoleranzen für die LODs testen müsste (aufmerksam lesen etc.)..
aufgrund des loddings ist kein _objektiver_ vergleich möglich (mitdenken).
-
rapso schrieb:
du hast behauptet, dass du trotz locken in jedem frame keinen geschwindigkeitsverlust hast.
korrekt
wenn das performanceproblem bei dir nicht der polycount sondern etwas anderes ist, wirst du den stall der graka natürlich kaum bemerken bei dir.
huch? Jetzt behaupteste ja das gleiche!
Deswegen schrieb ich auch, dass man es mit unterschiedlichen Fehlertoleranzen für die LODs testen müsste (aufmerksam lesen etc.)..
aufgrund des loddings ist kein _objektiver_ vergleich möglich (mitdenken).
selbstverständlich ist ein objektiver vergleich möglich. Man muss nur entsprechend die Fehlertoleranz festlegen/berücksichtigen.
Für einen 1:1 Vergleich, könnte man einfach die Fehlertoleranz auf 0 setzen und würde wohl so das Ergebnis erhalten, dass Bruteforce in dem Fall schneller ist.
Bei einem anderen Vergleich, könnte man festlegen, dass die Fehlertoleranz bei 100 Pixel bei einer Auflösung von 800*600 liegen soll und würde so feststellen, dass Bruteforce für terrains ab der Größe von n x n langsamer ist.
Was ist daran jetzt nicht objektiv deiner Meinung nach?
-
life schrieb:
rapso schrieb:
du hast behauptet, dass du trotz locken in jedem frame keinen geschwindigkeitsverlust hast.
korrekt
und da scheiden sich deine welt und die welt der leute die angeben wie gpus zu coden sind (z.b. treiber und hardwareentwickler), für das scenario von trianglelimitierung durch hochen polycount.
life schrieb:
wenn das performanceproblem bei dir nicht der polycount sondern etwas anderes ist, wirst du den stall der graka natürlich kaum bemerken bei dir.
huch? Jetzt behaupteste ja das gleiche!
klar behaupte ich das gleiche wie schon die ganze zeit? wieso sollte ich meine meinung auch ändern, nur weil du die geometrie loddest obwohl deine performance woanders verloren geht? das zeigt doch nur dass dein benchmark nicht die locks bzw triangleleistung gebenched hat, sondern... was auch immer dein bottleneck ist. somit ist deine behauptung dass locks pro frame (bei tri-limitierten scenarien) OK wären ohne fundament.
selbstverständlich ist ein objektiver vergleich möglich. Man muss nur entsprechend die Fehlertoleranz festlegen/berücksichtigen.
Für einen 1:1 Vergleich, könnte man einfach die Fehlertoleranz auf 0 setzen und würde wohl so das Ergebnis erhalten, dass Bruteforce in dem Fall schneller ist.
Bei einem anderen Vergleich, könnte man festlegen, dass die Fehlertoleranz bei 100 Pixel bei einer Auflösung von 800*600 liegen soll und würde so feststellen, dass Bruteforce für terrains ab der Größe von n x n langsamer ist.und dann würden wir uns hier weiter streiten, nicht was schneller ist, sondern wieviel pixel tollerierbar wären und hätten am ende außer der weiterführung von meinungsstreits kein ergebnis.
Was ist daran jetzt nicht objektiv deiner Meinung nach?
wie ich schon sagte, LODs kann man nicht objektiv beurteilen, bis auf polycount und framerate wüst ich nichts objektives.
-
rapso schrieb:
und da scheiden sich deine welt und die welt der leute die angeben wie gpus zu coden sind (z.b. treiber und hardwareentwickler), für das scenario von trianglelimitierung durch hochen polycount.
trianglelimitierung durch hochen polycount? hä?.. Ist auch egal. Ich weiß, dass es kein großen Performanceunterschied brachte und hab auch schon die bottlenecks aufgezählt, die ich dafür verantwortlich mache. Vielleicht liegen die Gründe auch ganz wo anders vergraben, aber eine Tatsache bleibt eine Tatsache und hat nichts mit "Meinung" zutun.
Wenn ich jetzt sage, dass es in meiner Wohnung zur Zeit dunkel ist, kommste ja auch nicht dahergelaufen und behauptest, dass das garnicht sein könnte, wenn man sich mal anschaut wieviel licht die sonne produziert und es in Paderborn grad mitten am Tag ist und du weiterhin dir schon Satellitenfotos angeschaut hast und die mit 10 Experten der Lichtforschungsfakultät kurzgeschlossen hast, ob es bei dieser Wolkenformation in meiner Wohnung dunkel sein könnte. Vielleicht warn die Vorhänge aber auch nur zugezogen ...somit ist deine behauptung dass locks pro frame (bei tri-limitierten scenarien) OK wären ohne fundament.
jaja.. aufmerksamen lesen ist wohl nicht deine stärke
und dann würden wir uns hier weiter streiten, nicht was schneller ist, sondern wieviel pixel tollerierbar wären und hätten am ende außer der weiterführung von meinungsstreits kein ergebnis.
warum streiten? Einfach die Meßergebnisse veröffentlichen und dann kann sich jeder selbst überlegen, wieviel Fehlertoleranz für ihn akzeptabel ist. Mit dem Messergebnissen kann er dann nämlich *objektiv* entscheiden, welcher Algorithmus in diesem Fall besser/schneller ist.
-
life schrieb:
rapso schrieb:
und da scheiden sich deine welt und die welt der leute die angeben wie gpus zu coden sind (z.b. treiber und hardwareentwickler), für das scenario von trianglelimitierung durch hochen polycount.
trianglelimitierung durch hochen polycount? hä?..
zu deiner aufklärung: man kann auch tri-limitiert sein durch z.b. lange shader, da ist dann der polycount nicht das limitierende, sondern instruction/poly-count
Ist auch egal. Ich weiß, dass es kein großen Performanceunterschied brachte und hab auch schon die bottlenecks aufgezählt, die ich dafür verantwortlich mache. Vielleicht liegen die Gründe auch ganz wo anders vergraben, aber eine Tatsache bleibt eine Tatsache und hat nichts mit "Meinung" zutun.
dann sind all deine aussagen bisher ja wertlos, du hast zwar lodding für die geometrie durchgeführt, jedoch war die geometrie garnicht das problem bei dir. daher sind deine aussagen betreffend "lock jedes frame ist ok" leider void.
Wenn ich jetzt sage, dass es in meiner Wohnung zur Zeit dunkel ist, kommste ja auch nicht dahergelaufen und behauptest, dass das garnicht sein könnte, wenn man sich mal anschaut wieviel licht die sonne produziert und es in Paderborn grad mitten am Tag ist und du weiterhin dir schon Satellitenfotos angeschaut hast und die mit 10 Experten der Lichtforschungsfakultät kurzgeschlossen hast, ob es bei dieser Wolkenformation in meiner Wohnung dunkel sein könnte. Vielleicht warn die Vorhänge aber auch nur zugezogen ...
wenn du behauptest, dass es egal für die helligkeit deiner wohnung ist, ob du deinen lichtschalter betätigst oder nicht, weil es gleich dunkel bleibt wo dir alle experten widersprechen und nach 4seiten dialog sagst du dann "ist auch egal, es gibt eh keine glühbirne im haus", ist das sehr witzlos.
somit ist deine behauptung dass locks pro frame (bei tri-limitierten scenarien) OK wären ohne fundament.
jaja.. aufmerksamen lesen ist wohl nicht deine stärke
dafür ist es deine stärke seitenlang einer tatsache zu wiedersprechen mit deinen erfahrungen um dann zu sagen, dass deine erfahrungen mit dem thema nichts zu tun haben.
und dann würden wir uns hier weiter streiten, nicht was schneller ist, sondern wieviel pixel tollerierbar wären und hätten am ende außer der weiterführung von meinungsstreits kein ergebnis.
warum streiten? Einfach die Meßergebnisse veröffentlichen und dann kann sich jeder selbst überlegen, wieviel Fehlertoleranz für ihn akzeptabel ist. Mit dem Messergebnissen kann er dann nämlich *objektiv* entscheiden, welcher Algorithmus in diesem Fall besser/schneller ist.
klar, kann ich dir geben, ca 50MTris/s (ati9500pro) bis 100MTris/s(gf6800gt) an dreiecken hab ich gemessen.
-
rapso schrieb:
du hast zwar lodding für die geometrie durchgeführt, jedoch war die geometrie garnicht das problem bei dir.
die darstellung des meshes ist in der Tat nur ein Teilproblem bei der Darstellung eines Terrains. Das heißt natürlich nicht, dass dieses völlig uninteressant ist. :>
daher sind deine aussagen betreffend "lock jedes frame ist ok" leider void.
Nun definiere "ok". Ich hab nur gesagt, dass man um buffer locks bei größeren terrains nicht drumherumkommt. Das jedes frame ein lock durchzuführen nicht optimal mal, hab ich auch schon vor deiner sinnlosen Hexenjagt eingeräumt..
Worauf willst du eigentlich hinaus?wenn du behauptest, dass es egal für die helligkeit deiner wohnung ist, ob du deinen lichtschalter betätigst oder nicht, weil es gleich dunkel bleibt wo dir alle experten widersprechen und nach 4seiten dialog sagst du dann "ist auch egal, es gibt eh keine glühbirne im haus", ist das sehr witzlos.
Bitte sei doch so gut und nenne mir die Stelle, an der ich behaupte habe, dass locks die Performance nicht beinflussen.
-
life schrieb:
rapso schrieb:
du hast zwar lodding für die geometrie durchgeführt, jedoch war die geometrie garnicht das problem bei dir.
die darstellung des meshes ist in der Tat nur ein Teilproblem bei der Darstellung eines Terrains. Das heißt natürlich nicht, dass dieses völlig uninteressant ist. :>
uninterresant ist hingegen, wenn du verschiedene strategien der meshbehandlung benchest, obwohl die performance bei dir von anderen dingen bestimmt wird.
life schrieb:
daher sind deine aussagen betreffend "lock jedes frame ist ok" leider void.
Nun definiere "ok". Ich hab nur gesagt, dass man um buffer locks bei größeren terrains nicht drumherumkommt. Das jedes frame ein lock durchzuführen nicht optimal mal, hab ich auch schon vor deiner sinnlosen Hexenjagt eingeräumt..
Worauf willst du eigentlich hinaus?dass man nicht jedes frame locken sollte, wenn es sich vermeiden lässt, weil es sehr viel performance kostet.
life schrieb:
wenn du behauptest, dass es egal für die helligkeit deiner wohnung ist, ob du deinen lichtschalter betätigst oder nicht, weil es gleich dunkel bleibt wo dir alle experten widersprechen und nach 4seiten dialog sagst du dann "ist auch egal, es gibt eh keine glühbirne im haus", ist das sehr witzlos.
Bitte sei doch so gut und nenne mir die Stelle, an der ich behaupte habe, dass locks die Performance nicht beinflussen.
klar, auch wenn wir jetzt leider festgestellt hatten, dass deine aussage void ist:
life schrieb:
rapso schrieb:
du hast behauptet, dass du trotz locken in jedem frame keinen geschwindigkeitsverlust hast.
korrekt
-
dass man nicht jedes frame locken sollte, wenn es sich vermeiden lässt, weil es sehr viel performance kostet.
Hm.. Wenn es das ist worauf du hinaus wolltest, hätteste das vielleicht gleich am Anfang genau so sagen sollen, denn hier sind wir natürlich einer Meinung (vielleicht mit dem Zusatz, dass es viel performance kosten *kann*)
Bitte sei doch so gut und nenne mir die Stelle, an der ich behaupte habe, dass locks die Performance nicht beinflussen.
klar, auch wenn wir jetzt leider festgestellt hatten, dass deine aussage void ist:
life schrieb:
rapso schrieb:
du hast behauptet, dass du trotz locken in jedem frame keinen geschwindigkeitsverlust hast.
korrekt
Ich seh den Zusammenhang jetzt nicht oO. Bei letzterem beziehst du dich ja auf einen konkreten Fall, bei dem das locken keinen großen gewschwindigkeitsunterschied zu dem nichtlocken brachte, weil, wenn man dir glauben schenken darf, der Flaschenhals woanders gelegen hat.
Aber nur weil die locks in diesem Fall unter größeren Performancebremsen untergehen, heißt das natürlich nicht, dass sie die Performance *im allgeimen* nicht negativ beinflussen.
Und die Behauptung, dass meine Behauptung "void" (wirklich bemerkenswerte Wortwahl ~~) sei, ist insofern natürlich ziemlich ironisch, da ich überhauptkeine Behauptung aufgestellt habe. Ich habe lediglich Tatsachen/Fakten vorgestellt, die du wohl offensichtlich falsch interpretiert hast.
Btw. brauchste auch nicht sinnlos posts anderer user zu löschen, nur weil sie dir nicht nach dem Mund reden...
-
life schrieb:
dass man nicht jedes frame locken sollte, wenn es sich vermeiden lässt, weil es sehr viel performance kostet.
Hm.. Wenn es das ist worauf du hinaus wolltest, hätteste das vielleicht gleich am Anfang genau so sagen sollen, denn hier sind wir natürlich einer Meinung (vielleicht mit dem Zusatz, dass es viel performance kosten *kann*)
klar hättest du machen können, statt zu sagen, dass locken jedes frame keine auswirkung hat.
life schrieb:
Bitte sei doch so gut und nenne mir die Stelle, an der ich behaupte habe, dass locks die Performance nicht beinflussen.
klar, auch wenn wir jetzt leider festgestellt hatten, dass deine aussage void ist:
life schrieb:
rapso schrieb:
du hast behauptet, dass du trotz locken in jedem frame keinen geschwindigkeitsverlust hast.
korrekt
Ich seh den Zusammenhang jetzt nicht oO. Bei letzterem beziehst du dich ja auf einen konkreten Fall, bei dem das locken keinen großen gewschwindigkeitsunterschied zu dem nichtlocken brachte, weil, wenn man dir glauben schenken darf, der Flaschenhals woanders gelegen hat.
ich kann dir auch deine behauptung auf die allgemeinheitbezogen quoten:
life schrieb:
rapso schrieb:
klar, aber mit ein wenig culling und meshlods kommt man wohl besser weg als buffer per cpu zu manipulieren.
hm.. sagen wirs so: im allgemeinen nicht! Mag natürlich für einige spezialfälle gelten..
life schrieb:
Und die Behauptung, dass meine Behauptung "void" (wirklich bemerkenswerte Wortwahl ~~) sei, ist insofern natürlich ziemlich ironisch, da ich überhauptkeine Behauptung aufgestellt habe. Ich habe lediglich Tatsachen/Fakten vorgestellt, die du wohl offensichtlich falsch interpretiert hast.
du hast behauptet,
life schrieb:
rapso schrieb:
klar, aber mit ein wenig culling und meshlods kommt man wohl besser weg als buffer per cpu zu manipulieren.
hm.. sagen wirs so: im allgemeinen nicht! Mag natürlich für einige spezialfälle gelten..
als begründung dafür gilt deine "tatsache", dass du beides probiert hast und es keinen performanceunterschied brachte. void wird das ganze jedoch, wenn das bottleneck woanders liegt.
void als wort.. emm.. ich wüste kein deutsches dass die bedeutung gut abdeckt. du hast halt ein "return void" als begründung deiner behauptung geliefert...btw. war wohl ein reflex
-
ich kann dir auch deine behauptung auf die allgemeinheitbezogen quoten:
life schrieb:
rapso schrieb:
klar, aber mit ein wenig culling und meshlods kommt man wohl besser weg als buffer per cpu zu manipulieren.
hm.. sagen wirs so: im allgemeinen nicht! Mag natürlich für einige spezialfälle gelten..
das ist ja wieder eine ganz andere Aussage. Hier behauptest du, dass locken *immer* schlechter sein *muss*. Dies ist aber natürlich nicht der Fall, da man dies einfach *nicht immer* sinnvoll vermeiden kann.
als begründung dafür gilt deine "tatsache", dass du beides probiert hast und es keinen performanceunterschied brachte. void wird das ganze jedoch, wenn das bottleneck woanders liegt.
void als wort.. emm.. ich wüste kein deutsches dass die bedeutung gut abdeckt. du hast halt ein "return void" als begründung deiner behauptung geliefert...vielleicht sollteste mal andere Literatur als die neuesten Tipps&Tricks der GPU programmierung durchlesen. Das fördert nämlich zum einen das dir offenbar fehlende Textverständnis, zum Anderen födert das auch, sofern es deutsche Literatur ist, auch den deutschen Wortschatz.
Ich denke jedenfalls, dass du mit "void" in diesem Zusammenhang "bedeutungslos" meinst.
-
life schrieb:
ich kann dir auch deine behauptung auf die allgemeinheitbezogen quoten:
life schrieb:
rapso schrieb:
klar, aber mit ein wenig culling und meshlods kommt man wohl besser weg als buffer per cpu zu manipulieren.
hm.. sagen wirs so: im allgemeinen nicht! Mag natürlich für einige spezialfälle gelten..
das ist ja wieder eine ganz andere Aussage. Hier behauptest du, dass locken *immer* schlechter sein *muss*. Dies ist aber natürlich nicht der Fall, da man dies einfach *nicht immer* sinnvoll vermeiden kann.
das fällt dir früh auf dass ich das vor ein paar seiten geschrieben hatte, vielleicht solltest du _dein_ textverständniss bzw deine aufmerksamkeit beim lesen ein wenig verbessern.
life schrieb:
als begründung dafür gilt deine "tatsache", dass du beides probiert hast und es keinen performanceunterschied brachte. void wird das ganze jedoch, wenn das bottleneck woanders liegt.
void als wort.. emm.. ich wüste kein deutsches dass die bedeutung gut abdeckt. du hast halt ein "return void" als begründung deiner behauptung geliefert...vielleicht sollteste mal andere Literatur als die neuesten Tipps&Tricks der GPU programmierung durchlesen. Das fördert nämlich zum einen das dir offenbar fehlende Textverständnis, zum Anderen födert das auch, sofern es deutsche Literatur ist, auch den deutschen Wortschatz.
Ich denke jedenfalls, dass du mit "void" in diesem Zusammenhang "bedeutungslos" meinst.du meinst, damit ich am ende auch void klugscheissen kann? *haha*
aber wenn du dich mit fremdsprachen ein wenig beschäftigen würdest, wüstest du, dass die bedeutung von wörtern viel mehr inhalt hat als die blose wortübersetzung. deswegen ist void nicht nur das, was dir ein wörterbuch liefert.
-
rapso schrieb:
aber wenn du dich mit fremdsprachen ein wenig beschäftigen würdest, wüstest du, dass die bedeutung von wörtern viel mehr inhalt hat als die blose wortübersetzung. deswegen ist void nicht nur das, was dir ein wörterbuch liefert.
die wörtliche übersetzung von "void" ist "leer" bzw. "Leere" du schlaumeier