It is possible for ctx->DrawBuffer to be NULL, so don't fault when
that happens. This change is not being committed to master because it
doesn't appear to be necessary there.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cherry picked from mesa_7_4_branch, commit 49e0c74ddd
Hook up a constant buffer, binding table, etc for the VS unit.
This will allow using large constant buffers with vertex shaders.
The new code is disabled at this time (use_const_buffer=FALSE).
We don't update drawables anymore unless they are completely
uninitialized, so we need to swap even if we don't have
cliprects yet, otherwise we never end up calling the driver's
SwapBuffers(). The driver should update the drawable in its
SwapBuffers() anyway.
See 8e753d04045a82062ac34d3b2622eb9dba8af374,
"dri glx: Fix dri_util::driBindContext" for the change that
exposed it.
Unfortunately this doesn't catch all the cases, as the mesa state tracker
can still use the framebuffer without giving the wgl state tracker
the chance to lock it.
intel / DRI2: Accept fake front-buffer from loader
Handle the loader returning a fake front-buffer. Since the driver
never specifically requests a fake front-buffer, the driver assumes
that it will never receive both a fake and a real front-buffer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
Assume that the front-buffer exists even if the server didn't tell the
client that it exists.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
intel / DRI2: Track and flush front-buffer rendering
Track two flags: whether or not front-buffer rendering is currently
enabled and whether or not front-buffer rendering has been enabled
since the last glFlush. If the second flag is set, the front-buffer
is flushed via a loader call back. If the first flag is cleared, the
second flag is cleared at this time.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>