[Piglit] [PATCH] arb_fb_no_attach: Test with an odd sample count

[Ilia Mirkin]

On Thu, Feb 4, 2016 at 9:32 AM, Neil Roberts <neil at linux.intel.com> wrote:
> Ilia Mirkin <imirkin at alum.mit.edu> writes:
>
>>> +       "        imageStore(img,\n"
>>> +       "                   ivec2(gl_FragCoord.xy),\n"
>>> +       "                   uvec4(gl_NumSamples));\n"
>>
>> Could I convince you to use ssbo instead? Not only is it supported by
>> nouveau [unlike images... for now], but I think it's a better match as
>> well :) Probably just a single integer and a 1x1 framebuffer.
>
> Ah yes, that is a good idea. Sure, I will do that.
>
>>> +       glGetIntegerv(GL_SAMPLES, &actual_n_samples);
>>
>> Oh interesting. I was trying to use glGetFramebufferParameteriv and
>> turns out it only does GL_SAMPLES for GL 4.5 :( How sure are you that
>> this is supposed to work?
>
> Are you asking whether I think the value of the
> FRAMEBUFFER_DEFAULT_SAMPLES should affect GL_SAMPLES for a framebuffer
> with no attachments? Well, it's pretty hard to get a definitive answer
> out of the GL spec (as usual) but I think the intention is that it
> should work. In section 9.2.1 of the GL 4.4 there is this:
>
>  When a framebuffer has no attachments […] it is considered to have
>  sample buffers if and only if the value of FRAMEBUFFER_DEFAULT_SAMPLES
>  is non-zero. The number of samples in the framebuffer is derived from
>  the value of FRAMEBUFFER_DEFAULT_SAMPLES in an implementation-dependent
>  manner similar to that described for the command
>  RenderbufferStorageMultisample (see section 9.2.4).
>
> So that implies that it should have samples, but that doesn't say
> anything about the actual value of GL_SAMPLES. That is defined in
> section 9.4.2:
>
>  The values of SAMPLE_BUFFERS and SAMPLES are derived from the
>  attachments of the currently bound draw framebuffer object. If the
>  current DRAW_FRAMEBUFFER_BINDING is not framebuffer complete, then both
>  SAMPLE_BUFFERS and SAMPLES are undefined. Otherwise, SAMPLES is equal
>  to the value of RENDERBUFFER_SAMPLES or TEXTURE_SAMPLES (depending on
>  the type of the attached images), which must all have the same value.
>  Further, SAMPLE_BUFFERS is one if SAMPLES is non-zero. Otherwise,
>  SAMPLE_BUFFERS is zero.
>
> That doesn't mention the framebuffer default values but it also seems
> like an oversight because it is written as if it is assuming all
> complete framebuffers have an attachment.
>
> The rest of the spec uses the value of GL_SAMPLE_BUFFERS to determine
> whether it should be doing multisample rendering. If this value wasn't
> affected by the framebuffer default values I guess that implies that
> setting FRAMEBUFFER_DEFAULT_SAMPLES doesn't cause it to do multisample
> rendering? If that's correct then what use is
> FRAMEBUFFER_DEFAULT_SAMPLES at all?
>
> It would be interesting to verify what happens on another driver. If we
> do decide that it should work then we could make the test check
> GL_SAMPLE_BUFFERS as well.

There's a khronos bug referenced in the GL 4.5 "changes" section re
why it was added go glGetFramebufferParameteriv:

"Allow GetFramebufferParameteriv and GetNamedFramebufferParameteriv in
section 9.2.3 to be used to query the framebuffer-dependent state in
table 23.73, including queries for the default framebuffers (Bug
12360)."

This bug is, of course, not visible to schmoes like me, but perhaps
you can glean something interesting from that?

  -ilia