Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Dark Helmet

Member Since 15 May 2012
Offline Last Active Aug 14 2014 06:09 AM

#5116805 Vertex Array Object + Direct State Access

Posted by Dark Helmet on 13 December 2013 - 08:49 PM

There is no viable alternative to VAOs though, which is why we are all so confused.

Cross-platform, no. But on NVidia, bindless can easily exceed the performance you get from VAOs, and the reason is intuitive.

You ideally just "enable" your 5 attribs, and then proceed to render 300 VBOs. You can't. It sucks.

Instead I have to create 300 VAOs, with 5 "enabled" attribs each. Then render 300 VAOs.

No you don't. Having a bazillion little VAOs floating around with all the cache misses that go with them isn't necessarily the best approach. Best case, use bindless (does an end-run around the cache issues, but is NV-only) or a streaming VBO approach with reuse (which keeps the bind count down, and works cross-platform).

If you have a number of separate, preloaded VBOs, you absolutely can't/refuse to make them large enough to keep you from being CPU bound for some reason, and you can't/won't use bindless, then fall back on (in the order of the performance I've observed on NVidia) 1) VBOs with VAOs, one per batch state combination, 2) client arrays, or 3) VBOs without VAOs or with one VAO for all.

In case it's not obvious, I do what gives me the best performance. I'm not a core purist.

Its really unfortunate AMD hasn't stepped up and supported bindless in their OpenGL drivers, at least for launching batches (vertex attribute and index list specification).


#5104068 PBO to GL_BACK

Posted by Dark Helmet on 24 October 2013 - 05:45 AM

GL_BACK_LEFT is a component buffer of the default (system) framebuffer. It is not the name of a buffer object.

I can easily see why you made this mistake though. Components of a framebuffer are historically called buffers (e.g. color buffers, depth buffer, stencil buffer; thus glDrawBuffer/glReadBuffer/etc.). These are different than buffer objects (arbitrary blocks of driver memory you can create).

With framebuffer objects, these component buffers are called "attachment points" to help disambiguate these concepts.


#5036553 Writing to Render Target from Itself

Posted by Dark Helmet on 25 February 2013 - 08:18 PM

Check out:

* GLSL : common mistakes#Sampling and Rendering to the Same Texture

NV_texture_barrier might be useful to you on NVidia specifically, but I don't know of a cross-vendor way to support this.

OpenCL IMO is a non-starter except for limited use cases, as IIRC flipping back and forth requires a full pipeline flush/sync (that is, in the absense of cl_khr_gl_event / ARB_cl_event). An OpenGL Compute Shader is much more interesting in terms of avoiding that overhead, but I'm not an expert on those yet.


PARTNERS