util_fill_rect could not handle formats with more than 32 bits,
since the fill color was a uint32_t value. Fix this by using
a util_color union instead, and also expand the union so it
works with formats which have up to 256 bits (the max of any
format currently defined).
Gallium always puts gl_PointCoord in GENERIC[0] if
point_quad_rasterization is enabled.
This is silly, but for now it makes mesa-demos/glsl/pointcoord work.
Before, we were discarding the compiled vertex program on each
vertex program change.
Now we compile the program as if there were 6 clip planes and
dynamically patch in an "end program" bit at the right place.
Also, nv30 should now work.
the current code reuses the same vbo over and over, however after a flush
we'd stall and wait for mapping on the vbo when we should just fire and forget.
On a gears test this brings me from ~620 to ~750 on my rv530 in swtcl mode.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the same issue as in the previous patch, but here the Blit is not
implemented for separate depth and stencil buffers at all (such
a configuration is not supported in Gallium) and the code incorrectly treated
a D24S8 texture as two separate buffers, making this Blit a no-op.
Signed-off-by: Brian Paul <brianp@vmware.com>
This should be mostly a noop, except that a plain dereference of a
variable that is not part of a constant expression could now get
"constant folded". I expect that for all current backends this will
be either a noop, or possibly a win when it provokes more
ir_algebraic. It'll also ensure that when new features are added,
tree walking will work normally. Before this, constants weren't
getting folded inside of loops.
I had used pkg-config from the Makefile because I didn't want to screw
around with the non-autoconf build, but that doesn't work because the
PKG_CONFIG_PATH or TALLOC_LIBS/TALLOC_CFLAGS that people set at
configure time needs to be respected and may not be present at build
time.
Bug #29585
Now we lie less when claiming OpenGL 2 support.
Also, first piglit result group is now all green, except for
fdo25614-genmipmap, which seems mesa/st's fault.
Include draw_context.h for draw_*_vertex_shader symbols.
Fixes the following GCC warning.
nvfx_vertprog.c: In function 'nvfx_vp_state_create':
nvfx_vertprog.c:1276: warning: implicit declaration of function 'draw_create_vertex_shader'
nvfx_vertprog.c:1276: warning: assignment makes pointer from integer without a cast
nvfx_vertprog.c: In function 'nvfx_vp_state_delete':
nvfx_vertprog.c:1298: warning: implicit declaration of function 'draw_delete_vertex_shader'
Before using depth buffer as texture, it needs to be decompressed
(tile pattern of db are different from one used for colorbuffer
like texture)
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Introduce a new configuration option XMESA_STRICT_INVALIDATE to switch
between swapbuffers-based and glViewport-based buffer invalidation.
Default strict invalidate to false, ie glViewport-based invalidation,
aka ST_MANAGER_BROKEN_INVALIDATE.
This means we will not call XGetGeometry after every swapbuffers,
which allows swapbuffers to remain asynchronous. For apps running at
100fps with synchronous swapping, a 10% boost is typical. For gears,
I see closer to 20% speedup.
Note that the work of copying data on swapbuffers doesn't disappear -
this change just allows the X server to execute the PutImage
asynchronously without us effectively blocked until its completion.
This applies even to llvmpipe's threaded rasterization as the
swapbuffers operation was a large part of the serial component of an
llvmpipe frame.
The downside of this is correctness - applications which don't call
glViewport on window resizes will get incorrect rendering, unless
XMESA_STRICT_INVALIDATE is set.
The ultimate solution would be to have per-frame but asynchronous
invalidation. Xcb almost looks as if it could provide this, but the
API doesn't seem to quite be there.
This version should hopefully be much clearer and thus less likely
to be subtly broken.
Also fixes point sprites on nv40 and possibly some other bugs too.
My merge of Zhenyu's patch on top of my previous patches broke it by
my code expecting simd16 single write and Zhenyu's simd8 path being
disabled by mine. Merge the two for success.
The docs claim two conflicting things: One, that a scalar source is
supported. Two, source hstride must be 1 and width must be exec size.
So splat a constant argument out into a full reg to operate on, since
violating the second set of constraints is clearly failing.
The alternative here might be to do a 1-wide exec on a constant
argument for math1. It would probably save cycles too. But I'll
leave that for the glsl2-965 branch.
Fixes glsl-algebraic-div-one-2.shader_test.
