Fix GL error occuring on pbuffer surface.

Fix GL_INVALID_OPERATION when querying FB config

Due to a possible Mesa bug[1], glGetFramebufferAttachmentParameteriv
fails with GL_INVALID_OPERATION when e.g. double buffering is disabled
and alpha bits are requested, which happens when pbuffer surfaces are
used. Since we don't need double buffering for pbuffer surfaces and
enabling it would increase memory consumption, we work around it by not
requesting this information when the surface is offscreen (which is
always true for pbuffer surfaces).

This will cause that the variables
`back_buffer_{color_format,has_depth,has_stencil}` stay at their
defaults (GL_RGBA, false, false), which shouldn't matter for an
offscreen surface.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=90162

BUG=474974

[mkollaro, 2015-04-24 13:00:11]

martina.kollarova@intel.com changed reviewers:
+ kbr@chromium.org, piman@chromium.org, thakis@chromium.org

[Nico, 2015-04-24 21:57:11]

thakis@chromium.org changed reviewers:
- thakis@chromium.org

[Nico, 2015-04-24 21:57:12]

Ken or piman are better reviewers for this, removing myself. Turning on
double-buffering seems pretty heavy.

[Ken Russell (switch to Gerrit), 2015-04-24 22:12:40]

Yes, turning on double-buffering for pbuffers on all GPUs is not acceptable to
work around a bug in Mesa.

A workaround should be defined for this problem in
src/gpu/config/gpu_driver_bug_* and used to conditionalize the workaround. Since
ui/gl is lower in the dependence chain than gpu/config/, I think we should just
avoid making the problematic glGetFramebufferAttachmentParameteriv calls on the
affected OpenGL drivers, getting the answers another way instead.

Can you please comment on the feasibility of this approach instead? Thanks.

[mkollaro, 2015-04-27 14:20:18]

On 2015/04/24 22:12:40, Ken Russell wrote:
> Yes, turning on double-buffering for pbuffers on all GPUs is not acceptable to
> work around a bug in Mesa.

Yes, I thought this might be the case, though I only ever saw the pbuffer
surface being used with a framebuffer of size 1x1, so it would only add a few
bits of overhead. However, it's hard for me to tell what other use cases this
surface has, so it would be better to make sure and implement a different
workaround. Maybe the whole call to glGetFramebufferAttachmentParameteriv could
be removed and glGetIntegerv could be used (as it was before the regression was
introduced).

[piman, 2015-04-27 23:33:33]

FYI, https://codereview.chromium.org/1081533003/ gets rid of pbuffer surfaces.

[mkollaro, 2015-05-05 08:35:10]

On 2015/04/27 23:33:33, piman (Very slow to review) wrote:
> FYI, https://codereview.chromium.org/1081533003/ gets rid of pbuffer surfaces.

Yeah, this removes the need for this patch completely. Closing.