Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Thomas White <taw@bitwiz.org.uk>
|
|
|
|
An improved workaround has now been committed.
This reverts commit 692fd8a500e0f9eadc703b29b0c7550f57863e29.
|
|
This is a horrible workaround for what I think must be a GCC bug. Remove that usleep(1),
or go back to the original CLAMP() macro, and glxdemo will have a white background
instead of a grey one. That is to say, the value 0.5 is getting clamped to 1.0 because
of some underlying floating-point weirdness. This happens when cross-compiling for
armv4t-angstrom-linux-gnueabi with GCC version 4.1.1 or 4.3.2.
|
|
|
|
|
|
It draws something!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's official. Indenting with spaces make me sick.
|
|
|
|
|
|
..and remove a commented out old thing from the Makefile
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Thomas White <taw@bitwiz.org.uk>
|
|
We probably don't want to propagate this condition to the pipe driver,
this reverts commit f455ca6490fcb65781b21f81c7117bd923e250d1 and the
dri_update_buffer flush altogether until an agreement is reached.
|
|
|
|
Undoes part of commit f455ca6 which would permit pipe->flush() to be
called while the VBO module still had its buffers mapped. Some
drivers care deeply about this. Sorry for not spotting this earlier.
|
|
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.
|
|
|
|
So far the frontbuffer was only being flushed on st_glFlush and
st_glFinish, however, a co-state tracker may need to make sure that
any frontbuffer changes are already on its way to the actual front.
The dri2 state tracker will need this for event-driven GL applications
to resize properly (It could also be done calling "dri_flush_frontbuffer",
but that way we would flush unnecessarily in the double-buffered case).
Additionally this patch avoids flushing the mesa rendering cache if
PIPE_FLUSH_RENDER_CACHE wasn't specified.
|
|
Core Mesa will not call ctx->Driver.CheckQuery() if the Ready flag
is already set.
|
|
|
|
|
|
|
|
|
|
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>
|