| Age | Commit message (Collapse) | Author |
|---|
|
This is described in the link in the comment, and is the same technique that
r300 uses.
|
|
The Taylor series notably fails at producing sin(pi) == 0, which leads to
discontinuity every 2*pi. The quadratic gets us sin(pi) == 0 behavior, at the
expense of going from 2.4% THD with working Taylor series to 3.8% THD (easily
seen on comparative graphs of the two). However, our previous implementation
was producing sin(pi) < -1 and worse, so any reasonable approximation is an
improvement. This also fixes the repeating behavior, where the previous
implementation would repeat sin(x) for x>pi as sin(x % pi) and the opposite
for x < -pi.
|
|
|
|
The failure mode that was a available was:
reloc 1 -> target_buf
exec: PRESUMED_OFFSET wrong, buffer migrates, r1 entry updated.
reloc 2 -> target_buf
exec: suppose buffer migrates again. PRESUMED_OFFSET wrong. r2 entry updated.
reloc 1 -> target_buf
exec: suppose buffer doesn't migrate. PRESUMED_OFFSET right. no relocations
performed. r1 has stale pointer at original location.
Failures were reported with OGLconform's VBO test and SPECviewperf90, though
I haven't confirmed that this fixes it.
|
|
|
|
In addition to potentially binding when it was about to be mapped anyway,
failure to use CACHED_MAPPED means eating a full wbinvd on validate. Thanks to
airlied for catching this.
|
|
This helps us avoid a bunch of mess with gl_client_arrays that we filled
with unused data and confused readers.
|
|
|
|
|
|
|
|
If compiled with optimization, it shouldn't appear at all, and helps me for
now.
|
|
|
|
|
|
|
|
isn't created at all for 965
|
|
|
|
This reverts commit e2cb905bc6e23eaafaeeb2abdc9480e70959ee3f.
It was a reversion of an optimization hidden as otherwise.
pre_target_buf_handle was always NULL, so the optimization was never enabled,
rather than fixing the important optimization (resulting in 25-50% performance
loss).
|
|
|
|
|
|
|
|
this fix bad texture issue in some games(UT and quake).
|
|
|
|
|
|
buffer is used for a relocatee in the former relocation process
then another target buffer is used for this relocatee at the same
offset in the current relocation process.
|
|
bug 14289
|
|
|
|
The rs690 has an rs4xx style vertex-shader less 3D engine. It uses the new
r500 output engine though. It also needs a new drm with rs690 support,
which is just getting cleaned up.
|
|
|
|
avoid some issues such that 1 + (-2) gets a big
positive value.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
This was around 3% improvement in OA.
|
|
Around 10% of a CPU was being wasted to create the linked list which we
threw out immediately after passing it to the kernel.
|
|
|
|
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.
|
|
|
|
C has no order of evaluation restrictions on function arguments, so we
attempted to realloc from new-size to new-size.
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Good for a 10-15% improvement to OA.
|
