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

GLhalf Should Be a Floating Point Type #334

Open
TheFloatingBrain opened this issue Jul 28, 2022 · 1 comment
Open

GLhalf Should Be a Floating Point Type #334

TheFloatingBrain opened this issue Jul 28, 2022 · 1 comment

Comments

@TheFloatingBrain
Copy link

TheFloatingBrain commented Jul 28, 2022

Hello, great library, I have been enjoying using it with strong typing guarantees and enum classes :)

I have been implementing some conversion code to associate opengl types with associated enum values for glVertexAttribPointer/Format

According too this and to the enum value (I would get you a line permalink but my browser is viewing glbinding/gl/enum.h as raw, but it is line 6999).

However it is defined as a short integer type.

Thanks - TFB :)

@scheibel
Copy link
Member

This is an interesting request.
It reminded me of an earlier issue here in glbinding: #236

However, I want to refer to other official, normative information on the GLhalf data type.
In the official C headers from Khronos, GLhalf is defined as follows:

typedef khronos_uint16_t GLhalf;

And in the gl.xml, it is defined as such:

<type requires="khrplatform">typedef khronos_uint16_t <name>GLhalf</name>;</type>

Which is of little surprise, as this XML mirrors the C header.

Coming from this, I think most platforms expect a GLhalf to be just storage from a CPU and RAM perspective. Only the GPU performs meaningful operations on them.
From what I see, I think that we just need some kind of placeholder type and not actual FP semantics.
I had a look into glm, a common dependency of our downstream projects that also use glbinding, and they even removed their half data type in the past.

Can you be a little more specific what you expect a GLhalf to behave?
In which scenarios do you need FP semantics?

Best,
Willy

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