Buffer Objects in jME

Development
41

ok cool.
One last nitpicking thing.
I really think the method setValue should be called setField or event better setFieldValue.
Please don’t hate me.

42

Ahaha, I have updated the PR again :wink:

2 Likes
43

@nehon what do you think about using glMapBuffer() to fetch data of SSBO from GPU? how can we manage it? because in some cases, users use SSBO to compute some data on GPU and to receive computed data on CPU side.

1 Like
44

It will be great to support glMapBuffer(). And glBufferSubData() too.

Moreover, it’s can to bring ability to not hold all of the buffers in CPU memory, but in GPU only. For example in clean OpenGL C (in case I understand it properly):

GLuint buff;
glGenBuffers(1, &buff);
glBindBuffer(GL_ARRAY_BUFFER, buff);
// Generate the buffer in GPU memory only
glBufferStorage(GL_ARRAY_BUFFER, size, NULL, GL_MAP_READ_BIT | GL_MAP_WRITE_BIT | GL_MAP_PERSISTENT_BIT);
// Map buffer to the CPU address space
void *data = glMapBuffer(GL_ARRAY_BUFFER, GL_READ_WRITE);
// ...
// Fill in the buffer data
// ...
// Release the mapping of a buffer
glUnmapBuffer(GL_ARRAY_BUFFER);
// Unbind the buffer
glBindBuffer(GL_ARRAY_BUFFER, 0);

In case of the glMapBufferRange() function, it’s can be possible to change the small parts of the big VBO (or any other buffer).

In my case, I try to implement the big voxel terrain. If I split them in the small parts (chunks), then I can change it quickly, but it’s slow to render big number of shapes separately. This is stuck on CPU.

When I joins all terrain geometry in single (almost, for optimisation) VBO, then it’s can give ability to render all terrain in single shot of glDraw(). But that approach introduse the problem to make changes in this terrain.

Ability to map and change only the part of big buffer can solve this problem without significant performance penalty.

P.S. Sorry if my English is too bad.

1 Like
45

IMHO glMapBuffer adds a whole lot of complexity. If you want to have it performant, you need to choose the right flags depending on the usecase. It requires glFenceSync/glMemoryBarrier at the right places depending on the usecase.
Gpu syncing when dooing async read/write ops is a nightmare

In that case i suggest looking up glMultiDrawElementsIndirect

46

If you do not double/tripplebuffer the buffer in this case you will get a full stall when reading the data.

1 Like
47

If I understand properly the glMultiDrawElementsIndirect, it is not solve my problem. As I understood, this method still required single buffer for all objects. If this is true, then my question is still open. How to rappidly change the single geometry in a big multiobject buffer?

48

For updating the buffer data glBufferSubData should be fast enough to upload a new tile to a large buffer containing all loaded tiles, then you can render partial tiles with drawIndirect in one call.

49

Yes. I agree. But it will be nice to be able to not consume system memory. In my current GPU I have 3Gb of memory. I can write algorithm so that it consume maximum GPU memory to render as big terrain as possible. And I confused little bit about the necessarity to dublicate that information in the system memory.

50

I dont see a need for duplicating memory.

1: Create a cpu buffer to hold the data for one tile.
2: Fill the buffer with the data for one tile
3: GlBufferSubData
4: goto 2

As a sidenote, without drawIndirect your indexbuffer can not be fragmented. So you eighter can swap only tiles with the same amount of triangles, or you likely have to rewrite large parts to counter the fragmentation on every change.

51

hey guys i’m following this improvment with high attention and want to ask what the actual state it has currently? the pull request looks like its done? regards

52

I have to review it. I’ve been a in a business trip the whole week and I couldn’t spare any time for JME. Resting a bit this week end and I’ll review it the coming week.

1 Like
53

So today i finally came to the point to got it running in my game.

Here some remarks:

  • On compatibility profile i had to activate “#extension GL_ARB_shading_language_420pack : enable” in the shader, if to use the binding id qualifier in the shader.
  • In the BufferObjectClass the Binding id is defaulty 1 or a number you assign to it. This should start by 0, because first ubo starts by id 0 not 1
  • I saw that float arrays and int arrays were missing but due to lack of padding i rejected to include it and provide a patch

Thanks for your contribution and thanks for the integration.

2 Likes
54

cool, I think if you create feature requests on github for this, I will spend time for it :slight_smile:

1 Like