🔒 Locked

A few performance questions

Started by NapharianWolf Jan 22, 2011 at 1:18 AM 2 replies 1.5k views

Original Post

Jan 22, 2011 at 1:18 AM

I'll start by listing my computer specs:
Intel Core2 Quad Q8300 2.5GHz
8gb DDR 3
Win 7 x64 Ultimate
2x Geforce 9600 GT (not in SLI mode, have 2 monitors (1920x1200, 1440x900) and 1 projector (1980x1080))

I am currently using jRuby with LWJGL. Default GC and no options, just "jruby script.rb"

I've calculated my maximum frame rate for a 1600x900 window (which is the window size for my program at the moment) based on my gfx card max fill rate to 7222.22222 (card fill rate is 10.4gps).

I am currently seeing a frame rate of ~640 when rendering roughly 2000 triangles on the screen (Skybox + GUI) using 2 VBOs (yes I know I should combine them into one).
When nothing is drawing and I only do a Display.update call within the loop, i get ~915fps
Without Display.update in the loop and just counting the number of cycles, i get ~330,000fps

Blending is on (blend function is src alpha, 1 - src alpha)
Shade model is smooth
cull face is enabled and removes front faces
Depth test is on and buffer cleared every frame (depth function is LEQUAL)
Color bit is never cleared due to the use of the skybox and gave me a very nice increase in performance
Average time for the VBO drawing functions 0.00024
Average time for the Display.update call 0.00126
Average main loop time is 0.00157 seconds
Double buffering is on (LWJGL does not allow you to turn it off)
Vsync is disabled (by application and video card)

My questions are:
1. What is the cost (if any) of 1d(invisible) triangles used to connect any number of triangle strips into 1 contiguous triangle strip
I currently have 4 1d(invisible) triangles per strip added

2. While VBOs rendered by index may be more space efficient, are they faster/slower/equal?

3. Display.update (which swaps the buffers and grabs system messages) runs at an average of 0.00157 seconds. Is there anyway I can speed this up?
there is no difference worth mentioning with Display.swapBuffers that does not grab system messages

4. Would it be wise to combine all of my GUI textures into 1 large texture to avoid a lot of texture binding during the GUI VBO drawing stage?

5. Are textures no longer subject to power of 2 limitations?
I render the GUI in an FBO and use the texture created, but when I created the texture I used 1600x900 for the dimensions (non power of 2) and it did it with no trouble. I was under the impression you have to use special calls to use non-power of 2.

More questions may follow, and thank you in advance for taking the time to answer.

Danny02

Jan 22, 2011 at 2:17 AM

1. negligible
2. faster because of the post transformation cache
3. a)you properly have a very big error, rounding error and measuring errors.
b ) you don't need to speed anything up and you won't ever get near the theoretical max fill rate cause of the standard overhead of running a OpenGL App in the first place.
4. yes, texture changes are one of the most expensive state changes.
5.On modern graphic card none power of 2 textures have no performance penalty. I wouldn't render a GUI to a FBO, because a GUI only takes a fraction of the screen and so you are wasting a lot of video memory.
About special calls, you need special calls to create such textures and also u have to use absolute texture coordinates instead of relative(perhaps only in shaders?)

No need to try to have as less VBOs as possible, the number of drawcalls isn't that important. Especially don't mix dynamic(GUI) geometry with static(skybox).

NapharianWolf

Jan 22, 2011 at 3:18 AM

The only reason I am rendering the GUI to an FBO is that it was a simpler solution than adjusting each elements coordinates if I were to want to render the GUI as if it were on a curved surface (think Metroid Prime HUD). All the numbers I gave are actually just rendering the GUI using it's VBO, I disabled the FBO for the time being due to a noticable pause when i needed to update it.

I'm not sure how I would be getting a rounding error when I time Display.update. The average is calculated every second along with the fps and loop average. I'm not using a profile at the moment, just Time.new.to_f before and after, then comparing. I know I wont get anywhere near close to max fill rate, but I was hoping that with so little rendered to the screen I would be seeing a higher fps. I got a 100fps boost by removing GL_COLOR_BUFFER_BIT from my glClear call and after that Display.update is the next slowest thing and the only thing at more than a fraction of an ms.

---

Here is the code for my FBO that works without power of 2, or special calls
Building:


 
 @fboTexture = glc.glGenTextures 
 glc.glBindTexture(glc::GL_TEXTURE_2D, @fboTexture)
 glc.glTexImage2D(glc::GL_TEXTURE_2D, 0, glc::GL_RGBA, 1600, 900, 0, glc::GL_RGBA, glc::GL_UNSIGNED_BYTE, nil)
 glc.glTexParameteri(glc::GL_TEXTURE_2D, glc::GL_TEXTURE_MAG_FILTER, glc::GL_NEAREST)
 glc.glTexParameteri(glc::GL_TEXTURE_2D, glc::GL_TEXTURE_MIN_FILTER, glc::GL_NEAREST)
 glc.glBindTexture(glc::GL_TEXTURE_2D, 0) 
 
 
 @fboDepth = arbf.glGenRenderbuffers
 arbf.glBindRenderbuffer(arbf::GL_RENDERBUFFER, @fboDepth)
 arbf.glRenderbufferStorage(arbf::GL_RENDERBUFFER, glc::GL_DEPTH_COMPONENT, 1600, 900)
 arbf.glBindRenderbuffer(arbf::GL_RENDERBUFFER, 0)
 
 @fbo = arbf.glGenFramebuffers
 arbf.glBindFramebuffer(arbf::GL_FRAMEBUFFER, @fbo)
 arbf.glFramebufferTexture2D(arbf::GL_FRAMEBUFFER, arbf::GL_COLOR_ATTACHMENT0, glc::GL_TEXTURE_2D, @fboTexture, 0)
 arbf.glFramebufferRenderbuffer(arbf::GL_FRAMEBUFFER, arbf::GL_DEPTH_ATTACHMENT, arbf::GL_RENDERBUFFER, @fboDepth) 
 arbf.glBindFramebuffer(arbf::GL_FRAMEBUFFER, 0)

Render to:


 glc.glEnable(glc::GL_TEXTURE_2D)
 glc.glBindTexture(glc::GL_TEXTURE_2D, 0)
 glc.glPushAttrib(glc::GL_VIEWPORT_BIT | glc::GL_ENABLE_BIT | glc::GL_COLOR_BUFFER_BIT | glc::GL_DEPTH_BUFFER_BIT)
 glc.glViewport(0, 0, 1600, 900)
 arbf.glBindFramebuffer(arbf::GL_FRAMEBUFFER, @fbo)
 
 glc.glClearColor(1.0, 1.0, 1.0, 0.0)
 glc.glClear(glc::GL_COLOR_BUFFER_BIT | glc::GL_DEPTH_BUFFER_BIT)
 glc.glLoadIdentity
 
 glc.glEnable(glc::GL_TEXTURE_2D)
 arbb.glBindBufferARB(arbv::GL_ARRAY_BUFFER_ARB, @vbo)
 glc.glVertexPointer(2, glc::GL_INT, 0, 0)
 arbb.glBindBufferARB(arbv::GL_ARRAY_BUFFER_ARB, @cbo)
 glc.glColorPointer(4, glc::GL_UNSIGNED_BYTE, 0, 0)
 arbb.glBindBufferARB(arbv::GL_ARRAY_BUFFER_ARB, @tbo)
 glc.glTexCoordPointer(2, glc::GL_FLOAT, 0, 0)
 glc.glBindTexture(glc::GL_TEXTURE_2D, TextureGL.textures["font"].id)
 glc.glDrawArrays(glc::GL_TRIANGLE_STRIP, 4, @vboLength)
 glc.glBindTexture(glc::GL_TEXTURE_2D, 0)
 
 arbf.glBindFramebuffer(arbf::GL_FRAMEBUFFER, 0)
 glc.glPopAttrib

Render FBO texture:


 glc.glBindTexture(glc::GL_TEXTURE_2D, @fboTexture)
 arbb.glBindBufferARB(arbv::GL_ARRAY_BUFFER_ARB, @vbo)
 glc.glVertexPointer(2, glc::GL_INT, 0, 0)
 arbb.glBindBufferARB(arbv::GL_ARRAY_BUFFER_ARB, @cbo)
 glc.glColorPointer(4, glc::GL_UNSIGNED_BYTE, 0, 0)
 arbb.glBindBufferARB(arbv::GL_ARRAY_BUFFER_ARB, @tbo)
 glc.glTexCoordPointer(2, glc::GL_FLOAT, 0, 0)
 glc.glDrawArrays(glc::GL_QUADS, 0, @guiVertices)
 glc.glBindTexture(glc::GL_TEXTURE_2D, 0)

KulSeran

Jan 22, 2011 at 5:02 AM

I know I wont get anywhere near close to max fill rate, but I was hoping that with so little rendered to the screen I would be seeing a higher fps. I got a 100fps[/quote]
For starters, anything in excess of your monitor refresh rate is usless FPS. If you have a 120Hz monitor, great, but most people run at 60. Set vsync to on, and forget about the fps till it starts to drop below 60, or maybe even 30.
Secondly, if your worried about the FPS for other reasons, then decouple your systems. You can always take user input at 120FPS, while doing logic updates at 20fps, physics updates at 30 fps and graphics updates at 60 fps.

Then, when you really need the graphics fps, go get a GPU debugger. ATI and Nvidia both have profiling tools. There are others out there like gDEBugger. There are lots of reasons for a slow render, and it all depends on what you are doing. You can render 2 triangles and get abysmal performance if you have some expensive pixel shader, so taking random guesses as to the problem isn't going to fix it. Profile!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.