<blockquote>
  <p>What does that even mean? </p>
</blockquote>

<p>It means that multisampling is resolved.</p>

<p>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.</p>

<p>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.</p>

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

<blockquote>
  <p>Is there a way to do it in a cross implementation defined manner?</p>
</blockquote>

<p>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.</p>

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

CC BY-SA 3.0
2016-11-03T21:00:38.740Z
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?
Andreas
CC BY-SA 3.0
2016-11-04T16:57:26.603Z
@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.
Nicol Bolas
CC BY-SA 3.0
2016-11-05T11:25:48.593Z
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.
Andreas
CC BY-SA 3.0
2016-11-03T20:05:44.903Z
2016-11-03T20:05:44.903Z
Nicol Bolas
<p>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): </p>

<blockquote>
  <p>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), <strong>the samples corresponding to each pixel location in the source are converted
  to a single sample before being written to the destination.</strong> 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 ﬂoating-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.</p>
</blockquote>

<p>What does that even mean? </p>

<p>Is there a way to do it in a cross implementation defined manner?</p>

CC BY-SA 3.0
2016-11-03T21:45:00.907Z
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.
Nathan Reed
CC BY-SA 3.0
2016-11-03T21:46:04.597Z
@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.
Andreas
CC BY-SA 3.0
2016-11-03T22:35:04.340Z
@NathanReed: Not true at all. There are [many implementations that support a sample count greater than 8](http://opengl.gpuinfo.org/gl_stats_caps_single.php?listreportsbycap=GL_MAX_COLOR_TEXTURE_SAMPLES). 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.
Nicol Bolas
CC BY-SA 3.0
2016-11-07T04:07:02.297Z
Ahh, I stand corrected. Somehow missed when GPUs crossed the 8-sample threshold. That was the limit for a long time, IIRC.
Nathan Reed
<opengl><rendering><texture><color><subpixel-rendering>
Can I have lower color bit depth in sample buffer than target framebuffer?
Andreas
# Can I have lower color bit depth in sample buffer than target framebuffer?

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

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 ﬂoating-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?

**Tags:** opengl, rendering, texture, color, subpixel-rendering

> **Comments:**
> **username_1**: 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.  
> **username_0**: @username_1 Provide a reference of your claim. Yesterday i queried an Nvidia Quadro 4000 of possible framebuffer configurations and up to 64 samples was provided.  
> **username_2**: @username_1: Not true at all. There are [many implementations that support a sample count greater than 8](http://opengl.gpuinfo.org/gl_stats_caps_single.php?listreportsbycap=GL_MAX_COLOR_TEXTURE_SAMPLES). 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.  
> **username_1**: Ahh, I stand corrected. Somehow missed when GPUs crossed the 8-sample threshold. That was the limit for a long time, IIRC.  

---

## 1 answers

### Answer by username_2 on 2016-11-03. Score: 3 | Accepted answer

> 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.

> **Comments:**
> **username_0**: 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?  
> **username_2**: @username_0: 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.  
> **username_0**: 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.  

---

