I'm going to drop this patch and will fix the problematic piglit tests by not using the framebuffer size queries for intensity and luminance formats.
Marek On Mon, Mar 10, 2014 at 11:34 PM, Marek Olšák <mar...@gmail.com> wrote: > On Mon, Mar 10, 2014 at 6:07 PM, Brian Paul <bri...@vmware.com> wrote: >> On 03/09/2014 01:03 PM, Marek Olšák wrote: >>> >>> Do you have any opinion on this patch, anyone? >>> >>> Marek >>> >>> On Tue, Mar 4, 2014 at 12:32 PM, Marek Olšák <mar...@gmail.com> wrote: >>>> >>>> From: Marek Olšák <marek.ol...@amd.com> >>>> >>>> There is no API for returning the number of luminance and intensity bits >>>> and >>>> the 3.3 spec doesn't seem to specify any behavior for the queries if the >>>> format >>>> is one of L, LA, I. It seems to be a spec bug. >> >> >> I'm trying to piece together the background info on this. >> >> IIRC, in GL 3.3 core there are no luminance, l/a or intensity textures or >> surfaces anymore. And yeah, I don't see a >> GL_FRAMEBUFFER_ATTACHMENT_LUMINANCE_SIZE query in the 3.3 compat profile >> spec. >> >> So basically your patch will return a non-zero value if, for example, >> GL_FRAMEBUFFER_ATTACHMENT_RED_SIZE is called on a luminance buffer, right? > > Correct. > >> >> Is that what AMD and NVIDIA's drivers do? > > For 8-bit luminance and intensity, AMD Catalyst returns > RED/GREEN/BLUE_BITS=(8,0,0), but the renderbuffer and framebuffer > attachment queries return (0,0,0). > > I don't think (8,0,0) is correct, but the compatibility spec doesn't > say it's incorrect. > > Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
