Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glTextureSubImage3d invalid pixel types #93

Closed
mfiano opened this issue Feb 10, 2020 · 1 comment
Closed

glTextureSubImage3d invalid pixel types #93

mfiano opened this issue Feb 10, 2020 · 1 comment

Comments

@mfiano
Copy link
Contributor

mfiano commented Feb 10, 2020

The GL documentation specifies the following for glTextureSubImage3d:

type
Specifies the data type of the pixel data. The following symbolic values are accepted: GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_FLOAT, GL_UNSIGNED_BYTE_3_3_2, GL_UNSIGNED_BYTE_2_3_3_REV, GL_UNSIGNED_SHORT_5_6_5, GL_UNSIGNED_SHORT_5_6_5_REV, GL_UNSIGNED_SHORT_4_4_4_4, GL_UNSIGNED_SHORT_4_4_4_4_REV, GL_UNSIGNED_SHORT_5_5_5_1, GL_UNSIGNED_SHORT_1_5_5_5_REV, GL_UNSIGNED_INT_8_8_8_8, GL_UNSIGNED_INT_8_8_8_8_REV, GL_UNSIGNED_INT_10_10_10_2, and GL_UNSIGNED_INT_2_10_10_10_REV.

However I'm experiencing a few problems. For Direct State Access, to upload a cube map is a bit strange -- you're required to use glTextureStorage2d first, and then glTextureSubImage3d to upload each face as if it were a layer of a 2d texture array. The strange part is you must allocate storage with the 2d storage call, and fill it with the 3d call, unlike a 2d texture array.

Anyway, doing this works fine, assuming I am uploading :unsigned-byte data. My cube maps have 4 bytes per pixel, and when using any of the more advanced pixel types to try to get that data on the GPU, I receive the following errors:

:unsigned-int-8-8-8-8
OpenGL signalled (1282 . INVALID-OPERATION) from TEXTURE-SUB-IMAGE-3D.
This one is strange. It's producing an invalid operation error, which is supposed to indicate that the texture does not yet exist, even though I previously allocated it with glTextureStorage2d.

:unsigned-int-8-8-8-8-rev
:UNSIGNED-INT-8-8-8-8-REV is not defined as a keyword for enum type #<CFFI::FOREIGN-ENUM CL-OPENGL-BINDINGS::PIXEL-TYPE>.

:unsigned-int-10-10-10-2
OpenGL signalled (1282 . INVALID-OPERATION) from TEXTURE-SUB-IMAGE-3D. Again, strange like :unsigned-int-8-8-8-8.

:unsigned-int-2-10-10-10-rev
:UNSIGNED-INT-2-10-10-10-REV is not defined as a keyword for enum type #<CFFI::FOREIGN-ENUM CL-OPENGL-BINDINGS::PIXEL-TYPE>.

I am unable to upload a 32bpp cubemap face at all. This may be related to #92 since I am on that branch.

Additionally, I have a related issue not related to cl-opengl, but the specification itself. Because of the new way to upload cubemaps with DSA using glTextureStorage2d and glTextureSubImage3d, I am unable to upload :rgb9-e5/:unsigned-int-5-9-9-9-rev at all, because :unsigned-int-5-9-9-9-rev is not a valid pixel type for glTextureSubImage3d at all. Advice needed :)

@3b 3b mentioned this issue Feb 10, 2020
13 tasks
@3b
Copy link
Owner

3b commented Feb 10, 2020

from irc discussion, it seems like the invalid-operation errors were user error, and :unsigned-int-5-9-9-9-rev should be supported according to spec, so that's a bug in man pages. Remaining "not defined as a keyword" errors are #92, so closing this.

@3b 3b closed this as completed Feb 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants