| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This may break the SUNOS4 build, but it's no longer relevant.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit fc427d23439a2702068209957f08990ea29fe21b.
At least xorg uses this, and just because something is not used in
OpenGL is *never* a valid reason to remove functionality from Gallium.
If something lacks a test, go add a test, don't remove features.
|
| |
|
| |
|
|
|
|
| |
Just follow gcc's advices here.
|
|
|
|
|
|
| |
The macros give warnings when compiled with -pedantic. This commit is
based on a patch by Brian Paul, with minor changes to add do {} while(0)
and rename the check macros.
|
|
|
|
| |
Not renderable in OpenGL anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimized Z-test functions assumed that the array of incoming quads
are adjacent, but that's not always true. The fragment shader can cull
intermediate quads, for example.
Now these Z-test functions can cope with non-adjacent quads. A little bit
of performance is probably lost, but it's probably not worth worring about.
This fixes broken glBitmap() Z testing, among other things.
(cherry picked from commit d437d905e6924ebc05ec9efe87e1e2c48d75bc13)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
We need to do this before we emit any state dependent on the current
render buffers.
|
| |
|
|
|
|
|
|
|
| |
Fixes bug 26623. Original patch was submitted by Mathias Frohlich
and modified by Brian.
(cherry picked from commit 7c34c237a2f6732b2c013543523617e375c1f534)
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
The idea is to directly parse the format description in
r300_translate_texformat and return ~0 if the format is unsupported.
|
|
|
|
|
| |
--whole-archive is not portable. Have the drivers reference _eglMain as
a poor man's --whole-archive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This merges the patches from the series "[PATCH 00/14] More
client-side GLX house cleaning" that were posted to the mesa3d-dev
mailing list. See
http://marc.info/?l=mesa3d-dev&m=126582985214612&w=2
Patches 01 through 04 eliminate a bunch of annoying warnings that I
get when building Mesa.
Patch 05 fixes an inconsistency between the implementation of
glXSwapIntervalMESA and the spec. I chose to favor the code over the
spec in this case. This also eliminated a warning.
Patches 06 through 12 clean up the way that context creation is
performed on the client. When support for GLX_SGIX_fbconfig and the
related GLX 1.3 functions was added, I refactored a bunch
nuts-and-bolts of context creation to CreateContext. The refactor was
a good idea, I just didn't do it right.
Patches 13 and 14 update glxgears_fbconfig to use GLX 1.3 interfaces.
|
| |
| |
| |
| |
| |
| | |
Pass either the fbconfig ID or the visual ID, as appropriate, to
CreateContext. Now CreateContext does not derefernce fbconfig or vis
(which no longer exists as a parameter).
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
For the direct rendering case, the DRI createContext function wants an
fbconfig. When glXCreateContext is called, we have to convert the
visual to an fbconfig. This work was done in CreateContext, but it
makes more sense for it to be done in glXCreateContext.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
A long time ago I was a bit over-agressive in refactoring context
creation into a single function. The creation code for
glXImportContextEXT does not belong in CreateContext because it does
not use any GLX protocol. The big if-statement for the import case
routed around almost the entire function anyway.
|
| |
| |
| |
| |
| | |
Passing the screen parameter to CreateContext will simplify a couple
of changes that are coming.
|
| |
| |
| |
| |
| |
| | |
Passing the opcode directly instead of having CreateContext infer it
from the value of fbconfig and the use_glx_1_3 flag will simplify some
changes that are coming.
|
| |
| |
| |
| |
| |
| |
| |
| | |
It appears that, in spite of what the spec says, the interval
parameter to glXSwapIntervalMESA has been an unsigned int since
day-1. This made the 'if (interval < 0)' test useless. The test is
removed and the spec is updated to note that the interval is an
unsigned value.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The wrapper macro GC_IS_DIRECT is used in CreateContext and a couple
other places to eliminate the need for some of the '#ifdef
GLX_DIRECT_RENDERING' madness. There appear to be a *LOT* of places
in glxcmds.c where '#ifdef GLX_DIRECT_RENDERING' is missing.
|
| | |
|