Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
This may break the SUNOS4 build, but it's no longer relevant.
|
|
This may break the SUNOS4 build, but it's no longer relevant.
|
|
This may break the SUNOS4 build, but it's no longer relevant.
|
|
|
|
|
|
|
|
|
|
|
|
We need to do this before we emit any state dependent on the current
render buffers.
|
|
|
|
This uses a stamp mechanisms to mark the DRI drawable as invalid.
Instead of immediately updating the buffers we just bump the drawable
stamp and call out to DRI2GetBuffers "later".
"Later" used to be at LOCK_HARDWARE time, and this patch brings back
callouts at the points where we used to call LOCK_HARDWARE. A new function,
intel_prepare_render(), is called where we used to call LOCK_HARDWARE,
and if the buffers are invalid, we call out to DRI2GetBuffers there.
This lets us invalidate buffers only when notified instead of on
every glViewport() call. If the loader calls the DRI invalidate
entrypoint, we disable viewport triggered buffer invalidation.
Additionally, we can clean up the old viewport mechanism a bit,
since we can just invalidate the buffers and not worry about
reentrancy and whatnot.
|
|
|
|
|
|
|
|
When a buffer invalidation event is received from the X server, the
"invalidate" hook of the DRI2 flush extension is executed: A generic
implementation (dri2InvalidateDrawable) is provided that just bumps
the "pStamp" sequence number in __DRIdrawableRec.
For old servers not supporting buffer invalidation events, the
invalidate hook will be called before flushing the fake front/back
buffer (that's typically once per frame -- not a lot worse than the
situation we were in before).
No effort has been made on preserving backwards compatibility with
version 2 of the flush extension, but I think it's acceptable because
AFAIK no released stack is making use of it.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now that we track the global name in struct intel_region, we can just
look it up there.
|
|
|
|
We just threw it away before, but we haven't had a use for it yet.
|
|
This reverts commit 325614a882f5371da512536e07c443a172ffb87c.
Ok this was already fixed this commit actualy broke things
|
|
To avoid kernel complaining and to set proper boundary on
vbo, substract the vbo offset to the vbo size.
|
|
to make kernel cs checker happier, last attribs don't need full stride of
space. Calculate as count-1*stride + size of attrib
|
|
normalized seems to work with this setting.
|
|
|
|
|
|
|
|
Phew, sure is nice to only have one struct called intel region.
|
|
|
|
|
|
|
|
Fixes fallout from 9a1bf52c.
|
|
A number of places in 3cce4a1e10361458630511543b7a8a6438544775 use
TRUE instead of GL_TRUE. This causes build failures in all of the
drivers that I don't typically build. Win.
Reported by sungami on IRC.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
We can't always guarantee that the swap will happen by exchange, so we
can't expose this mode. GLX_SWAP_UNDEFINED_OML already covers the
case where the swap *might be* by exchange.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Expose one config per color depth that includes accumulation buffer.
We could probably expose only one config with accumulation buffer, but
that would require figuring out the actual color depth. This is
easier and only exposes 2 useless configs.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Modify the interface to driCreateConfigs allowing drivers to not
expose configs with an accumuation buffer. All of the drivers calling
function have been updated to pass true for the accumulation
selector. This maintains the current behavior.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|