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

[Neil Roberts]

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.

Regards,
- Neil