<p>Buffer sharing like this is a common practice in OpenGL, in Vulkan it is even encouraged. So there should be no spec reason that this isn't allowed.</p>
<p>However there is still a chance that everything looks good on GPU A but on GPU B frames don't render correctly. This can happen if OpenGL doesn't handle the barrier between the two correctly. So one frame is still writing the data while another frame sneaks in and starts reading it.</p>
<p>OpenGL will &quot;probably&quot; get it right, but I would give a long hard look at memory barrier requirements in GL just to make sure.</p>

CC BY-SA 4.0
2024-04-11T15:23:32.663Z
I remember trying to use a buffer both as a vertex buffer in a draw call and as a transform feedback buffer for that draw call (of course, with a target range outside of what was used for rendering) and it certainly didn't work. Now a shader storage buffer mght be more flexible, but I could still imagine the driver not liking you to mess with a buffer that you currently render from, especially since you can't really tell the GL which region of the buffer you actually access when rendering (at least with indexed drawing and without `glBindVertexBuffer`).
Christian Rau
CC BY-SA 4.0
2024-03-07T14:13:37.600Z
2024-03-07T14:13:37.600Z
pmw1234
<p>I have created a too large buffer with some vertex data (position, normal vector...).</p>
<p>Within the render pipeline, I want to append new data to the end of the currently used buffer.
To do this, I thought of binding this buffer as <code>GL_ARRAY_BUFFER</code> and <code>GL_SHADER_STORAGE_BUFFER</code> at the same time.</p>
<p>Within the geometry shader, I only want to modify this buffer after the last vertex information used by this render call. So no input data will be changed.</p>
<p>Is this allowed? Or do I HAVE to create a second separate buffer in which I store the generated data?</p>

CC BY-SA 4.0
2024-03-07T11:35:31.163Z
The only real issue for doing this under opengl is the whether or not opengl is going to being able to figure out the memory barriers.  What version of OpenGL are you using? Since OpenGL 4.6 you can issue an explicit memory barrier.
pmw1234
CC BY-SA 4.0
2024-03-07T11:59:53.610Z
Not sure where I came up with 4.6, at any rate look into barriers to help with this.
pmw1234
CC BY-SA 4.0
2024-03-07T12:52:03.487Z
I don't need any barriers, because the memory which will be changed is appart from the input memory (memory index 0 till 10000 is used as vbo input, 10001 till 20000 is used to store new values). I am using the latest openGL version
Thomas
CC BY-SA 4.0
2024-03-07T12:53:43.077Z
I am only interested in knowing if this is allowed... On my GPU it seems to work. But I must been sure, if this is working on other GPUs as well...
Thomas
CC BY-SA 4.0
2024-03-07T12:59:12.927Z
Barriers aren't needed for the write, the question is will the write be done before the next read, the previous frame may still be writing when the frame that needs the data wants to read it. Unless there are no readers which begs the question.
pmw1234
CC BY-SA 4.0
2024-03-07T13:09:36.633Z
I hear you, everything works a GPU A and GPU B gives "ridiculous error 296512343" but  buffer sharing like this is common practice. This particular case isn't *as* common, but still done fairly often, there is no spec reason this shouldn't be allowed. But I still encourage you to look into the barriers to make sure the two won't step on each others toes.
pmw1234
CC BY-SA 4.0
2024-03-07T13:49:41.060Z
@pmw1234 Thank you very much! That was what I wanted to hear. Please write that as an answer so I can accept it =)
Thomas
<opengl>
OpenGL Bind same buffer as VBO and SSBO at the same time
Thomas
# OpenGL Bind same buffer as VBO and SSBO at the same time

(Asked by: username_0 on 2024-02-29)

I have created a too large buffer with some vertex data (position, normal vector...).

Within the render pipeline, I want to append new data to the end of the currently used buffer.
To do this, I thought of binding this buffer as `GL_ARRAY_BUFFER` and `GL_SHADER_STORAGE_BUFFER` at the same time.

Within the geometry shader, I only want to modify this buffer after the last vertex information used by this render call. So no input data will be changed.

Is this allowed? Or do I HAVE to create a second separate buffer in which I store the generated data?

**Tags:** opengl

> **Comments:**
> **username_1**: The only real issue for doing this under opengl is the whether or not opengl is going to being able to figure out the memory barriers.  What version of OpenGL are you using? Since OpenGL 4.6 you can issue an explicit memory barrier.  
> **username_1**: Not sure where I came up with 4.6, at any rate look into barriers to help with this.  
> **username_0**: I don't need any barriers, because the memory which will be changed is appart from the input memory (memory index 0 till 10000 is used as vbo input, 10001 till 20000 is used to store new values). I am using the latest openGL version  
> **username_0**: I am only interested in knowing if this is allowed... On my GPU it seems to work. But I must been sure, if this is working on other GPUs as well...  
> **username_1**: Barriers aren't needed for the write, the question is will the write be done before the next read, the previous frame may still be writing when the frame that needs the data wants to read it. Unless there are no readers which begs the question.  
> **username_1**: I hear you, everything works a GPU A and GPU B gives "ridiculous error 296512343" but  buffer sharing like this is common practice. This particular case isn't *as* common, but still done fairly often, there is no spec reason this shouldn't be allowed. But I still encourage you to look into the barriers to make sure the two won't step on each others toes.  
> **username_0**: @username_1 Thank you very much! That was what I wanted to hear. Please write that as an answer so I can accept it =)  

---

## 1 answers

### Answer by username_1 on 2024-03-07. Score: 1 | Accepted answer

Buffer sharing like this is a common practice in OpenGL, in Vulkan it is even encouraged. So there should be no spec reason that this isn't allowed.

However there is still a chance that everything looks good on GPU A but on GPU B frames don't render correctly. This can happen if OpenGL doesn't handle the barrier between the two correctly. So one frame is still writing the data while another frame sneaks in and starts reading it.

OpenGL will "probably" get it right, but I would give a long hard look at memory barrier requirements in GL just to make sure.

> **Comments:**
> **username_2**: I remember trying to use a buffer both as a vertex buffer in a draw call and as a transform feedback buffer for that draw call (of course, with a target range outside of what was used for rendering) and it certainly didn't work. Now a shader storage buffer mght be more flexible, but I could still imagine the driver not liking you to mess with a buffer that you currently render from, especially since you can't really tell the GL which region of the buffer you actually access when rendering (at least with indexed drawing and without `glBindVertexBuffer`).  

---

