Mesa will do the mapping at _mesa_add_sampler() time. Fixes assertion
failures in debug builds, which might have caught real problems with
multiple samplers linked in a row.
Instead of using a linker-assigned location (since samplers don't
actually take up uniform space, being a link-time choice), use the
sampler's varaible pointer as a hash key.
The new compiler doesn't generate Mesa IR at compile time, and that
compile time code previously wouldn't have reflected the link time
code that actually got used. But do dump the info log of the compile
regardless.
In most cases, we needed to be reparenting the cloned IR to a
different context (for example, to the linked shader instead of the
unlinked shader), or optimization before the reparent would cause
memory usage of the original object to grow and grow.
seems hw can do unaligned accesses and unaligned strides
removes extra conversion when using vbo's
however I needed to switch 3 component byte format to 4 component formats
for tests to pass. Somewhat sililar to GL_SHORT fix done earlier
removes assert and gains +2 piglit especially draw-vertices
The BGNLOOP and ENDLOOP instructions are now being used correctly, which
makes break and continue possible. The deadcode pass has been modified to
handle breaks, and the compiler is more careful about which loops are
unrolled.
When we have instance divisors we don't really know which vertex
elements we'll be fetching ahead of time.
This fixes a bug in instanced drawing which was exposed by the new
draw_vbo() code because of max_index not being ~0 as often as it used
to be. The test for max_index >= DRAW_PIPE_MAX_VERTICES often hid
this problem before.
It's easily reproducible with Compiz with its Resize window mode
set to Normal (which is usually not the default mode).
https://bugs.freedesktop.org/show_bug.cgi?id=28658https://bugs.freedesktop.org/show_bug.cgi?id=29303
This is actually a workaround to prevent Compiz crashes.
Instead, a completely white titlebar might show up during resizing
transparent windows (a rare case).
The underlying cause should be fixed by someone who has more knowledge
about the code. (dri2_drawable_get_buffers should not return NULL)
Acked-By: Jakob Bornecrantz <jakob@vmware.com>
Even though the spec says that the limits should be -64/+63, proprietary
drivers support much larger relative offsets and some applications do
depend on this non-standard behavior.
Also program_parse.tab.c has been regenerated.
This fixes the parser error:
ARB_vp: error: relative address offset too large
See also: https://bugs.freedesktop.org/show_bug.cgi?id=28628
4096 * sizeof(vec4) is the maximum size of the constant buffer on NV50.
It is not supposed to be a definite hardware limit, it is for the parser
not to get in the way and let the underlying driver decide whether it can
run the shader or not.
