Jump to content

  • Log In with Google      Sign In   
  • Create Account

Prune

Member Since 07 Mar 2007
Offline Last Active Dec 12 2014 03:29 PM

Topics I've Started

glGetError

10 September 2014 - 03:03 PM

Will I get a significant performance hit if I call glGetError() per frame, even if just before the SwapBuffers call (and I'm using vsync)?

 

For example, if I have a persistently mapped buffer, and I've initiated a transfer, then does the glGetError() act like a barrier and would thus potentially be a significant hit?


Overhead of GL_DYNAMIC_STORAGE_BIT​ or GL_MAP_WRITE_BIT​ when there's no writing be...

03 June 2014 - 06:13 PM

Do these two flags have any overhead?

 

I use immutable buffer storage. Most of my meshes are static, so I just upload the data at creation time by passing a pointer to glBufferStorage(). However, this presents me with a problem now that I've switched to putting all of a given type of vertex attributes in a single buffer (so all vertex positions for all meshes in one buffer, another one for normals, and so on), because I'm using a single multi-draw call per shader switch to draw a render pass.

 

The problem is now I either have to copy all my mesh data from mesh class instances to these buffers, instead of loading directly from the underlying std::vectors, or use a custom allocator for the vectors that my mesh class uses, where the allocator contiguously stores the elements of multiple vector instances into the underlying bigger buffer. Unfortunately, Visual C++ in debug mode uses a vector container's allocator not just for the element data store, but also rebinds it and allocates some _Container_proxy debugging data structure, and I haven't figured out how to handle that.

 

I'm wondering if, instead of having static buffer objects, I glBufferStorage() with null data source pointer but set either GL_DYNAMIC_STORAGE_BIT​ and load each mesh's data with glBufferSubData(), or GL_MAP_WRITE_BIT​ and write the data to the mapped buffers. But in this case, is there any potential overhead impacting performance after the buffers are filled with data by making the buffers writeable with either of these flags?


Overhead of subroutines in arrays when multidrawing?

28 May 2014 - 03:59 PM

Most of my drawing is with glMultiDrawElementsIndirectCountARB(), but I'm still splitting up the draw calls between groups of objects with different material types, in order to bind different shader programs. I've been considering just indexing by object ID into an array of subroutines so I don't have to switch shaders and thus have only one draw call per pass, but I'm wondering if an array of subroutines would have significant overhead, as it would be combining the additional dereference (the array) with a function call that can't be inlined (subroutine). Is this a realistic concern, or is it likely to be negligible?

The other issue I'm worried about is that different shaders in general require different inputs/outputs, and I'm not sure how much performance would be wasted by interpolation of input/output pairs that are unused by given subroutines.


Can I bind different ranges of the same buffer object to different binding points?

26 May 2014 - 12:20 PM

Specifically, can I glBindBufferRange() a portion of a buffer object to GL_DRAW_INDIRECT_BUFFER and another to GL_PARAMETER_BUFFER_ARB? It's kind of lame to have a whole separate buffer for the latter, given it's such a tiny buffer.


Can a bindless_sampler be mapped as normal UBO instead of using glProgramUniformHandleu...

21 May 2014 - 05:42 PM

ARB_bindless_texture specifies functions like glProgramUniformHandleui64vARB to update an array of texture handles. Can one, instead, use a regular uniform buffer object of GLuint64 and map it and write the handles to it, as one would write elements to any other mapped buffer object?


PARTNERS