The screen wide info such as pitch and cpp are obsoleted by the FBO
changes, so clean up the last few references to those, except for
setting up the legacy screen regions.
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.
This fix ensures it gets the starting location of the clip program
if a clip unit state is same as a unit which is created when metaops
is actived and it doesn't impact metaops because the clip state offset
isn't emitted when metaops is actived.
The WM code had this right, so copy its behavior. This reverts a flipping
of the arguments to SLT in brw_vs_tnl which came in with the GLSL code that
probably occurred to work around the flipped results, and brings the code back
in line with t_vp_build.c.
Wine intentionally tries some out-of-spec programs to test strictness, and
calling ProgramStringNotify on the results of a failed program parse resulted
in crashes in the 965 driver.
Workaround for recursive batchbuffer flushing: If the window is
moved, we can get into a case where we try to flush during a
flush. What happens is that when we try to grab the lock for
the first flush, we detect that the window moved which then
causes another flush (from the intel_draw_buffer() call in
intelUpdatePageFlipping()). To work around this we reset the
batchbuffer tail pointer before trying to get the lock. This
prevent the nested buffer flush, but a better fix would be to
avoid that in the first place.
The conditional in src/mesa/Makefile currently hardcodes the cases where
libOSMesa can be built on libGL. Likewise, the xlib case always includes
libOSMesa in the stand-alone target.
This changes the conditional to a loop over the DRIVER_DIRS variable.
This means that any driver configuration can enable or disable osmesa.
The current "stand-alone" rule is changed so that DRIVER_DIRS=x11 and
DRIVER_DIRS="x11 osmesa" are both respected.
The configure option is changed to --enable-gl-osmesa as this change
allows libOSMesa to be built upon any of the libGL-enabling drivers.
Since each one is only 64b, and kernel allocations are a page anyway, this
lets us reduce buffer allocation by packing many CURBEs into one buffer, for
each batchbuffer submitted. Improves openarena performance by around 10%.
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.
This may allow better concurrency (noop in openarena performance now), but is
also important for the previous commit -- otherwise, we may end up with
BufferData, draw_prims, BufferData and the draw_prims would use the new VBO
data instead of old. This could still occur with user-supplied VBOs and poor
use of MapBuffer without BufferData.
The comment about (vbo)_exec_api.c appeared to be stale, as the VBO code seems
to only use non-named VBOs (not actual VBOs) or freshly-allocated VBO data.
This brings a 2x speedup to openarena, because we can submit nearly-full
batchbuffers instead of many 450-byte ones.
This allows us to avoid re-emitting some state when validate_state happens
multiple times per batchbuffer. Even though we flush batch per primitive
currently, that may still happen already if the primitive changed (this should
probably be fixed as well).
Both drivers have ended up relying on lost_hardware being called after each
batch buffer, so update the name. This removes one of the calls on 965 whic
h was outside of the batchbuffer handling code and just duplicating what had
already happened through batchbuffer handling.
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.
