API errors in anti aliasing tutorial

[JuanDiegoMontoya]

There are some invalid glTexParameteri calls here that generate some errors (highlighted):

https://github.com/VictorGordan/opengl-tutorials/blob/main/YoutubeOpenGL%2022%20-%20Anti-Aliasing/Main.cpp#L149-L152

The specification says:

An INVALID_ENUM error is generated by TexParameter* if target is ei-
ther TEXTURE_2D_MULTISAMPLE or TEXTURE_2D_MULTISAMPLE_ARRAY,
and pname is any sampler state from table 23.18.

If we look at table 23.18, we can indeed see that all four of those parameters are sampler states, making all of these calls illegal.

These calls should be removed.

P.S. multisample textures cannot be sampled in GLSL, but only read via texelFetch and imageLoad, so it makes sense that they wouldn't support sampler state.

[VictorGordan]

I assume it's not a major error since the code still works as intended. Right? I am curious what the solution is though. Especially because if I remember correctly those lines are there to prevent bleeding on the edges of the screen, but I might be remembering it incorrectly.

…

On Sat, Aug 12, 2023, 10:31 Jake Ryan ***@***.***> wrote: There are some invalid glTexParameteri calls here that generate some errors (highlighted): https://github.com/VictorGordan/opengl-tutorials/blob/main/YoutubeOpenGL%2022%20-%20Anti-Aliasing/Main.cpp#L149-L152 The specification says: An INVALID_ENUM error is generated by TexParameter* if target is ei- ther TEXTURE_2D_MULTISAMPLE or TEXTURE_2D_MULTISAMPLE_ARRAY, and pname is any sampler state from table 23.18. If we look at table 23.18, we can indeed see that all four of those parameters are sampler states, making all of these calls illegal. P.S. multisample textures cannot be sampled in GLSL, but only read via texelFetch and imageLoad, so it makes sense that they wouldn't support sampler state. — Reply to this email directly, view it on GitHub <#24>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARU6BYZXJTY7RW2XPNLDZBDXU45MNANCNFSM6AAAAAA3NZOQXY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JuanDiegoMontoya]

Those calls are not a major issue, no (in that the program still appears to work with them), but conformant drivers will report it via the various error mechanisms that OpenGL supports. We found this error when I was helping another user (who was following the tutorial) who had an error elsewhere and set up the debug callback to pinpoint it.

W.R.T. possible bleeding, the specification notes that the samples will be resolved in an implementation-defined manner when using 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 floating-point or normalized types,
the sample values for each pixel are resolved in an implementation-dependent
manner.

However, because the blit source and target must have the same dimensions (otherwise is an error) and the filter is ignored, a sane driver should not read outside pixels at all. It should just resolve the samples of one pixel via some kind of mean and output it to exactly one target pixel.

In any case, I think the calls should be removed with no replacement, as I do not see how they could benefit the program. If bleeding occurs without setting the wrap behavior of the multisample texture, you should report that to your driver vendor.