| Summary: | [HSW] Mishandling of sample count when using an attachment-less framebuffer (assertion error) | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Ilia Mirkin <imirkin> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Looking a bit closer, in brw_upload_pipeline_state, we have:
unsigned int fb_samples = _mesa_geometric_samples(ctx->DrawBuffer);
...
if (brw->num_samples != fb_samples) {
brw->num_samples = fb_samples;
brw->ctx.NewDriverState |= BRW_NEW_NUM_SAMPLES;
}
Presumably you can't make an actual fb attachment with the "wrong" number of samples, but there's nothing to validate that here for the no-attachment case. Not sure if the correct fix is to apply the correction here, or if it should be handled in gen6_multisample_state.c directly.
I started looking into this and made a Piglit test for it here: http://patchwork.freedesktop.org/patch/72536/ The test shows up more problems in that the value of glGetInteger(GL_SAMPLES) and also gl_NumSamples in the fragment shader is always 0 with a framebuffer with no attachments. I think the solution would be to make these two variables use _mesa_geometric_samples and then somehow make that function give the driver a chance to return a quantized result. That would also fix the driver side when programming the multisample state because it already calls _mesa_geometric_samples to determine the sample count. Actually I wrote a test that will also hit it: http://patchwork.freedesktop.org/patch/72388/ But I never did an odd number of samples, that's just odd :) I think there is a big bit missing, which is something in between the default geometry's samples setting and the "real" one. Something like DefaultGeometry._Samples which gets set at _NEW_BUFFERS validation time maybe? And maybe by each driver directly. Thanks for the suggestion. I've posted a patch for it here: http://patchwork.freedesktop.org/patch/72634/ I've pushed all the patches here: http://cgit.freedesktop.org/mesa/mesa/commit/?id=eb9cf3cfc99db0cff0a5a584941e8b Ilia, thanks for the review and for confirming the Piglit test the NVidia driver. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
This manifests in the dEQP test: dEQP-GLES31.functional.fbo.no_attachments.multisample.samples2 gen6_multisample_state.c:150: gen6_emit_3dstate_multisample: Assertion `!"Unrecognized num_samples in gen6_emit_3dstate_multisample"' failed. (gdb) p brw->num_samples $1 = 2 But of course the minimum number of samples handled is 4. You're allowed to upgrade this in the driver, just like for glRenderbufferStorageMultisample. See the ARB_framebuffer_no_attachments spec: """ 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 (section 4.4.2). """