| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Add a new flag mvp_with_dp4 in the context, and use that to switch
both ffvertex.c and programopt.c vertex transformation code to
either DP4 or MUL/MAD implementations.
|
|
|
|
|
|
|
|
| |
This is a quick fix for z fighting in quake4 caused by the mismatch
between vertex transformation here and in the position_invarient code.
Full fix would be to make this driver-tunable and adjust both
position_invarient and ffvertex_prog.c code to respect driver
preferences.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Add a dummy function which exists only so that tgsi_text_translate()
doesn't get magic-ed out of the libtgsi.a archive by the build system.
Don't remove unless you know this has been fixed - check on
mingw/scons builds as well.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since GL_READ_BUFFER is historically part of the gl_pixel_attrib group
it made sense to signal changes with _NEW_PIXEL. But now with FBOs it's
also part of the framebuffer state.
Now _NEW_PIXEL strictly indicates pixels transfer state changes.
This change avoids framebuffer state validation when any random bit of
pixel-transfer state is set.
DRI drivers updated too: don't check _NEW_COLOR when updating framebuffer
state. I think that was just copied from the Xlib driver because we care
about dither enable/disable state there.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Previously we created the pipe_surface during framebuffer validation.
But if we did a glCopyTex[Sub]Image() before anything else we wouldn't yet
have the surface. This fixes that.
|
| |
| |
| |
| |
| | |
We need to make sure the framebuffer state is up to date to make sure we
read pixels from the right buffer when doing a texture image copy.
|
| |
| |
| |
| | |
Furthermore, return pointer(s) to the front color buffer(s).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The front/back buffer pointers are truly swapped (when there is an actual
front buffer).
This fixes some issues seen with apps/tests that draw to both the front
and back color buffers. The true swap allows us to avoid the (potentially)
slow surface_copy() call in update_framebuffer_state() and is cleaner
overall.
|
| |
| |
| |
| |
| |
| | |
When we create a new front color buffer (user called glDrawBuffer(GL_FRONT))
initialize it to the contents of the back buffer. Any previous call to
SwapBuffers() would have done that in effect, so make it reality.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Indicates whether there's defined image contents, or garbage/don't care.
This is set when we draw into a renderbuffer and cleared when we resize/
reallocate a renderbuffer or do a buffer swap (back buffer becomes undefined).
We use this to determine whether the front color buffer has been drawn to,
and whether to display its contents upon glFlush/Finish(), when the new
st_swapbuffers() function is used.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When building mangled Mesa on Darwin, the exported symbols are
named `_mgluWhatever' instead of simply `_gluWhatever'. When
using a list of exported symbols via the system ld's
`-exported_symbols_list' command line option (as done by mklib),
this resulted in error messages about exporting symbols which do
not exist.
Fortunately the file format accepts simple wildcards. This throws
a wildcard so that the symbol list will match both the mangled and
non-mangled names, preventing the warning and actually exporting
the correct symbols in one shot.
|
| | |
|
| |
| |
| |
| |
| | |
The pointers to the front/back renderbuffers are exchanged.
This new function isn't actually used yet...
|
| | |
|
| |
| |
| |
| |
| | |
dlopen manpage mandates that either RTLD_LAZY or RTLD_NOW flags must be
passed. Not doing so was causing a NULL return on debian unstable x86-64.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For non-stereo visuals, which is all we support, we treat
GL_FRONT_LEFT as GL_FRONT. However, they are technically different,
and they have different enum values. Test for either one to determine
if we're in front-buffer rendering mode.
This fix was suggested by Pierre Willenbrock.
Signed-off-by: Ian Romanick <[email protected]>
|
| |
| |
| |
| |
| | |
Before we always created the front color buffer, even if was never used.
This can save some memory.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/mesa/drivers/dri/i965/brw_curbe.c
src/mesa/drivers/dri/i965/brw_vs_emit.c
src/mesa/drivers/dri/i965/brw_wm_glsl.c
|
| | |
| | |
| | |
| | |
| | | |
This function will check an instruction to see if there's data dependencies
between the dst and src registers if executed in an SOA manner.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Make the use_const_buffer field per-program and only call the code which
updates the constant buffer's data if the flag is set.
This should undo the perf regression from 20f3497e4b6756e330f7b3f54e8acaa1d6c92052
(cherry picked from master, commit dc9705d12d162ba6d087eb762e315de9f97bc456)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use a bitvector of used/free flags.
If we run out of temps, examine the live intervals of the temp regs in
the program and free those which are no longer alive.
Also, enable the new WM const buffer code.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Use _NEW_PROGRAM_CONSTANTS when changing constant/uniform buffer values.
Binding a new program/shader sets both _NEW_PROGRAM and _NEW_PROGRAM_CONSTANTS.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the VS constants can now be handled in two different ways:
1. If there's room in the GRF, put constants there. They're preloaded from
the CURBE prior to VS execution. This is the historical approach. The
problem is the GRF may not have room for all the shader's constants and
temps and misc registers. Hence...
2. Use a separate constant buffer which is read from using a READ message.
This allows a very large number of constants and frees up GRF regs for
shader temporaries. This is the new approach. May be a little slower
than 1.
1 vs. 2 is chosen according to how many constants and temps the shader needs.
|
| | | |
|
| | |
| | |
| | |
| | | |
These types are only found in the new surface state cache now.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The new, second cache will only be used for surface-related items.
Since we can create many surfaces the original, single cache could get
filled quickly. When we cleared it, we had to regenerate shaders, etc.
With two caches, we can avoid doing that.
|