Is there a fast way to clear an OpenGL buffer with a double-precision data type or set a default value with an API call to avoid using a compute shader?
For half- and single-precision types, glClearBufferData/glClearNamedBufferData can be used, but it appears like there is no internal format enum for 64 bit types, which makes the switch from single- to double-precision data in scientific computing applications more cumbersome. Or am I missing an extension?
I am looking for a solution that works with OpenGL 4.6, Nvidia-specific extensions are fine.
At the end of the day, a "double" is just a way of interpreting 64-bits of data. Your goal is to get the right 64-bits into your buffer.
As far as buffer clearing is concerned, the image format and pixel transfer parameters are just an explanation of how to interpret the data you pass. If the internal format of the clearing operation is GL_RG32UI, then each "pixel" in the buffer is 64-bits of data.
Given that, all you need to do is to get the clearing function to take a block of 64-bits and copy it exactly as you provide it. To do this, you have to use the right pixel transfer parameters.
See, pixel transfer operations can perform data conversion, taking the data pointer you pass and converting it to match the internal format. You don't want that; you want a direct copy. So your pixel transfer parameters need to exactly match the internal format. Which is quite easy.
A format of GL_RG_INTEGER represents a two-component pixel that stores integer data, in red-green order. And a type of GL_UNSIGNED_INT means that each component is a 32-bit unsigned integer. This exactly matches the internal format of GL_RG32UI, so the copying algorithm won't mess with the bytes of your data.
So, given some 64-bit double value in C or C++, clearing a buffer to that double ought to be as simple as:
void clear_buffer_to_double(GLuint buffer, double dbl)
{
glClearNamedBufferData(buffer, GL_RG32UI, GL_RG_INTEGER, GL_UNSIGNED_INT, &dbl);
}
Related
QColor can return rgba values of type int (32-bit signed integer). Why is that? The color values range from 0-255, don't they? Is there any situation where this might not be the case?
I'm considering to implicitly cast each of the rgba values returned by QColor.red()/green()/blue()/alpha() to quint8. It seems to work but I don't know if this will lead to problems in some cases. Any ideas?
I assume you are talking about QColor::rgba() which returns a QRgb.
QRgb is an alias to unsigned int. In these 32 bits all fours channels are encoded as #AARRGGBB, 8 bits each one (0-255, as you mentioned). So, a color like alpha=32, red=255, blue=127, green=0 would be 0x20FF7F00 (553615104 in decimal).
Now, regarding your question about casting to quint8, there should be no problem since each channel is guaranteed to be in the range 0..255 (reference). In general, Qt usually uses int as a general integer and do not pay too much attention to the width of the data type, unless in some specific situations (like when it is necessary for a given memory access, for example). So, do not worry about that.
Now, if these operations are done frequently in a high performance context, think about retrieving the 32 bits once using QColor::rgba and then extract the components from it. You can access the individual channels using bitwise operations, or through the convenience functions qAlpha, qRed, qBlue and qGreen.
For completeness, just to mention that the sibbling QColor::rgb method returns the same structure but the alpha channel is opaque (0xFF). You also have QColor::rgba64, which returns a QRgba64. It uses 16 bits per channel, for higher precision. You have the 64 bits equivalents to qAlpha, etc, as qAlpha64 and so on.
Vulkan allows you to specify attributes as multi-component byte arrays such as with the qualifier "VK_FORMAT_R8G8B8_UINT". I am, however, unsure what input variable type I should use in my glsl shader. Using an ivec3 creates an error as I would expect.
Do I need to load them into an uint and then do bitwise operations do extract the variables? What are the speed implications of this?
If I want to do these bitwise operations, how can I be sure they will be endian-independent? To my understanding, the first byte on my CPU side could be stored in the first or last byte of the integer on the GPU side.
There is nothing to "extract". You asked to pass 3 unsigned integer values per-vertex. That's what the format defines, and that's what the shader should receive. The fact that each unsigned integer value is 8 bits doesn't need to be reflected in your shader; only that they're unsigned integers and that there are 3 of them.
There are no endian issues; not unless you create them in your CPU code. The format specifies that each value of the attribute comes from an array of 3 8-bit values. The three components are read left-to-right, and that's the order the components are expected to be in in memory.
Bytes don't have endian problems. Endian only is an issue when reading a single value that takes up multiple bytes. You asked to read 3 bytes, so that's what it will do. And that's what the CPU should write.
BTW, you should avoid using misaligned types like this. Pad it out to 4 8-bit integers rather than 3.
glTexImage2D takes internalFormat (which specifies number of bits and data type/encoding), format (without number of bits and encoding) and type.
Is it possible, for example, to let OpenGL convert passed pixel data containing 32 bit integers from format GL_RGB_INTEGER and type GL_INT to internal format GL_RGB32F?
The wiki article https://www.khronos.org/opengl/wiki/Pixel_Transfer#Format_conversion suggests to me it's possible by stating:
Pixels specified by the user must be converted between the user-specified format (with format and type) and the internal representation controlled by the image format of the image.
But I wasn't able to read from floating point sampler in shader.
The _INTEGER pixel transfer formats are only to be used for transferring data to integer image formats. You are filling in a floating-point texture, so that doesn't qualify. You should have gotten an OpenGL Error.
Indeed, the very article you linked to spells this out:
Also, if "_INTEGER" is specified but the image format is not integral, then the transfer fails.
GL_RGBA32F is not an integral image format.
If you remove the _INTEGER part, then the pixel transfer will "work". OpenGL will assume that the integer data are normalized values, and therefore you will get floating-point values on the range [-1, 1]. That is, if you pass a 32-bit integer value of 1, the corresponding floating-point value will be 1/(2^31-1), which is a very small number (and thus, almost certainly just 0.0).
If you want OpenGL to cast the integer as if by a C cast (float)1... well, there's actually no way to do that. You'll just have to convert the data yourself.
The OpenGL documentation says very little about these two functions. When it would make sense to use glTexParameterIiv instead of glTexParameteriv or even glTexParameterfv?
If the values for GL_TEXTURE_BORDER_COLOR are specified with glTexParameterIiv or glTexParameterIuiv, the values are stored unmodified with an internal data type of integer. If specified with glTexParameteriv, they are converted to floating point with the following equation: f=(2c+1)/(2b−1). If specified with glTexParameterfv, they are stored unmodified as floating-point values.
You sort of answered your own question with the snippet you pasted. Traditional textures are fixed-point (unsigned normalized, where values like 255 are converted to 1.0 through normalization), but GL 3.0 introduced integral (signed / unsigned integer) texture types (where integer values stay integers).
If you had an integer texture and wanted to assign a border color (for use with the GL_CLAMP_TO_BORDER wrap mode), you would use one variant of those two functions (depending on whether you want signed or unsigned).
You cannot filter integer textures, but you can still have texture coordinate wrap behavior. Since said textures are integer and glTexParameteriv (...) normalizes the color values it is passed, an extra function had to be created to keep the color data integer.
You will find this same sort of thing with glVertexAttribIPointer (...) and so forth; adding support for integer data (as opposed to simply converting integer data to floating-point) to the GL pipeline required a lot of new commands.
I am using GL_RGB10_A2UI internal format in glCopyTexImage1D() API but getting GL_INVALID_OPERATION error. Does OpenGL 3.3 support GL_RGB10_A2UI in glCopyTexImage1D() ?
GL_RGB10_A2UI is an integral image format; it contains integers, not normalized floating-point values that are stored as integers. Therefore, unless your framebuffer also contains unsigned integer values, this copy operation will fail with the expected error.
Of course, the only way for your framebuffer to have unsigned integers (rather than unsigned normalized integers, which is the usual case) would be to use an FBO. In which case, you could just be rendering directly to this texture, and you wouldn't need to copy from it.
I'm guessing you probably meant to use GL_RGB10_A2, which represent unsigned normalized values.