This might be a long shot.
I'm working on an OpenGL app, and discovered that there don't appear to be any texture formats with more than 8 bits per pixel available on my 915GM chip, using the DRI i810 driver.
I queried this by calling
glTexImage2D() with a target of GL_PROXY_TEXTURE_2D and an internal format of, for example, GL_RGB10_A2, GL_LUMINANCE16_ALPHA16, etc. (I actually tried all possible values) and appropriate other parameters. I then queried the exact format used by the hardware using
glGetTexLevelParameteriv(GL_PROXY_TEXTURE_2D, 0, GL_TEXTURE_RED_SIZE, &r);
for red, green, blue, alpha, lum, intensity channels. None of these ever yielded anything with more than 8 bits for any given channel.
Of course, this is allowed and compliant behaviour for an OpenGL implementation; however, I cross-checked what the hardware supports under Windows in Direct3D using the "DX Caps Viewer" tool, and this lists a number of texture formats with higher precision, among these the RGB10_A2 format and some 2-component, 16-bits-per-channel formats. In fact, the hardware can even render-to-texture on RGB10_A2. Note that I'm talking about fixed-point formats. I'm aware that floating-point textures are not available on the hardware.
Interestingly, the Win32 OpenGL driver exposes the same texture formats (max 8 bits) as the X.org/DRI one; I'm not sure what this means or explains, it's just an interesting data point.
In any case, I was wondering whether there were any plans to expose the formats supported by the hardware, or how hard this would be to do. (or, for that matter, GL_EXT_framebuffer_object, but that's a separate matter...)
I might even be persuaded to volunteer for implementing this myself, although I've never worked on X.org or DRI, and my experience of directly programming graphics hardware is limited to video game consoles, so it would require a healthy dose of documentation and helpful pointers on where to start...
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
I'll mark this as resolve later for future development reference.
Mass reopen. The "LATER" resolution is lame, I'm deleting it. Consider LATER to have arrived.
on Dec 08, 2016 at 00:04:57.
(provided by the Example extension).