i downloaded fogleman's excellent "minecraft in 500 lines" demo https://github.com/fogleman/craft. used 2to3 tool , corrected details hand make runnable under python3. wondering thing call of self.clear() in render method. modified rendering method called every frame pyglet:
def on_draw(self): """ called pyglet draw canvas. """ framestart = time.time() self.clear() cleartime = time.time() self.set_3d() glcolor3d(1, 1, 1) self.model.batch.draw() self.draw_focused_block() self.set_2d() self.draw_label() self.draw_reticle() rendertime = time.time() self.clearbuffer.append(str(cleartime - framestart)) self.renderbuffer.append(str(rendertime - cleartime)) as can see, took execution times of self.clear() , rest of rendering method. call of self.clear() calls method of pyglet, can found @ .../pyglet/window/__init__.py:
def clear(self): '''clear window. convenience method clearing color , depth buffer. window must active context (see `switch_to`). ''' gl.glclear(gl.gl_color_buffer_bit | gl.gl_depth_buffer_bit) so make call glclear().
noticed frame drops while testing game (at 60 fps), added above code measure execution time of commands, , 1 of glclear(). found out rendering never takes longer 10 ms. duration of glclear() bit of different story, here distribution 3 measurements under different conditions:
duration of glclear() under different conditions.
the magenta lines show time limit of frame. behind first line means there frame drop.
execution time of glclear() seems have kind of "echo" after first frame expires. can explain me why? , how can make call faster?
unfortunately not opengl expert, thankful every advice guys. ;)
your graph wrong. well, @ least it's not suitable graph purpose of measuring performance. don't ever trust gl* function execute when tell to, , don't ever trust execute fast you'd expect to.
most gl* functions aren't executed right away, couldn't be. remember, we're dealing gpu, telling stuff directly slow. so, instead, write to-do list (a command queue) gpu, , dump vram when really need gpu output something. "dump" part of process called synchronisation, , can trigger 1 glflush. though, opengl user friendly (compared to, say, vulkan, @ least), , such doesn't rely on explicitly flush command queue. many gl* functions, depending on graphics driver, implicitly synchronise cpu , gpu state, includes flush.
since glclear initiates frame, possible driver thinks it'd perform such implicit synchronisation. might imagine, synchronisation slow process , blocks cpu execution until it's finished.
and what's going on here. part of synchronisation process perform memory transactions (like glbufferdata, glteximage*), queued until they're flushed glclear call. makes sense in example; spikes can observe frames after you've uploaded lot of block data.
but bear in mind, pure speculation, , i'm not total expert on sort of stuff either, don't trust me on exact details. this page on opengl wiki resource on sort of thing.
though 1 thing certain, glclear call not take long profiler says does. should using profiler dedicated profiling graphics.
Comments
Post a Comment