GL_DEBUG_SEVERITY_LOW for creating and attaching a renderbuffer to an fbo ??

GL_DEBUG:
source : GL_DEBUG_SOURCE_API
type : GL_DEBUG_TYPE_OTHER
severity : GL_DEBUG_SEVERITY_LOW
id : 0x20061
message :
Framebuffer detailed info: The driver allocated storage for renderbuffer 1

GForce GTX 970
Driver 9.18.13.5306

Yes, me, I did it, guilty, caught, I created and attached the renderbuffer … on purpose! But whats wrong with that ? Why is it treated as an error with low severity ? Why should I use a texture when I do not need to sample ?
Application behavior is as expected.

That’s not an error, type is GL_DEBUG_TYPE_OTHER. In this case it’s just a debug message of low severity.
OpenGL 4.5 specs chapter 20 lists them all. https://www.opengl.org/registry/

Looks like you dumped every debug message you got from the OpenGL implementation.
If you don’t want to see these all the time, you could fine tune the level of information your application dumps by changing your function which handles these to ignore specific things at different debug levels for example.

I would agree if in that case the severity would be GL_DEBUG_SEVERITY_NOTIFICATION. As per Spec ( thanks for the hint btw., was searching for that ) GL_DEBUG_SEVERITY_LOW tells me about: “Performance warnings from redundant state changes; trivial undefined behavior” and I don’t see this for using renderbuffers as any attachment to an fbo, do you ?
No GL_DEBUG message at all on ATI APU/GPU in this case.

True, that might only need a notification status.
That output is implementation specific and I would still recommend to add filters for the source, type, and severity.

I did, turned off everything whats on severity notification, but to be honest I WANT to be informed about anything which has higher severity and fix it. The main question still remains: is there anything wrong performance vise in using renderbuffers ? Should I go with textures instead ? If so, what would be the reasoning ?

I wouldn’t be concerned about that. Rendering to render buffers should actually be faster than render to texture, at least from my experience as former OpenGL driver engineer. I would rather expect differences have become smaller nowadays but I haven’t tried recently.

I also wouldn’t spend too many thoughts on this specific debug output. If you can filter the output, simply go from top to bottom until you’re happy with the code and ignore the rest.

There are a lot more performance related topics how to architect OpenGL programs more efficiently.
Food for thought:
Check out the GTC presentations at http://on-demand-gtc.gputechconf.com/gtcnew/on-demand-gtc.php

Seach for the presentations
GPU-Driven Large Scene Rendering in OpenGL
Nvpro-Pipeline: A Research Rendering Pipeline
OpenGL 4.4 Scene Rendering Techniques
OpenGL Scene Rendering Techniques
Advanced Scenegraph Rendering Pipeline