On Thu, May 17, 2012 at 3:34 PM, Brian Paul <bri...@vmware.com> wrote: > 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. 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. > > > Do you want to implement this change or should I?
Feel free to. I probably won't have any time to do anything Mesa-related until weekend or next week. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
