Some apps won't run w/ indirect rendering contexts.
Also, consolidate some context-init code in new init_glx_context() function.
(cherry-picked from master, commit 49e80bf6b1)
We only wanted to request when asked for the same set of buffers when a resize
has happened. We can just watch the protocol stream for a ConfigureNotify
and flag to do it then.
This is about a 5% win from doing two glViewport()s per frame in openarena.
Fixes bug 19835. However, a more elaborate fix should be implemented someday
which uses proper reference counting for gl_array_object.
(cherry picked from master, commit 88e0b92a74)
Previously, "in-place" swizzles such as:
MOV t, t.xxyx;
were handled incorrectly. Fixed by splitting the one loop into two loops so we
get all the refs before assigning them (to avoid potential clobbering).
(cherry picked from master/commit faa48915d2)
There were several bugs in the infrastructure for these two routines.
1. GLX_ALIAS was incorrectly used. The function and its alias must be
identical! glXMakeContextCurrent / glXMakeCurrentReadSGI and
MakeContextCurrent had different parameters. This caused the last
parameter of MakeContextCurrent to get random values.
2. We based the implementation of glXMakeContextCurrent on the manual
page instead of the GLX spec. The GLX spec says that
glXMakeContextCurrent can be passed a Window as a drawable. When this
happens, it will behave just like glXMakeCurrentReadSGI or
glXMakeCurrent.
3. If there was a problem finding or creating the DRI drawable,
MakeContextCurrent would crash instead of returning an error.
This commit fixes all three issues, and fixes bug #18367 and bug #19625.
The upstream linux kernel headers and libdrm kernel headers disagree on the
tag name for the sarea struct: _drm_i915_sarea vs drm_i915_sarea. They
both typedef it to drm_i915_sarea_t though, so just use that.
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
This utility is useful for hardware that doesn't support HW index buffers.
It's a bit inefficient but appears to give a substantial performance gain,
as we can emit tri strips that would otherwise be split into triangles.
Dri drivers often may validate first a write drawable and then a read
drawable ("readable"). However, the hardware lock may be unlocked when
validating the readable, causing the write drawable status to be stale.
Drivers should use this macro instead when validating two drawables.
