2
$\begingroup$

I´m looking into uses of high amount of samples in multisampling. If I have an RGBA8 framebuffer and render to it using multisample with many samples, say 32, dithering on per-sample level should yield a reasonably accurate 8-bit color from the 32 samples in 4-bit color when resolved. The spec (4.5) seems a bit scary though (glBlitFrameBuffer):

If the read framebuffer is multisampled (its effective value of SAMPLE_BUFFERS is one) and the draw framebuffer is not (its value of SAMPLE_BUFFERS is zero), the samples corresponding to each pixel location in the source are converted to a single sample before being written to the destination. filter is ignored. If the source formats are integer types or stencil values, a single sample’s value is selected for each pixel. If the source formats are floating-point or normalized types, the sample values for each pixel are resolved in an implementation-dependent manner. If the source formats are depth values, sample values are resolved in an implementation-dependent manner where the result will be between the minimum and maximum depth values in the pixel.

What does that even mean?

Is there a way to do it in a cross implementation defined manner?

Improve this question
$\endgroup$
4
  • $\begingroup$ Current GPUs only support up to 8 samples per pixel, BTW, so your scenario with 32 samples in 4-bit color unfortunately isn't possible using hardware multisampling. $\endgroup$
    – Nathan Reed
    Nov 3, 2016 at 21:45
  • 1
    $\begingroup$ @NathanReed Provide a reference of your claim. Yesterday i queried an Nvidia Quadro 4000 of possible framebuffer configurations and up to 64 samples was provided. $\endgroup$
    – Andreas
    Nov 3, 2016 at 21:46
  • 1
    $\begingroup$ @NathanReed: Not true at all. There are many implementations that support a sample count greater than 8. Indeed, pretty much every GPU that supports GL 4.x supports more than 8 samples. Not because 4.x requires it, but simply because they can. Even many of Intel's GPUs support 16. The only exceptions seem to be AMD GPUs that don't use their GCN core. $\endgroup$
    – Nicol Bolas
    Nov 3, 2016 at 22:35
  • $\begingroup$ Ahh, I stand corrected. Somehow missed when GPUs crossed the 8-sample threshold. That was the limit for a long time, IIRC. $\endgroup$
    – Nathan Reed
    Nov 7, 2016 at 4:07

2 Answers 2

Reset to default
3
$\begingroup$

What does that even mean?

It means that multisampling is resolved.

A multisample framebuffer contains multiple samples for each pixel. The combination of samples represents the color of that pixel. The process of converting from multiple samples to a single color is multisample resolving.

By blitting from a multisampled buffer to a non-multisampled buffer, you are telling OpenGL to resolve each pixel's worth of samples into a single sample. Typically, this is done by adding all the sample values up and dividing by the number of samples, but implementations can take weighted averages or something else, depending on the precise nature of each sample.

Generally speaking, it's best that you let the implementation do its job.

Is there a way to do it in a cross implementation defined manner?

You can program your own resolution by rendering with a multisample texture to a non-multisampled texture. In the FS, you read each fragment's worth of pixels, doing whatever operation you would like to combine them.

But that's probably not going to be as fast as letting the hardware do the multisample resolve itself.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Will an implementation clamp the resolved value into the bit depth of the source before writing to the destination? OR, can I assume the precision is "enough" throughout the resolve to not lose any information? $\endgroup$
    – Andreas
    Nov 3, 2016 at 21:00
  • $\begingroup$ @Andreas: I would not suggest attempting to use multisampling to make precise calculations of anything. You should use it for its intended purpose: making pictures. If you need guaranteed precision of some calculation, multisampling is the wrong tool to employ; it has too many implementation-dependent variables. $\endgroup$
    – Nicol Bolas
    Nov 4, 2016 at 16:57
  • $\begingroup$ For the record my (current) mission is trying out order independent translucency and specifically smoke by altering the number of samples covered and their depth. I probably need many samples, at least 8. To make that work I need some guarantees of how OpenGL resolves the multisample surface. And I´d prefer it to be hardware accelerated. I´ll be back with more questions if I screw up. $\endgroup$
    – Andreas
    Nov 5, 2016 at 11:25
0
$\begingroup$

GPUs compress multisample data (for bandwidth) and dithering would defeat this - so this is not supported. GPUs also have techniques to sample at higher frequencies than they store values (see QUINCUNX anti aliasing for an example that's been around a while), saving overall memory.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.