Can linear filtering be used to multiply the FBO MSAA texture for a non-MSAA texture?
I have two 2D textures. The first, the MSAA texture, uses a target GL_TEXTURE_2D_MULTISAMPLE
. The second non-MSAA texture uses target GL_TEXTURE_2D
.
According to the OpenGL spec on ARB_texture_multisample , this GL_NEAREST
is only a valid filtering parameter when drawing an MSAA texture.
In this case, both of these textures are bound to GL_COLOR_ATTACHMENT0
through their separate Framebuffer objects. Their permissions are also the same size (as far as I know this is necessary when blitting MSAA for non-MSAA).
So, given the current limitations, if I blit MSAA holding FBO for non-MSAA holding FBO, do I still need to use GL_NEAREST
filtering or GL_LINEAR
valid as parameter since both textures have already been rendered?
source to share
Filtering options are enabled only if sampling from textures. They don't matter as long as you render the texture.
When sampling from multiprocessor textures, this is GL_NEAREST
indeed the only supported filter option. You also need to use a special sampler type ( sampler2DMS
) in your GLSL code with the appropriate sampling instructions.
Actually I cannot find anything in the spec stating that setting the filter GL_LINEAR
for multiprocessing textures is a bug. But the filter is not used at all. From the OpenGL 4.5 spec (emphasis mine):
When a multiprocessor texture is accessed in a shader, access takes one vector of integers describing which texel to retrieve, and an integer corresponding to the sample numbers described in section 14.3.1, which determines which texel to retrieve. Standard sampling instructions are not allowed for the purpose of multisampling textures, rather than filtering by sampling.
For blitting between multisample and non-multisampled textures, the glBlitFramebuffer()
filter argument can be either GL_LINEAR
or GL_NEAREST
, but in this case it is ignored. From spec 4.5:
If the framebuffer being read is multisampled (its effective SAMPLE_BUFFERS value is one) and the postback framebuffer (its SAMPLE_BUFFERS value is zero), the samples corresponding to each pixel position in the source are converted to one sample before being written to the destination. the filter is ignored .
This makes sense because in this case there is a limitation that the source and destination rectangles must be the same size:
The INVALID_OPERATION error is generated if the read or draw frameserver is multisampled and the source and target rectangle sizes provided by BlitFramebuffer are not identical.
Since the filter is only applied when the image is stretched, it doesn't matter in this case.
source to share