I’ve been Googling for almost an hour now and I think the problem is with my VAO
I recently tried switching to Riven’s unmapped buffer code but unfortunately code that used to work now doesn’t. I’m getting a fatal error from the JVM stating “EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000018007caf0, pid=4744, tid=9456”
Above is my code and I appreciate any help whatsoever
Almost always means that you’ve told OpenGL to read outside a buffer boundary, either through how you set up your vertex attributes or by drawing too many elements (if using glDrawElements()).
I can’t understand how though, I know for a fact that my vertex attributes specifically state 32 bytes per vertex, my buffer sizes are set up correctly, my buffers are bound correctly and my draw calls no matter how many vertices will always give out access violation…
Can you make a self-contained, compilable executable example, for us to reproduce the problem?
Here you go, it automatically links to the natives in the same folder in the same way LWJGL 3 structures them. Link the LWJGL 3 JAR itself the way you want
You’ve misunderstood how vertex attributes and buffers work. glVertexAttribPointer() inherently uses the currently bound VBO at the moment when you call that method (not when glDrawArrays() is called), and since you have none bound you’re essentially telling it to read from an invalid memory address. Once you call glDrawArrays() the read is actually executed, so that’s where it crashes. You need to bind the correct VBO before calling those methods. In the same way, your glBindBuffer() in [icode]public void drawBuffer(Unsync buffer)[/icode] currently does nothing. Since you’re using Riven’s unmapped buffer code, you need to redo all your glVertexAttribPointer() calls with the correct buffer bound each frame since the buffer you want to read from changes each frame.
Well, it has fixed the issue but now I have two new questions:
How am I supposed to use a VAO?
and
Why am I getting such slow speeds with just 600 vertices
I’ve just been experimenting with VAO and it turns out they’re a massive pain in the arse for almost no gain whatsoever. What I’ve discovered is that you should essentially create and bind one VAO right at app init, and leave it well alone. Then everything just works as it did before.
Cas 
VAO’s were ment to reduce code, but introduced buttpain.
VAOs were meant to reduce OpenGL API call count, pushing state into the GPU, at the expense of code complexity.
In the end the complexity is a real problem, and more importantly, VAOs actually have worse performance. So it’s pretty much a lose-lose situation.
Digression… it was a shame they didn’t really seem to grok how people were using VAOs in real life. IMHO the basic principle behind it - “set up a vertex format once and reuse it” - is broken by 2 things:
Cas
I guess the new layout system tried to address this but that wasn’t really helpful as well…
So, what can I do about the speed ;D
What are you comparing with? Buffer mapping is an expensive operation, so you should try to map as little few times per frame as possible. Mapping is more useful for very large VBOs. If you’re mapping so little data, the mapping operation may be expensive enough to bottleneck the program at a few thousand FPS. You may want to take a look at persistent mapped buffers for optimal performance.
@theagentd: except that we discovered (when using LibStruct) that persistent mapped buffers had horrible performance in the mapped memory region. It was a lot faster to write into another region and copy that into the mapped region. :persecutioncomplex:
that makes me cry. :’(
I am just mapping a single buffer per frame, should I drop down to 10-20 frames per second with that? It seems unreal. Will I be better off orphaning buffers with glBufferData(target, size, GL_STREAM_DRAW); and then glBufferSubData(…)?
Persistently mapped memory most definitely is faster. You completely get rid of the map operation and also get rid of some driver-internal synchronization. Sequential writes to write-only persistently mapped memory is barely slower than normal direct ByteBuffers. Using LibGDX with read-write persistent GPU memory is slow, since you’re essentially reading and writing incoherently directly to VRAM. When it comes to uploading data to the GPU, you cannot beat persistent mapped buffers.
How are you mapping your buffer now? What are you writing to it? What are you drawing? What GPU do you have?
I am using the exact same method the code above I posted, I basically do this every frame:
buffer.nextFrame();
buffer.bind();
buffer.ensureSize(6 * 32);
FloatBuffer mapped = buffer.map().asFloatBuffer();
mapped.put(new float[] {-1, 1, 0, 1, 0, 1, 0, 0});
mapped.put(new float[] {1, 1, 0, 0, 1, 1, 1, 0});
mapped.put(new float[] {1, -1, 0, 1, 1, 0, 1, 1});
mapped.put(new float[] {-1, 1, 0, 1, 0, 1, 0, 0});
mapped.put(new float[] {1, -1, 0, 0, 1, 1, 1, 1});
mapped.put(new float[] {-1, -1, 0, 1, 1, 0, 0, 1});
buffer.unmap();
drawBuffer(buffer);
When I put the put calls into a loop repeating it 100 times I’m just putting 600 vertices per frame, but even at around 50 runs (so 300 vertices) the FPS starts to struggle hard
The map operation is relatively slow, and what’s more, it causes a total GPU stall. The correct way to do things is probably to map one large buffer.
Cas