Extend the relaxation on readPixels to the multisample attachments created by core functions of ES 3.0 and later

[dreamelon]

As discussed here

the relaxation in the EXT spec is explicitly limited to attachments created via RenderbufferStorageMultisampleEXT / FramebufferTexture2DMultisampleEXT.

So from spec perspective, implementations should still distinguish whether the multisample attachment was created by:

EXT path → relaxation applies
Core path → no relaxation; GL_INVALID_OPERATION required

I would like to extend the relaxation to core path, would you agree @zmike @janharaldfredriksen-arm

[zmike]

Suggested change

	- Extend the relaxation on readPixels to the multisample attachments created
	- Extend the relaxation on ReadPixels to the multisample attachments created

[janharaldfredriksen-arm]

Hi,
I don't think we can make this change retrospectively - because existing implementations won't allow it. (Our does not, as a concrete example.)

I'm also not sure it would be the right thing to do (as part of this extension). This extension allowed ReadPixels on the implicitly resolved textures and renderbuffers precisely because the multisample data doesn't have to be preserved for them. I.e., ReadPixels can behave just like it does for non-multisampled data.

RenderbufferStorageMultisampleEXT and RenderbufferStorageMultisample are not straight aliases for this reason (despite what the naming implies).

For core multisampled textures (e.g. created via FramebufferTexture2D), I think we'd need to either:

• allow the implementation to throw away the multisample data on ReadPixels - but then we'd need spec language to say that
• require that multisample data is preserved, but in that case the behavior would effectively be the same as if you called BlitFramebuffer followed by ReadPixels today

In any case, I think that would have be done as a new extension.