On 05/17/2012 07:20 AM, Marek Olšák wrote:
On Mon, May 14, 2012 at 6:59 PM, Brian Paul<bri...@vmware.com> wrote:
On 05/14/2012 10:44 AM, Marek Olšák wrote:
On Mon, May 14, 2012 at 4:40 PM, Brian Paul<bri...@vmware.com> wrote:
On 05/12/2012 10:11 AM, Marek Olšák wrote:
It may fail with an unsupported format, but that's not an allowed case
where
RenderbufferStorage may fail.
I've read your comment several times but I still can't quite understand
the
whole issue.
The intention was that AllocStorage() should never fail because of the
internalFormat value. We do error checking of internalFormat earlier in
renderbuffer_storage(). Then the driver chooses a hw format that best
matches the requested internalFormat.
The driver is r600g and the format is GL_RGB9_E5
(EXT_texture_shared_exponent). There is sampler support, but no
colorbuffer support. The format is quite special, no other format
matches it well, though I guess any RGB float format would work.
However the spec doesn't require renderbuffer support despite the fact
the format is accepted in glRenderbufferStorage.
This looks like a spec/documentation issue. The GL 3.0 spec (page 180) says
GL_RGB9_E5 is a texture-only format. But the GL_EXT_texture_shared_exponent
spec says it's accepted by glRenderbufferStorage.
I just hacked up a quick test for the NVIDIA driver. Passing GL_RGB9_E5 to
glRenderbufferStorage() generates a GL_INVALID_OPERATION error.
Actually, I take that back. I made a mistake in my test program.
GL_INVALID_OPERATION was being generated because of a missing
glBindRenderbuffer() call. Grrr.
NVIDIA seems to accept GL_RGB9_E5, GL_R11F_G11F_B10F and GL_RGB10_A2UI
as internalFormat. No error is generated. But I get a
GL_FRAMEBUFFER_UNSUPPORTED when I check the framebuffer status.
Mesa will
need some changes if we want to generate the same error, rather than
GL_INVALID_ENUM.
Could you test w/ AMD's driver?
The AMD driver also generates GL_INVALID_OPERATION.
Looks like we should defer specific format checking until FBO
validation time.
Still, some Mesa clean-ups are in order...
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
