search

KhronosGroup / OpenGL-API

OpenGL and OpenGL ES API Issue Tracker
34 stars 5 forks source link

The data type of sizedinternalformat for TexStorage{2D|3D}Multisample in GLES 3.1/3.2 should be "enum". #30

Closed Richard-Yunchao closed 6 years ago

Richard-Yunchao commented 6 years ago

The data type of sizedinternalformat for TexStorage{2D|3D}Multisample in GLES 3.1/3.2 specifications are "int", but the data type of sizedinternalformat for TexStorage{2D|3D}Multisample in OpenGL specs are "enum", and the data type of internalformat/sizedinternalformat in similar APIs like TexStorage{2D|3D} are all "enum". So I think the data type in GLES should be "enum" too, which is aligned with the majority of this kind data type.

In addition, it also use "enum" (not "int") for internalformat in TexStorage2DMultisample in GLES 3.1/3.2 manual page: GLES 3.1: https://www.khronos.org/registry/OpenGL-Refpages/es3.1/html/glTexStorage2DMultisample.xhtml. GLES 3.2: https://www.khronos.org/registry/OpenGL-Refpages/es3/html/glTexStorage2DMultisample.xhtml

WDYT?

The GLES 3.1 spec: https://www.khronos.org/registry/OpenGL/specs/es/3.1/es_spec_3.1.pdf The GLES 3.2 spec: https://www.khronos.org/registry/OpenGL/specs/es/3.2/es_spec_3.2.pdf

pdaniell-nv commented 6 years ago

Yes, these should be "enum". Historically the texture functions took "int" as their internalFormat because OpenGL 1.0 used to support parameters like "1", "2" and "4". We have since cleaned that up to be "enum", but clearly missed this case.

@oddhack could you take care of this? Thanks.

oddhack commented 6 years ago

This will be fixed in the upcoming update to the ES 3.2 spec. Also changed the formal parameter name to internalformat, to match GL, gl.xml, and the headers.