Bug 9875 - Pixel formats with >8 bits per channel not available via OpenGL although apparently supported by hardware
Pixel formats with >8 bits per channel not available via OpenGL although appa...
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915
x86 (IA32) Linux (All)
: low enhancement
Assigned To: Default DRI bug account
Depends on:
  Show dependency treegraph
Reported: 2007-02-04 08:59 UTC by Phillip Jordan
Modified: 2008-02-24 18:22 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Phillip Jordan 2007-02-04 08:59:29 UTC
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...

Comment 1 Daniel Stone 2007-02-27 01:36:10 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 2 Michael Fu 2008-02-18 23:08:06 UTC
I'll mark this as resolve later for future development reference.
Comment 3 ajax at nwnk dot net 2008-02-24 18:22:26 UTC
Mass reopen.  The "LATER" resolution is lame, I'm deleting it.  Consider LATER to have arrived.