Can linear filtering be used for an FBO blit of an MSAA texture to non-MSAA texture?

Question

I have two 2D textures. The first, an MSAA texture, uses a target of GL_TEXTURE_2D_MULTISAMPLE. The second, non MSAA texture, uses a target of GL_TEXTURE_2D.

According to OpenGL's spec on ARB_texture_multisample, only GL_NEAREST is a valid filtering option when the MSAA texture is being drawn to.

In this case, both of these textures are attached to GL_COLOR_ATTACHMENT0 via their individual Framebuffer objects. Their resolutions are also the same size (to my knowledge this is necessary when blitting an MSAA to non-MSAA).

So, given the current constraints, if I blit the MSAA holding FBO to the non-MSAA holding FBO, do I still need to use GL_NEAREST as the filtering option, or is GL_LINEAR valid, since both textures have already been rendered to?

Whang

Answer 1

The filtering options only come into play when you sample from the textures. They play no role while you render to the texture.

When sampling from multisample textures, GL_NEAREST is indeed the only supported filter option. You also need to use a special sampler type (sampler2DMS) in the GLSL code, with corresponding sampling instructions.

I actually can't find anything in the spec saying that setting the filter to GL_LINEAR for multisample textures is an error. But the filter is not used at all. From the OpenGL 4.5 spec (emphasis added):

When a multisample texture is accessed in a shader, the access takes one vector of integers describing which texel to fetch and an integer corresponding to the sample numbers described in section 14.3.1 determining which sample within the texel to fetch. No standard sampling instructions are allowed on the multisample texture targets, and no filtering is performed by the fetch.

For blitting between multisample and non-multisample textures with glBlitFramebuffer(), the filter argument can be either GL_LINEAR or GL_NEAREST, but it is ignored in this case. From the 4.5 spec:

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.

This makes sense because there is a restriction in this case that the source and destination rectangle need to be the same size:

An INVALID_OPERATION error is generated if either the read or draw framebuffer is multisampled, and the dimensions of the source and destination rectangles provided to BlitFramebufferare not identical.

Since the filter is only applied when the image is stretched, it does not matter in this case.

Rager

I think since the only way you can sample a multisampled texture is to use texelFetch (...), it's more or less implied that most sampler states are meaningless (e.g. wrap mode, filter, LOD bias). Like you said, it's not an error as-per the spec. to set these states, but if you had to describe the behavior using a filter then point / nearest would be the only candidate. – Proverb

@AndonM.Coleman Yes, I think that's exactly what the first spec quote describes, where I highlighted "no filtering is performed". – Rager

Yeah, I just wanted to point out that you can set those sampler states, they just don't do anything :p Sampler objects separate those states from texture object state, and probably would have made this question a non-issue. But because of GL's legacy design, multisample texture objects have sampler states associated with them that don't do anything (since they're not sampled). – Proverb