<p>I am implementing a simple ray tracer with OpenGL. I have a shader storage buffer with all the triangles so I can test them for intersections in a compute shader. It works fine up to a certain buffer size. But if I have more than a certain amount, it stops working and I get the following message:</p>

<blockquote>
  <p>OpenGL: Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.</p>
</blockquote>

<p>The program does not crash however.</p>

<p>The <code>GL_MAX_SHADER_STORAGE_BLOCK_SIZE</code> is 2147483647, so 2GB. The size of the buffer when it doesn't work anymore is just a couple of MB, around 6 to 7 MB.</p>

<p>Am I overlooking something? Are there other limits I don't know about?</p>

<p><strong>Edit:</strong></p>

<p>My specs: Linux Mint 17.2, GTX 980Ti with 6GB of VRAM</p>

CC BY-SA 3.0
2016-02-11T11:06:37.830Z
That's just a warning that the vram is getting over-committed and could cause more memory transfers.
ratchet freak
CC BY-SA 3.0
2016-02-11T17:08:21.130Z
@ratchetfreak: That's just a side effect then? I still don't understand why the program stops working though.
gartenriese
CC BY-SA 3.0
2016-02-12T17:00:26.943Z
@DanielMGessel: Yes, I am using Linux Mint 17.2 and my GPU is a GTX 980Ti with 6GB of VRAM.
gartenriese
CC BY-SA 3.0
2016-02-15T07:55:24.873Z
@DanielMGessel: I think it has something to do with how long my compute shader is working. When I am using a simple compute shader where I iterate through the whole buffer and compute an average over all the values inside, then it works with bigger buffer sizes. Are there any rules on how long a shader can be working? My error appeared when the shader was working for more than ~8 seconds.
gartenriese
CC BY-SA 3.0
2016-03-30T02:52:37.057Z
It would be useful to include the additional information (such as the comment mentioning OS and GPU) in the question so it is more accessible. Also, comments are not intended to last long term. If there's any information you want to add to the question, just [edit].
trichoplax is on Codidact now
CC BY-SA 3.0
2016-03-31T18:53:43.617Z
There are usually two limits, one having "native" in the name. Beyond native limits the driver is likely to emulate behavior in software. MB of shader data storage is never good. I had similar problem in DX11 a few years back. You should try move that data to a buffer object of some kind or divide the issue into more passes.
Andreas
CC BY-SA 3.0
2016-03-31T23:39:04.643Z
Why is a buffer object better than a shader data storage? I thought it was the other way around.
gartenriese
CC BY-SA 3.0
2016-04-01T06:07:30.627Z
@gartenriese Better? How do you mean?
Andreas
CC BY-SA 3.0
2016-04-01T12:08:45.787Z
@Andreas: If you look [here](https://www.opengl.org/wiki/Shader_Storage_Buffer_Object), three out of four points are in favor of SSBOs over UBOs.
gartenriese
CC BY-SA 3.0
2016-04-09T15:15:36.510Z
@gartenriese (Sry for delay, didnt have rep to comment) Oh I see. SSBO have additional features, and that is "better". Ok. My idea of a "buffer storage" was not SSBO/UBO. This post mentions "texture buffer objects" that are quite large without the requirement to be writeable: http://stackoverflow.com/questions/7954927/glsl-passing-a-list-of-values-to-fragment-shader
Andreas
CC BY-SA 3.0
2016-04-11T06:24:15.123Z
@Andreas: Thanks for the link, very informative. However the top answer says that SSBOs are even larger than TBOs, so I don't think this should be the problem. But I can try anyways!
gartenriese
CC BY-SA 3.0
2016-04-11T06:34:53.510Z
@gartenriese That's not what I read. SSBO are limited to 16MB. TBO is limited to VRAM. And you do have more VRAM than that, right? In any case you should check those parameters for you platform (glGetInteger).
Andreas
CC BY-SA 3.0
2016-04-11T09:53:47.163Z
@Andreas: No, they are not limited to 16MB. 16MB is the minimal size it is guaranteed to have. Usually they are limited to VRAM. If you look at my question I already checked the size with `GL_MAX_SHADER_STORAGE_BLOCK_SIZE` and it's 2GB (which isn't actually my VRAM size, but still big enough).
gartenriese
CC BY-SA 3.0
2016-04-11T09:55:06.207Z
@gartenriese Oh right, my bad.
Andreas
<opengl>
Cannot use more than a couple of MB in a shader storage buffer
gartenriese
# Cannot use more than a couple of MB in a shader storage buffer

(Asked by: username_0 on 2016-02-11)

I am implementing a simple ray tracer with OpenGL. I have a shader storage buffer with all the triangles so I can test them for intersections in a compute shader. It works fine up to a certain buffer size. But if I have more than a certain amount, it stops working and I get the following message:

> OpenGL: Buffer usage warning: Discarding a video memory only buffer object. The data store will be reallocated on next usage of the buffer object.

The program does not crash however.

The `GL_MAX_SHADER_STORAGE_BLOCK_SIZE` is 2147483647, so 2GB. The size of the buffer when it doesn't work anymore is just a couple of MB, around 6 to 7 MB.

Am I overlooking something? Are there other limits I don't know about?

**Edit:**

My specs: Linux Mint 17.2, GTX 980Ti with 6GB of VRAM

**Tags:** opengl

> **Comments:**
> **username_1**: That's just a warning that the vram is getting over-committed and could cause more memory transfers.  
> **username_0**: @username_1: That's just a side effect then? I still don't understand why the program stops working though.  
> **username_0**: @DanielMGessel: Yes, I am using Linux Mint 17.2 and my GPU is a GTX 980Ti with 6GB of VRAM.  
> **username_0**: @DanielMGessel: I think it has something to do with how long my compute shader is working. When I am using a simple compute shader where I iterate through the whole buffer and compute an average over all the values inside, then it works with bigger buffer sizes. Are there any rules on how long a shader can be working? My error appeared when the shader was working for more than ~8 seconds.  
> **username_2**: It would be useful to include the additional information (such as the comment mentioning OS and GPU) in the question so it is more accessible. Also, comments are not intended to last long term. If there's any information you want to add to the question, just [edit].  
> **username_3**: There are usually two limits, one having "native" in the name. Beyond native limits the driver is likely to emulate behavior in software. MB of shader data storage is never good. I had similar problem in DX11 a few years back. You should try move that data to a buffer object of some kind or divide the issue into more passes.  
> **username_0**: Why is a buffer object better than a shader data storage? I thought it was the other way around.  
> **username_3**: @username_0 Better? How do you mean?  
> **username_0**: @username_3: If you look [here](https://www.opengl.org/wiki/Shader_Storage_Buffer_Object), three out of four points are in favor of SSBOs over UBOs.  
> **username_3**: @username_0 (Sry for delay, didnt have rep to comment) Oh I see. SSBO have additional features, and that is "better". Ok. My idea of a "buffer storage" was not SSBO/UBO. This post mentions "texture buffer objects" that are quite large without the requirement to be writeable: http://stackoverflow.com/questions/7954927/glsl-passing-a-list-of-values-to-fragment-shader  
> **username_0**: @username_3: Thanks for the link, very informative. However the top answer says that SSBOs are even larger than TBOs, so I don't think this should be the problem. But I can try anyways!  
> **username_3**: @username_0 That's not what I read. SSBO are limited to 16MB. TBO is limited to VRAM. And you do have more VRAM than that, right? In any case you should check those parameters for you platform (glGetInteger).  
> **username_0**: @username_3: No, they are not limited to 16MB. 16MB is the minimal size it is guaranteed to have. Usually they are limited to VRAM. If you look at my question I already checked the size with `GL_MAX_SHADER_STORAGE_BLOCK_SIZE` and it's 2GB (which isn't actually my VRAM size, but still big enough).  
> **username_3**: @username_0 Oh right, my bad.  

---

## 0 answers

