|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Lloyd
Anmeldungsdatum: 27.06.2008 Beiträge: 37 Wohnort: Nähe Frankfurt
|
Verfasst am: 21.05.2009, 21:01 Titel: Open GL macht Code langsamer => wtf? |
|
|
Öhm, also ich hab hier eine Art Wassersimulation geschrieben, allerdings hab ich ein immenses Problem mit der Geschwindigkeit. Trotz simpelster Mathematik wird der Code sehr schnell langsam. Also dachte ich mir, probier ich mal mit OpenGL den Code und alles zu verschnellern, mithilfe des GPU.
Allerdings hat das so garnicht geklappt. Stattdessen ist der Code jetzt bei gleicher Menge an Partikeln 10 Frames langsamer. Und das, wo ich die Variablentypen nur durch die OpenGL Variablen ersetzt habe und die Zeichensachen angepasst habe.
Ich glaube allerdings auch, dass ich so nicht wirklich den GPU einsetze.
Jetzt ist meine Frage, was ich falsch mache. Ich habe den Code soweit optimiert wie ich konnte, es gibt keine überflüssige Berechnungen mehr oder Ähnliches. Ich bin echt überfordert ;__;
Achja, interessant wäre zu wissen, wieviel Frames ihr denn so habt.
Hier ist erstmal der normale Code, ohne OpenGL und Kommentare:
http://npshare.de/files/9a5f5cb7/Water_normal.rar
Und hier der Code mit OpenGL und Kommentaren:
http://npshare.de/files/71f8754a/Water_gl.rar
Bwäh! |
|
Nach oben |
|
|
MisterD
Anmeldungsdatum: 10.09.2004 Beiträge: 3071 Wohnort: bei Darmstadt
|
Verfasst am: 21.05.2009, 22:24 Titel: |
|
|
also wenn du so sachen wie OPEN CONS einmal vor der schleife machst und nicht bei jedem durchlauf neu gewinnst du sicher schon mal was..
ansonsten, glColor3f reicht auch einmal vor der schleife, du änderst die farbe ja nie (OpenGL ist ein Zustandsautomat, ein einmal eingestellter wert bleibt gleich, egal was passiert, solange du ihn nicht ausdrücklich änderst).
außerdem, so kram wie texturen, tiefentests und alphatests brauchst du bei deinem programm eigenltich im opengl nicht aktivieren, benutzt du eh nicht.
noch ein tipp: mach nicht sowas wie FOR i AS GLint = 1 to 10 oder sowas, benutz die GLxxx datentypen nur für zahlen, die du nachher auch in den GL-Befehlen benutzt, für alles andere benutz die normalen. dadurch erkennst du sehr einfach, welche variablen programm-variablen und welche variablen grafik-daten-werte sind, und ein GLint ist auch irgendwo nur per #define definiert und wird vorm compilen sowieso durch INTEGER ersetzt, also mach dir die mühe nicht.
und letztlich - jeden vertex einzeln an die grafikkarte schicken ist relativ langsam, versuch mal, direkt die vertices als array an openGL zu übergeben, das geht nämlich auch. schau dir zB http://www.blitzbasic.com/Community/posts.php?topic=66184 an für ein beispiel.
damit solltest du dann auch nen merklichen geschwindigkeitsunterschied erreichen _________________ "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
Nach oben |
|
|
Lloyd
Anmeldungsdatum: 27.06.2008 Beiträge: 37 Wohnort: Nähe Frankfurt
|
Verfasst am: 21.05.2009, 23:35 Titel: |
|
|
Hm, okay. Also die sinnfreien Zeilen hab ich mal rausgelöscht, hatte ich nur von irgendwoher kopiert
Allerdings krieg ich das mit dem Array nicht hin. Ich hatte es zwar hingekriegt, dass die Koordinaten hintereinandergereiht in einem Array gespeichert wurden, allerdings konnte ich damit nichts anzeigen. Entweder es wird nichts angezeigt, oder ich ordne dem Array nicht korrekt die Werte zu.
Allerdings dachte ich mir, dass es doch bestimmt gehen würde, den GPU zu benutzen, um mehr rechenleistung zu erzielen. Aber wie funktioniert das genau? Gibts da irgendwo Tutorials zu? Wäre Hammermäßig! |
|
Nach oben |
|
|
anihex
Anmeldungsdatum: 09.03.2006 Beiträge: 51
|
Verfasst am: 22.05.2009, 06:56 Titel: Re: Open GL macht Code langsamer => wtf? |
|
|
Lloyd hat Folgendes geschrieben: | Achja, interessant wäre zu wissen, wieviel Frames ihr denn so habt. |
Hab ich mal getestet ...
Im Softwaremodus hab ich etwa 54 FPS. Im OpenGL Modus hab ich nur noch 27 FPS. Damit hab ich bei deinem kleinen Programm weniger FPS als in Crysis Warhead (Enthusiast) bei 1280x1024 o.O
Ich kenne mich nun leider nicht so gut mit OpenGL aus, aber ich denke, dass mich das wundern darf ...
Zumal ich ein kleine kleine Graphikdemo erstellt habe, die ein Fenster bei der Auflösung 1024x768 mit insgesamt 7680 Quadraten mit jeweils 32x32 Pixeln füllt und ich hab dort immernoch über 1400 FPS o.O
Der Fairness halber : Meine kleine Demo berechnet auch nichts _________________ Es gibt nur 10 Arten von Menschen. Diejenigen, die den Binärcode verstehen und solche, die es nicht tun |
|
Nach oben |
|
|
MisterD
Anmeldungsdatum: 10.09.2004 Beiträge: 3071 Wohnort: bei Darmstadt
|
Verfasst am: 22.05.2009, 11:50 Titel: |
|
|
um die GPU zum rechnen zu benutzen brauchst du ne aktuelle grafikkarte, die CUDA unterstützt, außerdem musst du dann in C entwickeln mit CUDA erweiterung, musst erstmal verstehen wie man überhaupt mit massivparallelen prozessoren arbeitet, außerdem brauchst du sofern du nicht unter linux arbeitest visual studio auf dessen C-compiler der CUDA-compiler aufbaut..
-> http://en.wikipedia.org/wiki/CUDA
davon, dass du variablentypen mit nem anderen namen benutzt arbeitet nicht von alleine deine grafikkarte statt deiner cpu _________________ "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
Nach oben |
|
|
Haubitze
Anmeldungsdatum: 14.10.2009 Beiträge: 132
|
Verfasst am: 25.02.2010, 03:44 Titel: |
|
|
also wenn du die GPU benutzen moechtest um etwas zu berechen, brauchst du nicht wie oben angedeutet CUDA, das ist absolut ueberfluessig.
du kannst dich auch in GLSL einarbeiten dann deine eignen routinen
schreiben un baeng arbeitet deine GPU fuer dich.
allerdings solltest du dabei beachten je mehr deine
GPU fuer dich berechnungen macht die nichts mit der Grafik zu tun
haben desto weniger effekte kannst du daruber berechnen lassen.
hier noch ein link zur wiki: http://de.wikipedia.org/wiki/OpenGL_Shading_Language
damit solltest du schon ein wenig weiter kommen.
Gruesse Haubitze
PS: mir faellt grade ein, ich weis nicht in wie weit FB GLSL unterstuetzt. |
|
Nach oben |
|
|
MisterD
Anmeldungsdatum: 10.09.2004 Beiträge: 3071 Wohnort: bei Darmstadt
|
Verfasst am: 25.02.2010, 16:49 Titel: |
|
|
du gräbst hier threads aus die n dreiviertel jahr alt sind.. übrigens ;P _________________ "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008 Beiträge: 1917
|
Verfasst am: 25.02.2010, 20:49 Titel: |
|
|
Und verbreitest gefährliches Halbwissen. |
|
Nach oben |
|
|
Haubitze
Anmeldungsdatum: 14.10.2009 Beiträge: 132
|
Verfasst am: 26.02.2010, 07:27 Titel: |
|
|
oh tschuldigung da hab ich was verwechselt.
meinte natuerlich was anderes was auch mit shadern zu tun hatt...
is aber nicht wichtig da ich erstens zu alte freds rauskrame und
zweitens eh nur halbwissen verbreite.
naja CUDA is die loesung fuer alles.
guten tag |
|
Nach oben |
|
|
Sebastian Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 26.02.2010, 11:49 Titel: |
|
|
Haubitze hat Folgendes geschrieben: | is aber nicht wichtig da ich erstens zu alte freds rauskrame und
zweitens eh nur halbwissen verbreite.
naja CUDA is die loesung fuer alles. |
Ich sehe kein Problem darin, alte Threads um weitere Informationen zu ergänzen. Wir verweisen schließlich auch immer wieder auf die "SuFu" (Suchfunktion) und da ist es meiner Meinung nach auch legitim, den darüber auffindbaren Datenbestand anzureichern, auch wenn dies den ursprünglichen Threadstarter vielleicht nicht mehr interessiert. _________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
|
darkinsanity aka sts
Anmeldungsdatum: 01.11.2006 Beiträge: 456
|
Verfasst am: 26.02.2010, 12:03 Titel: |
|
|
Dann ergänze ich mal mit: Es ist schon möglich, über GLSL viele Berechnungen laufen zu lassen, allerdings ist das oft auch mehr Aufwand als es letztendlich bringt, gerade wenn es sich um "nicht-grafische", komplexere Berechnungen handelt. Vor allem das auslesend der Ergebnisse ist nicht so schön.
Deutlich flexibler (und ebenfalls plattformunabhängig) ist OpenCL, SDK´s gibts auch schon, aber irgendwie noch keine laufenden Treiber (soweit ich das überblicken kann).
Aber CUDA halte ich für ungeeignet, denn es geht nur auf nVidia-GPUs. Wenn OpenCL erstmal richtig läuft, muss noch nichtmal eine GPU benutzt werden, es gingen auch zusätzliche Prozessoren im System, d.h. PhysX, Cell Broadband Engine, angeblich sogar Prozessoren auf Soundkarten und selbstverständlich auch die CPU. _________________ Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak |
|
Nach oben |
|
|
MisterD
Anmeldungsdatum: 10.09.2004 Beiträge: 3071 Wohnort: bei Darmstadt
|
Verfasst am: 26.02.2010, 13:41 Titel: |
|
|
zu dem zeitpunkt meines posts war opencl noch garnicht benutzbar, wie das inzwischen ist weiß ich nicht. aber was ich so aus der forschung mitkriege, zumindest nehmen die leute immer cuda zuerst in den mund und hängen in der regel noch ein "oder opencl" irgendwo weiter hinten dran, der großteil der implementierungen scheint immernoch in cuda gemacht zu werden. _________________ "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008 Beiträge: 1917
|
Verfasst am: 26.02.2010, 16:45 Titel: |
|
|
Haubitze hat Folgendes geschrieben: | oh tschuldigung da hab ich was verwechselt.
meinte natuerlich was anderes was auch mit shadern zu tun hatt...
is aber nicht wichtig da ich erstens zu alte freds rauskrame und
zweitens eh nur halbwissen verbreite.
naja CUDA is die loesung fuer alles.
guten tag |
Ich wollte damit nicht ausdrücken, dass das was du geschrieben hast falsch oder Blödsinn ist, sondern lediglich das sagen, was letztendlich schon darkinsanity gesagt hat: Es ist aufwändig, zeitraubend und auch nicht unbedingt schnell, weil Shader darauf optimiert sind ein und dieselbe Sache nicht auf ein paar Millionen Pixel anzuwenden, sondern ein paar hundert mal pro Sekunde dieselbe Sache auf ein paar Millionen Pixel anzuwenden. |
|
Nach oben |
|
|
Haubitze
Anmeldungsdatum: 14.10.2009 Beiträge: 132
|
Verfasst am: 27.02.2010, 05:14 Titel: |
|
|
Gut 28398 dann habe ich deinen post wohl in den falschen hals bekommen.
ich gebe dir und auch den andern postern recht das es nicht unbedingt den
aufwand lohnt aber das war ja nicht die frage, sondern ob es machbar ist.
openCL hoere ich heute zB zum ersten mal. werd ich mir direkt mal
anschaun. vorallem wenn man damit zB physiX karten (oder den zweiten
cpu) ansprechen kann is das doch eine feine sache wuerde ich denken. da
ja in den meisten spielen grade die Physik sehr viel rechenaufwand
darstellt. aber auch in wissenschaftlichen projekten waere die sicher eine
gute alternative um rechenleistung besser und effizienter
einsetzen zu koenn.
ich denke hier zB an Klimaforschung, Proteinfaltung und berechnungen der statik.
friede und salute Haubitze.
PS.: wie oben angedeutet. ich kenne foren da sin freds von vor 5 jahren
noch sehr aktuell. daher kann ich nur dem poster zustimmen auch alte freds koennen aktuell gehalten werden |
|
Nach oben |
|
|
darkinsanity aka sts
Anmeldungsdatum: 01.11.2006 Beiträge: 456
|
Verfasst am: 01.03.2010, 13:56 Titel: |
|
|
noch etwas zum ursprünglichen Thema: Allein durch "graphische" Optimierung kann man das doppelte an FPS rausholen. Die Berechnungen sind und bleiben aber der Flaschenhals.
Vielleicht find ich die optimierte Version noch...
/edit:
Hier: http://darkinsanity.netii.net/stuff/Water_gl.7z
Läuft bei mir mit 71 FPS anstatt den 31 FPS der Originalversion. _________________ Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak |
|
Nach oben |
|
|
micha
Anmeldungsdatum: 09.12.2005 Beiträge: 72
|
Verfasst am: 05.03.2010, 21:48 Titel: |
|
|
Code: |
#include once "fbgfx.bi"
type float as single ' double
Type Vector
As float x
As float y
End Type
Type PARTICLE
As Vector P ' Postition
As Vector V ' Geschwindigkeit
As Vector A ' Beschleunigung !!! ignored !!!
As float Radius
As float Radius2 ' Radius^Radius
As float Mass
As float InvMass ' 1.0/Mass
As Integer Active
As Integer Fixed
End Type
const as integer nParticles = 1000
Dim Shared As PARTICLE Water(0 to nParticles-1)
Dim As Integer Sx, Sy, Counter, Flag
Dim As Integer FPS, Frames, Mx,My,Mb
Dim As Double tStart,tNow
Dim As float length, sumRadii, force,R
Dim As Vector diff,norm
Dim As PARTICLE ptr iP,jP
const As float DT = 1.0/100.0
const as float DT10 = DT*10
Const As float G = 98.1 ' Gravitation
Const As float GDT = G*DT
Const As float Stiffness = 200 ' Festigkeit/Steifheit des Wassers
Const As float Damping = 100 ' Dämpfung/Zaehigkeit des Wassers
Const As float DampingDT = Damping * DT
Screeninfo Sx, Sy
sx = 800
sy = 600
Screenres Sx,Sy
Randomize Timer
For i As Integer = 0 to nParticles-1
With Water(i)
.Active = 1 'Aktivieren
.Radius = 10
.Radius2 = .Radius*.Radius
.Mass = .Radius / 5
.InvMass = 1.0/.Mass
' Zufaellig in die untere Haelte des Bildschirms setzen
.P.x = Sx*Rnd
.P.y = sy*0.5 + sy*0.5*Rnd
End With
Next
tStart = timer
Do
Frames+=1
getmouse Mx, My,,Mb
If Mb = 1 Then
If Multikey( fb.sc_control ) Then
'PArtikel zur Maus ziehen
For i As Integer = 0 to nParticles-1
iP=@Water(i)
If iP->active Then
iP->V.x += (Mx-iP->P.x) * dt10
iP->V.y += (Mx-iP->P.y) * dt10
end if
'end with
Next
Else
'Partikel hinzufuegen
If Flag = 0 Then
Flag = 0
With Water(Counter)
.Active = 1
.Radius = 10 + 5*Rnd
.Radius2 = .Radius * .Radius
.Mass = .Radius / 5
.InvMass = 1.0/.Mass
.P.x = Mx
.P.y = My
.fixed = 0
End With
Counter = (Counter+1) mod nParticles
Endif
Endif
Elseif Mb = 2 Then
If Multikey( fb.sc_control ) Then
'Partikel von Maus abstossen
For i As Integer = 0 to nParticles-1
iP=@Water(i)
diff.x = iP->P.x - Mx
diff.y = iP->P.y - My
length = diff.x * diff.x _
+ diff.y * diff.y
if length > 0 then
If length < 100^2 Then
length =Sqr( length )
Force = -500 * (length - 100)
norm.x = diff.x/length
norm.y = diff.y/length
norm.x *= Force * dt
norm.y *= Force * dt
iP->V.x+=norm.x * iP->InvMass
iP->V.y+=norm.y * iP->InvMass
end if
Endif
'end with
Next
Else
'Feste Partikel hinzufuegen
If Flag = 0 Then
Flag = 1
With Water(Counter)
.Active = 1
.Radius = 20
.Radius2 = .Radius*.Radius
.Mass = 10
.InvMass = 1.0/.Mass
.P.x = Mx
.p.y = My
.fixed = 1
End With
Counter = (Counter+1) mod nParticles
Endif
Endif
Elseif Mb = 0 Then
Flag = 0
Endif
'durchzaehlen
For i As Integer = 0 to nParticles-2
iP=@water(i)
If iP->active = 1 Then
'For j As Integer = i + 1 + calc_timer to nParticles-1 Step calc_Step + 1
For j As Integer = i + 1 to nParticles-1
jP=@water(j)
If jP->active = 1 Then
' Beide zu kontrollierende Partikel sind aktiv
' Differen der Positionen
diff.x = jP->P.x - iP->P.x
' Radii zusammenzaehlen
SumRadii = ( iP->Radius + jP->Radius )
' Sind beide Partikel in dem Wuerfel mit der Kantenlaenge SumRadii?
If Abs(Diff.x) < SumRadii then
diff.y = jP->P.y - iP->P.y
if Abs(Diff.y) < SumRadii Then
' Satz des Pythagoras ohne Wurzel, um Rechenzeit zu sparen
length = diff.x * diff.x _
+ diff.y * diff.y
if (length > 0) then
' Sind beide Partikel im Radius?
If (length < (iP->Radius2 + jP->Radius2)) Then
' Jetzt erst Wurzel ziehen
length = Sqr( length )
' Federkraft berechnen
Force = -Stiffness * ( length - sumRadii ) * dt
' Differenz normalisieren
norm.x = Diff.x/length
norm.y = Diff.y/length
' Differenz der Geschwindigkeiten
Diff.x = jP->V.x - iP->V.x
Diff.y = jP->V.y - iP->V.y
norm.x*= Force
norm.y*= Force
' Daempfen
norm.x-= ( diff.x / sumRadii ) * DampingDT
norm.y-= ( diff.y / sumRadii ) * DampingDT
' Wenn einer der beidern Partikel fixiert, Kraft verstaerken
If jP->fixed = 1 Or iP->fixed = 1 Then
norm.x*=5:norm.y*=5
end if
' Geschwindigkeiten hinzufuegen
jP->V.x += norm.x * jP->InvMass
jP->V.y += norm.y * jP->InvMass
iP->V.x -= norm.x * iP->InvMass
iP->V.y -= norm.y * iP->InvMass
Endif
end if
Endif
Endif
Endif
Next
Endif
Next
For i As Integer = 0 to nParticles-1
iP=@water(i)
If iP->active = 1 Then
' Wenn nicht fixiert dann
If iP->fixed = 0 Then
' Position aktualisieren
iP->P.x += iP->V.x * dt
iP->P.y += iP->V.y * dt
' Geschwindigkeit aktualisieren !!! accel=0 !!!
' Water(i).V += Water(i).A * dt
' Gravitation hinzufuegen
iP->V.y += gdt * Water(i).mass
' Waende
R=iP->Radius
if (iP->V.y>0) then
If (iP->P.y+R)>Sy Then
iP->P.y=Sy-R:iP->V.y*= -Rnd*.1
end if
elseif (iP->V.y< 0) then
If (iP->P.y-R)<0 Then
iP->P.y=R:iP->V.y*= -Rnd*.1
end if
end if
if (iP->V.x > 0) then
If (iP->P.x+R)>sx Then
iP->P.x=sx-R:iP->V.x*= -Rnd*.1
end if
elseif (iP->V.x < 0) then
If (iP->P.x-R)<0 Then
iP->P.x =R:iP->V.x*= -Rnd*.1
end if
end if
Else
' Wenn fixiert dann Geschwindigkeit nullen
iP->V.x= 0
iP->V.y= 0
'iP->A.x= 0 !!! never used !!!
'iP->A.y= 0
Endif
Endif
Next
' Zeichnen
screenlock
line (0,0)-(sx,sy),0,BF
for i as Integer = 0 to nParticles-1
with water(i)
line (.P.x,.P.y)-(.P.x+.V.x*dt, .P.y+.V.y*dt) ,1
end with
next
screenunlock
if Frames=100 then
tNow=Timer
fps=100.0/(tNow-tStart)
WindowTitle "FPS = " & FPS
Frames=0
tStart=tNow
Sleep 10
end if
Loop Until Multikey(&h01)
|
|
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|