It looks like we were reading a fractional value, multiplying by an
enormous negative value, then stuffing that value into a bitfield
assuming it was already clamped. This becomes relevant for GL_ALPHA
or R/RG FBOs.
This avoids many pipeline stalls in cairo-gl.
[ # ] backend test min(s) median(s) stddev. count
Before:
[ 0] gl firefox-talos-gfx 36.799 36.851 2.34% 3/3
[ 0] gl firefox-talos-svg 33.429 35.360 3.46% 3/3
After:
[ 0] gl firefox-talos-gfx 35.895 36.250 0.48% 3/3
[ 0] gl firefox-talos-svg 26.669 29.888 5.34% 3/3
This doesn't avoid all the pipeline stalls because the kernel reports
!busy for buffers on the flushing list. That should be fixed in .36.
In exchange we end up with an extra memcpy, but that seems better than
calloc/free. Each buffer is 4k maximum, and on the i965-streaming
branch this allocation was showing up as the top entry in
brw_validate_state profiling for cairo-gl.
I was told this wouldn't help to fix the FDO bug #28443, but still,
it's a harmless last resort.
Also, linear textures safely fallback to an unpipelined transfer here.
lots and lots of fixes for geometry shaders. in particular now we work when the gs
emits a different primitive than the one the pipeline was started with and also
we work when gs emits more vertices than would fit in the original buffer.
If no customizer is present, 3D will be enabled by default.
Otherwise the option will default to the customizer value.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
There were entries to this function (most imporantly, prepare_render
-> update_renderbuffers) that wouldn't have had NEW_BUFFERS set, but
brw_wm_surface_state (the i965 state tracking the drawing regions)
expected this to change.
interface wise we have everything needed by d3d10 and gl transform feedback.
the draw module misses implementation of some corner cases (e.g. when stream
output wants different number of components per output than normal rendering
paths)
