MSVC may not support full C99, but supports more than plain C90. And
-pedantic without -std=c99 generates too many spurious warnings
(specially C++ style comments) to be of any use.
Note that using certain C99 features in the cross-platform parts of Gallium
is still not possible; namely mid-of-scope variable declarations and named
structure initializers will break MSVC builds.
The following construction in util_surface_copy() in
gallium/auxiliary/util/u_rect.c, introduced in commit
d177c9ddda, incorrectly inverts
the Y coordinate in the last parameter to pipe_copy_rect().
/* If do_flip, invert src_y position and pass negative src stride
*/
pipe_copy_rect(dst_map,
&dst->block,
dst->stride,
dst_x, dst_y,
w, h,
src_map,
do_flip ? -(int) src->stride : src->stride,
src_x,
do_flip ? w - src_y : src_y);
The intention is to start at the last Y coordinate line and move
backwards, in the case of a flip; in that case, the correct
calculation is "src_y + h - 1", not "w - src_y".
This fixes a Gallium assertion failure in the conformance tests:
u_rect.c:65:pipe_copy_rect: Assertion `src_y >= 0' failed.
debug_get_bool_option: GALLIUM_ABORT_ON_ASSERT = TRUE
Trace/breakpoint trap
This is a work-around the for the fact that we do fragment shader state
validation before vertex shader validation (see comments in state.c) so in
get_fp_input_mask() we can't rely on ctx->VertexProgram._Current being up to
date yet.
This fixes a glean glsl1 test failure.
Remove the old/initial vbuf allocation in util_create_gen_mipmap().
We were allocating a small vbuf at this point so get_next_slot() didn't have
as large of buffer as it expected. So all but the first set_vertex_data()
was writing out of bounds.
Also added some comments.
The problem we're solving only occured when there was a user-defined
vertex shader but no fragment shader. Check for that case now.
Fixes glean api2 vertex array failure.
Quite a few util modules were maintaining a single vertex buffer over multiple
frames, and potentially reusing it in subsequent frames. Unfortunately that
would force us into syncrhonous rendering as the buffer manager would be
forced to wait for the previous rendering to complete prior to allowing the
map.
This resolves that issue, but requires the state tracker to issue a few new
flush() calls at the end of each frame.
The Minimum Resolvable Depth factor depends on the driver and can't just
be computed from the number of Z buffer bits.
Glean's polygon offset test now passes with softpipe.
Still need to determine the MRD factor for other gallium drivers, if they use
the draw module's polygon offset stage...
