Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (788)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (862)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Poor VBO performance  (Read 2859 times)
0 Members and 1 Guest are viewing this topic.
Offline acove

Junior Newbie

« Posted 2005-09-09 15:24:57 »

I recently ported my group's very performance-intensive rendering system from GL4Java to JOGL.  Having experienced a serious decrease in the performance of vertex arrays after the switch, I've been migrating the code over to use VBO's.  However, I have not yet been able to attain adequate frame rates for our needs.

All of the objects I've been rendering are in the form of stripped geometry, so the code to draw a single object is currently:

   gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB,;                                 //data vbo
   gl.glVertexPointer(3,GL.GL_FLOAT,0,BufferUtils.bufferOffset(0));                        //data is generally organized in buffer as (vertices[0-n],texcoords[0-n],colors[0-n])
   gl.glBindBufferARB(GL.GL_ELEMENT_ARRAY_BUFFER_ARB, vbo.indexID); //all the indices for all the strips

        //then, since not all of the strips use the same primitive type, there's a loop
       for (int n = 0; n < vbo.stripTypes.length; n++){
                   vbo.capacity[n],                                                                                  //the length of the current strip
                   vbo.offset[n]);                                                                                     //an array of ByteBuffers preloaded with output from BufferUtils.bufferOffset

   gl.glBindBufferARB(GL.GL_ARRAY_BUFFER_ARB, 0);

The models we're drawing range from 6k faces to 40k faces.  In some of the projects, we are able to use static VBO's, but in many cases, we dynamically deform the geometry, and thus use streaming VBOs. 

In the old GL4Java code, we were able to get suitable performance by using display lists of vertex array rendered geometry for static geometry, and just vertex arrays for the dynamic geometry.  However, in the new VBO-based JOGL code, vertex arrays are unbearably slow for the deforming geometry (like 12fps for one model, when I need to draw dozens), and VBO's and DisplayLists don't seem to play well together (the displaylist performance tanks).

Unfortunately, removing display lists entirely, and trying to render absolutely everything as VBO's does not reach our performance needs.  Running -Xprof reveals that 70% of the time is spent in dispatch_glDrawRangeElements . 

Any recommendations on what I may be doing wrong, or what I can do to improve performance?

Offline Ken Russell

JGO Coder

Java games rock!

« Reply #1 - Posted 2005-09-09 16:24:11 »

There should be absolutely no performance difference between GL4Java and JOGL when rendering vertex arrays or any other kind of bulk geometry. Are you running the latest version of JOGL (1.1.1)? What is the output of "java -Djogl.verbose demos.printext.PrintExt"? What OS, graphics card vendor, and JDK version are you using? Does the demos.vertexBufferObject.VertexBufferObject demo attain reasonable performance? What other command line flags are you passing to the JVM?

Offline acove

Junior Newbie

« Reply #2 - Posted 2005-09-09 17:40:27 »

Apparantly, I'm a jogl version behind. 

Windows XP is the OS.
jdk 1.5.0_03

FPS of the VBO demo is ~33

running java with :  java -server -Xmx1000m -Dsun.java2d.noddraw=true

Output of PrintExt:

JOGL version 1.1.0
Using single-threaded workaround of dispatching display() on event thread
GL vendor: NVIDIA Corporation
GL version: 1.5.1
GL renderer: Quadro FX 500/FX 600/AGP/SSE2
GL extensions:
  GL_ARB_depth_texture                    GL_ARB_fragment_program
  GL_ARB_fragment_program_shadow          GL_ARB_fragment_shader
  GL_ARB_imaging                          GL_ARB_multisample
  GL_ARB_multitexture                     GL_ARB_occlusion_query
  GL_ARB_point_parameters                 GL_ARB_point_sprite
  GL_ARB_shadow                           GL_ARB_shader_objects
  GL_ARB_shading_language_100             GL_ARB_texture_border_clamp
  GL_ARB_texture_compression              GL_ARB_texture_cube_map
  GL_ARB_texture_env_add                  GL_ARB_texture_env_combine
  GL_ARB_texture_env_dot3                 GL_ARB_texture_mirrored_repeat
  GL_ARB_transpose_matrix                 GL_ARB_vertex_buffer_object
  GL_ARB_vertex_program                   GL_ARB_vertex_shader
  GL_ARB_window_pos                       GL_S3_s3tc
  GL_EXT_texture_env_add                  GL_EXT_abgr
  GL_EXT_bgra                             GL_EXT_blend_color
  GL_EXT_blend_func_separate              GL_EXT_blend_minmax
  GL_EXT_blend_subtract                   GL_EXT_compiled_vertex_array
  GL_EXT_Cg_shader                        GL_EXT_draw_range_elements
  GL_EXT_fog_coord                        GL_EXT_multi_draw_arrays
  GL_EXT_packed_pixels                    GL_EXT_paletted_texture
  GL_EXT_pixel_buffer_object              GL_EXT_point_parameters
  GL_EXT_rescale_normal                   GL_EXT_secondary_color
  GL_EXT_separate_specular_color          GL_EXT_shadow_funcs
  GL_EXT_shared_texture_palette           GL_EXT_stencil_two_side
  GL_EXT_stencil_wrap                     GL_EXT_texture3D
  GL_EXT_texture_compression_s3tc         GL_EXT_texture_cube_map
  GL_EXT_texture_edge_clamp               GL_EXT_texture_env_combine
  GL_EXT_texture_env_dot3                 GL_EXT_texture_filter_anisotropic
  GL_EXT_texture_lod                      GL_EXT_texture_lod_bias
  GL_EXT_texture_object                   GL_EXT_vertex_array
  GL_HP_occlusion_test                    GL_IBM_rasterpos_clip
  GL_IBM_texture_mirrored_repeat          GL_KTX_buffer_region
  GL_NV_blend_square                      GL_NV_copy_depth_to_color
  GL_NV_depth_clamp                       GL_NV_fence
  GL_NV_float_buffer                      GL_NV_fog_distance
  GL_NV_fragment_program                  GL_NV_fragment_program_option
  GL_NV_half_float                        GL_NV_light_max_exponent
  GL_NV_multisample_filter_hint           GL_NV_occlusion_query
  GL_NV_packed_depth_stencil              GL_NV_pixel_data_range
  GL_NV_point_sprite                      GL_NV_primitive_restart
  GL_NV_register_combiners                GL_NV_register_combiners2
  GL_NV_texgen_reflection                 GL_NV_texture_compression_vtc
  GL_NV_texture_env_combine4              GL_NV_texture_expand_normal
  GL_NV_texture_rectangle                 GL_NV_texture_shader
  GL_NV_texture_shader2                   GL_NV_texture_shader3
  GL_NV_vertex_array_range                GL_NV_vertex_array_range2
  GL_NV_vertex_program                    GL_NV_vertex_program1_1
  GL_NV_vertex_program2                   GL_NV_vertex_program2_option
  GL_SGIS_generate_mipmap                 GL_SGIS_texture_lod
  GL_SGIX_depth_texture                   GL_SGIX_shadow
  GL_SUN_slice_accum                      GL_WIN_swap_hint
  WGL_EXT_swap_control                    GL_Autodesk_valid_back_buffer_hint
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder

Java games rock!

« Reply #3 - Posted 2005-09-09 18:26:36 »

Running with -Xprof on 1.5 will cause a significant slowdown of your application. This is due to an unfortunate design decision in HotSpot in the 1.5 timeframe which I hope will be fixed in 1.6.

How are you driving your rendering loop? If you have a single thread calling GLCanvas.display() over and over again, i.e., running as fast as possible, then there should be no measurable difference in efficiency between GL4Java and JOGL.

I believe the GL4Java workspace contained a version of the VertexArrayRange demo shipped with JOGL. Can you try running both versions of that demo? There should be no performance difference, and if that is the case, then something else has gone wrong in your JOGL port which is causing the slowdown. Can you boil things down into a smaller test case?
Offline acove

Junior Newbie

« Reply #4 - Posted 2005-09-09 20:45:05 »

I only used -Xprof when I was trying to find out what the slowest part of the display loop was. 

Up until now I've actually been using the Animator class.  I was aware of the overhead issues, but since all of my work is done synchronously in the display loop, its hold on the CPU didn't seem to be a huge factor, although I may be severely misinterpreting things.  I'll change that implementation to check for improvements.

I'll see what else I can narrow things down to.

Offline acove

Junior Newbie

« Reply #5 - Posted 2005-09-09 22:56:11 »

I've switched to using just a thread with an inner loop calling GLDisplay.display() rather than an animator, with no significant performance improvement. 

I was able to run both VAR demos and the JOGL demo is actually faster.

I'm going to put together a jar containing a minimal implementation of what I'm doing, which I'll try to post here.  It would be great if I can get this solved.
Pages: [1]
  ignore  |  Print  

hadezbladez (2134 views)
2018-11-16 13:46:03

hadezbladez (812 views)
2018-11-16 13:41:33

hadezbladez (2106 views)
2018-11-16 13:35:35

hadezbladez (420 views)
2018-11-16 13:32:03

EgonOlsen (3455 views)
2018-06-10 19:43:48

EgonOlsen (3682 views)
2018-06-10 19:43:44

EgonOlsen (2275 views)
2018-06-10 19:43:20

DesertCoockie (3004 views)
2018-05-13 18:23:11

nelsongames (3084 views)
2018-04-24 18:15:36

nelsongames (3854 views)
2018-04-24 18:14:32
Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!