| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
INLINE is commonly used in third-party headers.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/gallium/auxiliary/util/Makefile
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Fixed size hash table. Collisions are handled by simply destroying the
previous entry.
It hasn't received much testing yet.
|
| | |
|
| | |
|
| |
| |
| |
| | |
This fixes two-sided lighting for vertex shaders.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following construction in util_surface_copy() in
gallium/auxiliary/util/u_rect.c, introduced in commit
d177c9ddda2c452cf7d6696d89cf4458ef986f98, 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
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
get_fp_input_mask()
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.
|
| | |
|
| |
| |
| |
| | |
This reverts commit cdaaf8e107010624bed4abdf9553c0ef63c8b708.
|
| |
| |
| |
| |
| | |
We were accidentally using the fixed-function logic when a vertex shader was
being used.
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously 3D textures were mipmapped using multiple passed through
the 2D mipmap generation code. This had 3 disadvantages. First, the
extra passes were slow. Second, this required the allocation of a
temporary buffer to hold intermediate data. Third, and most
important, the extra passes caused loss of additional bits due to
integer division / bit-shifting.
With this change, our mipmapgen conformance test passes for
non-compressed texture formats.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
The partial precision mode doesn't have quite enough bits of precision
to pass conformance tests.
|
| | |
| | |
| | |
| | |
| | | |
It looks like the LOG2 macro only has 8 or 9 bits of precission, but
the ARB_vertex_program spec says "accurate to at least 10 bits".
|
| | |
| | |
| | |
| | | |
Bug #19139.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
glCopyTexSubImage already gets the (correct) clipping for us, so it doesn't
need the path. While moving the clipping out, replace the code with the mesa
path to do the same job.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Note how if:
x + width == xmax + 0: width -= 0
x + width == xmax + 1: width -= 0
x + width == xmax + 2: width -= 1
So, the function was clipping to [xmin, xmax+1), not [xmin, xmax) like it was
supposed to. Same for ymax.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
The subsequent if/else cases always call _mesa_reference_fragprog() anyway.
|
| | | |
|
| | |
| | |
| | |
| | | |
Unfinished, a big no-op for now.
|
| | |
| | |
| | |
| | | |
This is copied from Ian's commit a330933bb75c38148668637cd22b90d75d39506f
|
| | | |
|