Created attachment 322943 [details] [review]
glmemory: fix copy texture fail using glCopyTexImage2D()

Just curious as to what system/platforms you saw this on?

The only case I've seen this matter is on iOS where they implement a different rg texture extension to everyone else and seem to not conform to their own rg texture extension.

The internal format doesn't technically have to be sized everywhere, i.e. you can pass base internal formats on most systems and have things work.

That being said, we've done this for all the other texture operations, may as well do it for copy as well.

Note: this patch doesn't apply at all to current master.

(In reply to Matthew Waters (ystreet00) from comment #2)
> Just curious as to what system/platforms you saw this on?
> 
> The only case I've seen this matter is on iOS where they implement a
> different rg texture extension to everyone else and seem to not conform to
> their own rg texture extension.
> 
> The internal format doesn't technically have to be sized everywhere, i.e.
> you can pass base internal formats on most systems and have things work.
> 
> That being said, we've done this for all the other texture operations, may
> as well do it for copy as well.
Hi Matthew,

I meet this case on i.Mx6Q for Linux. The GPU vendor is vivante GC2000. If I use texture format such as GL_RED, copy texture will fail. But change to use GL_R8, it works ok. I think we should call API according to the GL spec because some Embedded systems may have limitation.

The spec allows GL_RED/GL_RG as an internal format so your drivers are not compliant.

From the GLES 3.0.1 spec, section 3.8.3, page 125.

"If internalformat is specified as a base internal format, the GL stores the resulting texture with internal component resolutions of its own choosing."

GLES 2.0 doesn't contain RG textures so we rely on the GL_EXT_texture_rg extension from https://www.khronos.org/registry/gles/extensions/EXT/EXT_texture_rg.txt which states:

"Accepted by the <internalformat> parameter of TexImage2D and CopyTexImage2D, and the <format> parameter of TexImage2D, TexSubImage2D, and ReadPixels:

RED_EXT 0x1903
RG_EXT  0x8227"

If by some weird reason there's GL_ARB_texture_rg support with your drivers, they also contain the exact same statement as GL_EXT_texture_rg (albeit with more formats).

Closing due to inactivity/cause being in the GL driver.