Thanks for the explanation. I had assumed a Batch and vertex buffer would be roughly equivalent in terms of draw calls / overhead. When I get time I'll try a Batch with more complex geometry.
So vertex buffers would be the way to go, and then merging those into a Batch when needed for larger geometries. Because it's a 'glDrawBuffers' call (or equivalent), Batch can only have a single fragment, vertex and geometry shader bound before the draw call. This would also be true for vertex buffers too. Hence, some sorting by rendering by material. Thanks for the help =) Cheers, Adam On Sun, Sep 9, 2012 at 8:02 PM, Andreas Schiefer <[email protected] > wrote: > For simple, static geometries, yes, display lists will probably be > faster. But they cannot be changed and have some size limitations. > Also, as far as I know, some OpenGL drivers even emulate display lists > using their vertex buffer code. > > On the other hand, vertex buffers as used by batches have some > overhead because the buffers have to be bound for the draw call etc. > (and you additionally store and restore some GL state, which you don't > do in the display list render path). > The advantage of vertex buffers is that you can change the data > dynamically (and their size is not really limited). > > In an ideal case, you put all your geometry into one vertex buffer, > bind it once during setup and draw everything with a single draw call > in the render loop. > Switching between different buffers and storing and restoring GL state > are relatively expensive operations. > > > On Sun, Sep 9, 2012 at 11:06 AM, Adam Griffiths > <[email protected]> wrote: > > Thanks for the response Andreas. > > The code is just a quick'n'dirty, so excuse the trivial issues such as > > multiple initialisations. > > > > The point of the example is to demonstrate the speed of various methods. > > I'm trying to benchmark the Batch class by doing exactly what you stated, > > calling it 121 times. > > > > Are you saying that it should be expected for 121 batch calls to be > slower > > than 121 display list calls? > > > > I haven't tried this test with pyglet's vertex_list object, which I'm > using > > in other areas. > > I've found using vertex_list is faster than Batch. Is this to be > expected? > > > > > > Cheers, > > Adam > > > > > > On Sun, Sep 9, 2012 at 6:57 PM, Andreas Schiefer > > <[email protected]> wrote: > >> > >> I've quickly skimmed over your code and noticed a few things: > >> > >> - in setup_scene, it seems that you call initialise_cube for each > >> position, so you create 121 batches (and display lists) containing one > >> cube, but only the last one gets stored in the global variable (but > >> this shouldn't affect the performance, it's just wasted work) > >> > >> - in your render function, you draw the batch for each cube separately > >> - this amounts to 121 draw calls, each only drawing a single cube (and > >> possibly the vertex buffer for the batch gets rebound for each draw > >> call too, which can be expensive) > >> > >> The idea of batches is to draw as much geometry as possible in a > >> single draw call, so I guess you would get much better performance if > >> you put all your cubes into a single batch and draw them with a single > >> draw call. > >> Your current way of rendering might be acceptable if you have some > >> complex geometry in each batch, but I think the cube is just too > >> simple to take advantage of batched rendering - the overhead of the > >> batch is probably bigger than the actual render work. > >> > >> > >> On Thu, Sep 6, 2012 at 4:07 AM, Adam Griffiths > >> <[email protected]> wrote: > >> > I'm running Pyglet on OS-X (previously 10.7 and now 10.8). > >> > The entire time I've been developing, I've found using Pyglet's Batch > >> > objects to be horrendously slow. > >> > > >> > I have a demo program (it uses my framework PyGLy and Pyrr) which > shows > >> > this. > >> > > >> > > https://github.com/adamlwgriffiths/PyGLy/tree/master/examples/render_methods > >> > > >> > The example renders 121 transparent cubes and allows you to toggle > >> > between > >> > render methods (Immediate, Batch, DL). > >> > It also disables VSync and runs the render method as fast as possible > >> > > >> > I get the following results: > >> > > >> > OpenGL immediate mode: 38 fps > >> > pyglet.graphics.Batch: 51 fps > >> > OpenGL Display List: 99 fps > >> > > >> > In my other demos (mesh_md2) using Batch made the performance drop to > 10 > >> > fps. > >> > > >> > Is this a known issue? > >> > > >> > I see bug #314 was closed due to age. I have a feeling it wasn't > really > >> > resolved. > >> > http://code.google.com/p/pyglet/issues/detail?id=314 > >> > > >> > Cheers, > >> > Adam > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "pyglet-users" group. > >> > To view this discussion on the web visit > >> > https://groups.google.com/d/msg/pyglet-users/-/dtmgnj7yn60J. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]. > >> > For more options, visit this group at > >> > http://groups.google.com/group/pyglet-users?hl=en. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "pyglet-users" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/pyglet-users?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "pyglet-users" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/pyglet-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pyglet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
