Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mi Apr 24, 2024 12:07

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 87 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste
Autor Nachricht
BeitragVerfasst: Fr Apr 09, 2010 14:34 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
OT@Flash: Doppelpunkte werden in Unixen bei Pfadangaben gerne verwendet, um mehrere mögliche Pfade abzutrennen. Beispielsweise in der PATH-Variable (wo Ausführbare Dateien gesucht werden), steht bei mir folgendes (verkürzt):
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/horazont/bin

d.h. er sucht erst in /usr/local/bin, dann in /usr/bin, dann in /bin usw., bis er das entsprechende gefunden hat.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 09, 2010 15:47 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,

ich habe noch ein Ant-Skript angefertigt, dann wäre das Start-File zumindestens auch plattformunabhängig :P

Was mich wundert ist, das noch die alte 1.1.1 Jogl-Version benutzt wurde.
Ist der Benchmark eigentlich schon irgendwo im SVN-Repository auffindbar?

Viele Grüße
dj3hut1

P.S.: der Parameter "Djava.library.path" ist übrigens nur dafür da, daß die Native Libraries gefunden werden, nicht für die Jars ( die müssen nur im Klassenpfad sein ), also theoretisch könnte der Pfad zu der xmlBeans-Bibliothek dort rausgenommen werden.

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University


Zuletzt geändert von dj3hut1 am Fr Apr 09, 2010 21:09, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 09, 2010 17:40 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Wenn ich das richtig verstehe dann haben wir jetzt:
- Windows Support (getestet von Flash)
- Mac (intel) Support (getestet von damadmax)
- Plattformunabhängigen Starter auf ANT Basis (von dj3hut1 - getestet auf ?????)

Es fehlt noch ein Nachweis für Linux...damit hätte ich nicht gerechnet. ;)

Im Repository ist der Benchmark noch nicht, da er erst getestet werden sollte und die Startscripte inkl. beschreibung ergänzt werden sollten.

Wegen JOGL - die Frage ist, ob die neue JOGL Version kompatibel ist. Ansonsten muss man nochmal den Code anpassen.

Am Benchmark fehlt außerdem noch das Feature die Hardware auszulesen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 09, 2010 17:57 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Code:
===<Start DGL Benchmark>==============
Checking Parameters....
Found 1 parameter -> Using benchmark.conf as config file
Create Window for Benchmark
Exception in thread "main" java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1678)
   at java.lang.Runtime.loadLibrary0(Runtime.java:840)
   at java.lang.System.loadLibrary(System.java:1047)
   at com.sun.gluegen.runtime.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:102)
   at com.sun.gluegen.runtime.NativeLibLoader.access$000(NativeLibLoader.java:51)
   at com.sun.gluegen.runtime.NativeLibLoader$1.run(NativeLibLoader.java:70)
   at java.security.AccessController.doPrivileged(Native Method)
   at com.sun.gluegen.runtime.NativeLibLoader.loadGlueGenRT(NativeLibLoader.java:68)
   at com.sun.gluegen.runtime.NativeLibrary.ensureNativeLibLoaded(NativeLibrary.java:399)
   at com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:163)
   at com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:129)
   at com.sun.opengl.impl.x11.DRIHack.begin(DRIHack.java:109)
   at com.sun.opengl.impl.x11.X11GLDrawableFactory.<clinit>(X11GLDrawableFactory.java:99)
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(Class.java:186)
   at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:111)
   at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:520)
   at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:131)
   at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:90)
   at com.delphigl.dglbenchmark.DglBenchmarkMain.<init>(DglBenchmarkMain.java:78)
   at com.delphigl.dglbenchmark.DglBenchmarkMain.main(DglBenchmarkMain.java:52)

bekomme ich beim Ausführen von damadmax' Script. Irgendwelche Dependencies, die ich installieren sollte? Eine Suche in den Repos ergab weder für gluegen-rt noch für jogl einen Treffer …

greetings

ps:
Flash hat geschrieben:
Es fehlt noch ein Nachweis für Linux...damit hätte ich nicht gerechnet. ;)

Meinerseits ist da mangelndes Interesse an einem Java-Benchmark und mangelnde Zeit / Motivation, etwas in Pascal zu implementieren, schuld ;)

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 09, 2010 20:18 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Aug 18, 2007 18:47
Beiträge: 694
Wohnort: Köln
Programmiersprache: Java
Die Libs hast du dir reinkopiert ?

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.


Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 09, 2010 20:30 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Nachdem ich das Archiv jogl-1.1.1-linux-amd64-Archiv entpackt, den Inhalt des Unterordners lib in das Verzeichnis des Startskriptes kopiert und außerdem im Startskript den $LIBRARY_PATH angepasst hatte, sah das ganze dann so aus wie im Anhang. Soll das so? Sieht reichlich merkwürdig aus … Außerdem kommt beim Ändern der Fenstergröße immer ein
Code:
[GLEventListener.reshape] Leere Methode gerufen.

im Terminal (und das Bild bleibt gleichklein, der neue Fensterbereich wird nur von Schwarz erschlossen).

Sieht also so aus, als wäre für Linux und MacOS auf jeden Fall jeweils ein anderes Startskript notwenig (und das mit den Libs bitte dazusagen ;) ).

greetings


Dateianhänge:
benchmark.png
benchmark.png [ 7.92 KiB | 7185-mal betrachtet ]

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 09, 2010 21:06 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Aug 18, 2007 18:47
Beiträge: 694
Wohnort: Köln
Programmiersprache: Java
Der Test scheint wohl auf ein Resize zu warten. Wenn man das Fenster häufig in der Größe ändert kommt er auch mal zum Ende. Auf meiner Windows Kiste tut er das nicht.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.


Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Apr 09, 2010 21:13 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,

das Build-File wurde von mir unter Windows und Linux getestet.
Unter Ubuntu scheint sich auch bei mir das Fenster nicht von alleine zu schließen.
Wenn man es selbst schließt werden keine XML-Dateien erzeugt.

Viele Grüße
dj3hut1


Dateianhänge:
build.zip [494 Bytes]
305-mal heruntergeladen

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University
Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Sa Apr 10, 2010 15:43 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Resize ist einfach nicht imlementiert. Das verhalten ist korrekt.

Der Test dauert eine Weile. Bei mir auf dem Laptop ca. 30Sek.

Der Screenshot ist nebenbei ebenfalls korrekt. Er zeigt 1000Quads mit Smoothshading wenn ich mich nicht täusche.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Apr 11, 2010 16:11 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Auch wenn mich die Richtung in die diese Diskussion geht (Benchmark und Java sind für mich ein absolutes No-Go, und der ganze Shellkram hier *hust*) wollt ich nur mal nebenbei anmerken dass wir "früher" schonmal an nem DGL-Benchmark gearbeitet haben und es da sogar was lauffähiges mit (wenn ich nicht irre) DLL-Support von LarsMiddendorf gab.

Den Thread findet man hier : http://delphigl.com/forum/viewtopic.php ... wrapheader (HINWEIS : Internes Forum! Können also ned alle lesen)

Warum wird eigentlich nicht darauf aufgebaut, statt jetzt sowas unendlich kompliziertes in einer Sprache zu machen die fast die komplette Userbase aussperrt? Der im internen Link gepostet Source von Lars lässt sich übrigens noch kompilieren und es ist ein Beispielmodul dabei dass eine Test-DLL kompiliert die dem Benchmark ein FPS-Ergebnis zurückliefert.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Apr 11, 2010 19:36 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich schreib mir hier echt noch die Finger wund: Der Benchmark ist NICHT in Java geschrieben. Der Benchmark existiert nur als Spezifikation und es soll dann Implementationen für verschiedene Sprachen geben.
Ich hab absolut nichts dagegen, wenn hier jemand eine Delphi/Pascal Variante davon schreibt. Die Spec macht keine Annahmen über Fähigkeiten von Sprachen.

Wenn der Code von Lars funktioniert, dann kann man den ja so umbauen, dass er der Spec entspricht und schon haben wir eine zweite Referenzimplementierung. Anstatt einzelnen JARs hat man dann halt einzelne DLLs.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Apr 12, 2010 09:37 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Es geht mir auch eher darum dass wir damals (Ende 2003!) bereits ein laufendes Framework hatten, und dort via DLL eigentlich in jeder Programmiersprache Module erstellt werden können. Und dies hat auch prima funktioniert (die Testmodule haben bereits FPS und sogar nen Screenshot zurückgegeben), es gab Interesse, zwei (oder evtl.) mehr Chatabende zu dem Thema etc. Daher versteh ich nicht warum jetzt wieder alles komplett neuaufgezogen wird statt auf dem alten Benchmark (dem ja letztendlich nur die DB-Andindung, dank Delphi aber ein Klax, sowie eine hübsche GUI fehlen).

Denn die neue Idee mit der Implementation in verschiedenen Sprachen sagt mir nicht wirklich zu, zumal ich beim alten Benchmark rege mitdiskutiert, gewerkelt hab. Was bringt eine OpenGL-Benchmarkimplementation in verschiedenen Sprachen? Das macht die Sache doch unübersichtlich, da so doch auch die Performance der Programmiersprache teilweise in die OpenGL-Benchmarks einfliesst, was ja nicht sein soll. Denn durch die Performanceunterschiede in den Sprache wäre es ja unmöglich Werte untereinander zu vergleiche bzw. würde das in der DB dann sicherlich Verwirrung stiften.

Ich will hier keinesfalls die Spezifikationen oder die Diskussion in Frage stellen (ganz im Gegenteil, find es generell toll wenn Communityprojekte angegangen werden), sondern wollte drauf hinweisen dass wir sowas bereits 2003 in Planung hatten und auch was Lauffähiges.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Apr 12, 2010 10:03 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich muss mich da Sascha anschliessen, die Idee ein Framework für jede Sprache zu liefern ist keine gute Entscheidung.
Die Resultate eines Benchmarks im vergleich mit einem anderen sind völlig nutzlos, da z.B. ein Java und C++ Benchmark so unteschiedlich ausfallen werden, aufgrund des Overhead vom JNI für OpenGL, GC und einiges mehr, ganz zu schweigen von den Compileroptimierungen.
Es gibt eine gemeinsame Basis die alle Sprachen gleich haben und wo der Code auch gleich komplex umgesetzt wird und das sind dynamische Bibliotheken.
Diese werden von allen Sprachen in die gleiche ABI von C zusammen geführt und machen Test zwischen verschiedenen Sprachen wesentlich sinnvoller.
Ob nun das Benchmark Framework selber in Delphi,FreePascal, Java, c#, swing, scala, c++ oder einer anderen sprache geschrieben ist ist nebensächlich.
Da eine in Delphi schon existent ist , würde ich eher dazu tendieren dieses in Freepascal mal unter Windows, Linux und MacOSX zu testen und wenn nötig zu erweitern.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Apr 12, 2010 11:57 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Hmmm... was soll ich dazu sagen.... die Diskussion hier läuft auch nicht erst seit gestern.

Verschiedene Sprachen hätten noch den Effekt, dass man ungefähr die Performanceverluste durch die Sprachen messen kann.

Ist mir eigentlich auch egal wenn das hier alles verworfen wird. Was ich will ist, dass endlich ein DGL Benchmark zur Verfügung steht und dieser auch genutzt wird. Meine Javaimpl. hat den Vorteil, dass sie extrem simpel erweitert werden kann. Einfach ein Jar in einen Ordner kopieren und ein Configfile erweitern - fertig.

Ich für meinen Teil habe noch nie DLLs geschrieben - mal schnell einen Benchmark wird man da von mir also nicht sehen. Aber wenn andere das rege nutzen, fände ich das sehr gut.

Dann sollte man den DLL Benchmark mal so erweitern, dass er die Hardware ausließt und eine Ausgabe wie die laut spec liefert, so dass man die Benchmarkergebnisse sammeln könnte.

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Apr 12, 2010 12:24 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi,

was ich mich bei dem ganzen Benchmark Geschichten immer frage ist.. wozu ist das alles gut? :)

Ich meine, wenn ich den Geschwindigkeits unterschied zwischen Triangles und Triangle-Strips wissen will bau ich mir das kurz in meinem Programm/Engine/Spiel/WasAuchImmer ein und teste es direkt am lebenden Objekt.

Für so einen Testfall dann extra ein externes Tool hernehmen um dafür ein Plugin zu schreiben wäre mir viel zu aufwändig, zumal ich dann wenn sich herausgestellt hat das Variante B schneller ist ich das ganze nochmal bei mir in der Engine implementieren muß.

Und, das ganze dann als DLL zu verteilen bringt auch recht wenig, denn wenn bei mir Variante B schneller ist als A, wird das tendenziell bei jedem so sein.. also wozu muß jeder das nochmal Benchmarken?

Das einzige was es halt als sinnvollen Benchmark meiner Meinung nach gibt sind dinge wie "Wieviele Trianlges kann Grafikkarte XYZ pro sekunde verarbeiten", "Wie viel FPS bekommt man mit Fullscreen Shading bei Grafikkarte XYZ" etc.

Aber auch die Tests sind wieder recht irrelevant für die allgemeinheit und eher ansprechend für den einzelnen zum sehen wie toll seine Grafikkarte ist :)


Aya


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 87 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4, 5, 6  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 29 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.117s | 21 Queries | GZIP : On ]