| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Conflicts:
src/mesa/drivers/dri/intel/intel_screen.c
src/mesa/drivers/dri/intel/intel_swapbuffers.c
src/mesa/drivers/dri/r300/r300_emit.c
src/mesa/drivers/dri/r300/r300_ioctl.c
src/mesa/drivers/dri/r300/r300_tex.c
src/mesa/drivers/dri/r300/r300_texstate.c
|
|
|
|
|
|
Shaves 400 bytes or so from i915_dri.so.
|
|
|
|
Before, if we just called glXMakeCurrent() and didn't render anything we'd
still trigger a flushFrontBuffer() call.
Now only set the intel->front_buffer_dirty field at state validation time
just before we draw something.
NOTE: additional calls to intel_check_front_buffer_rendering() might be
needed if I missed some rendering paths.
|
|
|
|
|
|
Since the TNL is all done in software anyway, it should be the same to
the user who's probably using ARB_vertex_program otherwise, but gives them
a nicer programming environment.
|
|
|
|
|
|
The i965 hardware cannot do GL_CLAMP behavior on textures; an earlier
commit forced a software fallback if strict conformance was required
(i.e. the INTEL_STRICT_CONFORMANCE environment variable was set) and
2D textures were used, but it was somewhat flawed - it could trigger
the software fallback even if 2D textures weren't enabled, as long
as one texture unit was enabled.
This fixes that, and adds software fallback for GL_CLAMP behavior with
1D and 3D textures.
It also adds support for a particular setting of the INTEL_STRICT_CONFORMANCE
environment variable, which forces software fallbacks to be taken *all*
the time. This is helpful with debugging. The value is:
export INTEL_STRICT_CONFORMANCE=2
|
|
Oops.
|
|
Intel docs state that only 830/845 have VBOs, 855/865 don't. So
lets just not use them on i8xx at all.
This restores the old pre-vbo code and uses it on all 8xx hw.
|
|
According to Keith the docs have these offsets the other way around
|
|
|
|
Makefile.template
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
To do this, I had to clean up some of 965 state upload stuff. We may end
up over-emitting state in the aperture overflow case, but that should be rare,
and I'd rather have the simplification of state management.
|
|
This lets GEM use pwrite, for an additional 4% or so speedup.
|
|
|
|
|
|
Avoids spamming compilation output with tons of warnings about
use of possibly uninitialized variables.
|
|
The fix for pageflipping with cliprects ended up causing a batch flush at
an inopportune time, which is fixed by moving it up.
Additionally, the recovery code for handling batch wraps at bad times is
replaced by just checking for the space up front, and using a no_batch_wrap
assert like on 965 to make sure that we weren't wrong about how much space that
was.
|
|
The previous change gave us only two modes, one which looped over the batch
per cliprect (3d drawing) and one that didn't (state updeast).
However, we really want 4:
- Batch doesn't care about cliprects (state updates)
- Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing)
- Batch needs to be executed just once (region fills, copies, etc.)
- Batch already includes cliprect handling, and must be flushed by unlock time
(copybuffers, clears).
All callers should now be fixed to use one of these states for any batchbuffer
emits. Thanks to Keith Whitwell for pointing out the failure.
|
|
In particular, batch buffers are no longer flushed when switching from
CLIPRECTS to NO_CLIPRECTS or vice versa, and 965 just uses DRM cliprect
handling for primitives instead of trying to sneak in its own to avoid the
DRM stuff. The disadvantage is that we will re-execute state updates per
cliprect, but the advantage is that we will be able to accumulate larger
batch buffers, which were proving to be a major overhead.
|
|
|
|
|
|
|
|
This could lead to incorrect rendering or even lockups.
|
|
The lock coverage and checks for cliprects were unneeded since the batchbuffer
will have INTEL_BATCH_CLIPRECTS anyway. It appeared to be a leftover from
intelClearWithBlit.
This makes the locking requirements of i915 meta_draw_quad match i965
meta_draw_quad.
|
|
|
|
|
|
|
|
|
|
"gl_" to match other structs.
|
|
|
|
Instructions, InputsRead, OutputsWritten, and Parameters.
Also, added debug functions: _mesa_print_instruction(),
_mesa_print_program_parameters() and revamp _mesa_print_program().
|
|
|
|
|
|
|
|
|
|
|
|
|
