How to query sample count of RBO

Is there a way to query the number of samples of a RBO, that is, the number passed as the second argument to glRenderbufferStorageMultisample ?

I assume the RBO is used by a FBO, so maybe a glGet with GL_SAMPLES with the FBO bound might work?

L.E.: @remdul, you are correct, sorry. Haven’t used RBOs in a while. The docs say that it should return the sample count for the currently BOUND framebuffer but also, as I found out later, that user created framebuffers would return 0.

Use glGetRenderbufferParameter. Though really, there’s no reason to do so, unless you’re using a renderbuffer that you didn’t actually create. Because if you created it, you should know how many samples it was created with.

If you ask for three samples, it might be created with four.

@IonutCava: AFAIK that only works for the FB of the GL context. glGet(GL_SAMPLES, …) doesn’t seem to work on bound RBO/FBOs.

@Alfonse Reinheart: thanks! See comment by arekkusu as to why. IIRC I’ve seen sample counts clamped to GL_MAX_SAMPLES, and thus one may not be sure of the exact RBO sample count. Although one should ideally query the MAX_SAMPLES before setting up the RBO, I also prefer to query the RBO afterwards to be sure. It is important to know the exact sample count to calculate the coverage ratio when using occlusion queries.

That only makes me more curious: what are you doing with occlusion queries that you need an accurate count of passed samples?

Also, the specification on such things is… kinda wishy-washy. The spec allows implementations to count either just the samples in a pixel covered by the primitive, or all the samples in a pixel even if the primitive only covers one sample in that pixel. So it would be impossible to get a truly accurate sample count.

For example when rendering a glow over sun disk in the sky, and gradually fading it when obscured. With MSAA enabled, the occlusion query result will be multiplied by the number of samples, which is why I need to be certain about the number of samples per pixel. I pre-calculate the number of pixels of the rasterized occludee on the CPU (trivial for 2d primitive shapes), and divide the occlusion result by that to get the ratio, which is then used to blend/scale the glow sprite. Much more elegant than a ray-test with temporal fade, and it works with alpha-tested and alpha-to-coverage surfaces. :slight_smile:

A little conformance test (e.g. perform occlusion query on one 1px GL_POINTS) should reveal what convention the driver uses. I previously avoided that by rendering the occludee twice, once right after clearing the depth buffer to obtain the unobscured pixel count, and again later to get for the occluded pixel count, but I’d like to avoid unnecessary potential pipeline stalls (and messy code) if possible.

Well, it would have been nice if the spec was more strict and the numbers actually meant something.

Just as a side note and for future reference, @remdul, from the current docs:
“GL_SAMPLES - params returns a single integer value indicating the coverage mask size of the currently bound framebuffer” so I should’ve worked, I think, but Alfonse’s solution was the correct one. I just assumed that you had no control over the RBO but knew it was used somehow.

That should throw an GL_INVALID_VALUE error (and an GL_INVALID_OPERATION if it’s not supported by the format) upon creating the storage.

I’m actually curios about arekkusu’s comment. In what situations does rounding occur and wouldn’t it round down if it happened?

[QUOTE=IonutCava;1266162]
I’m actually curios about arekkusu’s comment. In what situations does rounding occur and wouldn’t it round down if it happened?[/QUOTE]

It’s not really “rounding” so much as “that’s what the implementation supports”. Some multisample implementations only handle powers-of-two sample counts. Also, note that you can just ask the implementation what sample counts it supports, for a particular image format/texture target.

Yes, but specifying an unsupported value for a specific format would surely throw an error, right? Multisampling seems solid enough to at least tell you when you specify an invalid count. Or would that make too much sense to actually implement? :slight_smile:

Yes, but specifying an unsupported value for a specific format would surely throw an error, right?

No. If you ask for 5 samples, there’s nothing necessarily wrong with giving you 8 instead. The only places where an exact sample count is needed is when your shader is directly interacting with the samples in an image. Either by reading/modifying the fragment’s output sample mask or when you’re from a multisample image in a shader.