external_mesa3d/src/gallium/drivers/llvmpipe/lp_setup_tri.c, branch replicant-6.0

llvmpipe: fix lp_rast_plane alignment on 32bit

2016-03-15T18:42:15+00:00

Some rasterization code relies (for sse) on the first and third planes
(but not the second for now) being 128bit aligned, and we didn't get that
on 32bit - I mistakenly thought the 64bit number in the struct would get
the thing aligned to 64bit even on 32bit archs.
Stephane Marchesin really figured this out.

Reviewed-by: Jose Fonseca 

CC:

llvmpipe: add a few const qualifiers

2016-02-19T15:51:51+00:00

Reviewed-by: Roland Scheidegger

llvmpipe: use scissor_planes_needed helper function

2016-02-03T00:25:45+00:00

So it doesn't get out of sync in multiple places.

llvmpipe: drop scissor planes early if the tri is fully inside them

2016-02-02T04:58:19+00:00

If the tri is fully inside a scissor edge (or rather, we just use the
bounding box of the tri for the comparison), then we can drop these
additional scissor "planes" early. We do not even need to allocate
space for them in the tri.

The math actually appears to be slightly iffy due to bounding boxes
being rounded, but it doesn't matter in the end.

Those scissor rects are costly - the 4 planes from the scissor are
already more expensive to calculate than the 3 planes from the tri itself,
and it also prevents us from using the specialized raster code for small
tris.

This helps openarena performance by about 8% or so. Of course, it helps
there that while openarena often enables scissoring (and even moves the
scissor rect around) I have not seen a single tri actually hit the
scissor rect, ever.

v2: drop individual scissor edges, and do it earlier, not even allocating
space for them.
v3: help the compiler a bit with simpler code, suggested by Brian.

Reviewed-by: Brian Paul

llvmpipe: minor cleanup of sse2 for calc_fixed_position

2016-02-02T04:58:19+00:00

Just slightly simpler assembly.

Reviewed-by: Brian Paul

llvmpipe: fix arguments order given to vec_andc

2016-01-17T19:07:27+00:00

This patch fixes a classic "confuse the enemy" bug.

_mm_andnot_si128 (SSE) and vec_andc (VMX) do the same operation, but the
arguments are opposite.

_mm_andnot_si128 performs "r = (~a) & b" while
vec_andc performs "r = a & (~b)"

To make sure this error won't return in another place, I added a wrapper
function, vec_andnot_si128, in u_pwr8.h, which makes the swap inside.

Signed-off-by: Oded Gabbay 
Reviewed-by: Roland Scheidegger

llvmpipe: (trivial) use cast wrapper for m128d to m128 casts

2016-01-13T03:48:41+00:00

some compiler was unhappy.

llvmpipe: scale up bounding box planes to subpixel precision

2016-01-13T02:34:59+00:00

Otherwise some planes we get in rasterization have subpixel precision, others
not. Doesn't matter so far, but will soon. (OpenGL actually supports viewports
with subpixel accuracy, so could even do bounding box calcs with that).

Reviewed-by: Brian Paul 
Reviewed-by: Jose Fonseca

llvmpipe: add sse code for fixed position calculation

2016-01-13T02:34:09+00:00

This is quite a few less instructions, albeit still do the 2 64bit muls
with scalar c code (they'd need way more shuffles, plus fixup for the signed
mul so it totally doesn't seem worth it - x86 can do 32x32->64bit signed
scalar muls natively just fine after all (even on 32bit).

(This still doesn't have a very measurable performance impact in reality,
although profiler seems to say time spent in setup indeed has gone down by
10% or so overall. Maybe good for a 3% or so improvement in openarena.)

Reviewed-by: Brian Paul 
Reviewed-by: Jose Fonseca

llvmpipe: do 64bit plane calculations in the sse path

2016-01-07T23:34:14+00:00

The sse path was pretty much disabled for practical purposes because the
largest allowed fb size was 128x128. So, adapt it for 64bit plane calculations.
This is actually not that difficult, though a problem is that we can't do
a signed 32x32->64bit mul, only unsigned, so need to fix that up. Overall,
the code still looks reasonable, though it's not like changes there in
setup really make much of a difference in the end...

Reviewed-by: Jose Fonseca 
Reviewed-by: Brian Paul