we piggy back flags in the top four bits of the element indices, so if
the maximum index stored in any of the elements is greater than
sizeof(ushort) - sizeof(flags we piggy back) then we overflow. fix it by
simply falling back to the slow path if we notice the overflow.
The piglit vp-address-01 test uses negative address-relative
offsets. In this test we're indexing into PROGRAM_STATE_VAR
which, in turn, contains references to ENV vars.
We previously fixed this issue for PROGRAM_CONSTANT.
piglit/vp-address-01 (the version from Feb 5) passes now.
Without this patch, the two symbols get an underscore prepended
and an "@4" appended when compiling with VC8.
Signed-off-by: Brian Paul <brianp@vmware.com>
PXOR user in code were causing the lowest SP float register to have NaN
values which made all math operations in that slot fail. Correct istruction
to clear float registers is XORPS which handles single precission floats
correctly.
Fixes progs/tests/fog in swrast SSE mode.
Now the correct commit instead of 9d9c1f17dc which is not even close
of correct fix for the bug.
Store XPD results in temporaries before writing to the dest register.
This issue has already been fixed in Mesa/master for XPD (and all
other instructions?).
Fixes progs/demos/bump.c when using TGSI interpreter (GALLIUM_NOSSE=1).
A new glean/glsl1 test has been added to test this case.
Texture derivatives are potentially undefined inside dynamic branches,
so hardwire lod zero in this case. Treating all if/endif and loop
constructs as dynamic branches.
The fogcoord calue was not pushed to GPU because of implicit float to int conversion.
Fix is to use float pointer to buffer object so no conversion is done in assigment.
This fixes a bug reported by Christoph Bumiller on mesa3d-dev.
When a texture is first created as RGBA, then re-defined with
glTexImage(internalFormat=GL_DEPTH_COMPONENT) we failed to deallocate
the original texture. When this texture was bound as a FBO surface,
the depth/Z surface format was RGBA instead of Z. Depending on the
driver this led to a failed assertion or FBO validation failure.
This patch does three things:
1. Remove ancient code that mysteriously tested if we were replacing
the smallest mipmap level and tested if the texture was not a cube map
texture. I can't see any reason for those tests.
2. Move the width=height=depth=0 test to after the code which frees
texture data. Calling glTexImage with width=height=depth=0 and data=NULL
is a way to free a single mipmap level.
3. Update the code comments.
There are no apparent conform, glean or piglit regressions from this change.
Before, _mesa_find_free_register() would scan the given shader to
find a free/unused register of the given type. But subsequent calls
would return the same register again. This caused a failure in the
_mesa_remove_output_reads() function which sometimes needs several
free temps.
Now use a new function which build a vector of 'used' flags and another
function which searches that vector for an unused register starting at
a position that's incremented for each call.
Fixes fd.o bug 26317. Note that a regression test for this has been
added to the glean/glsl1 test.
Lets see if this is not too pedantic. Obj pointers are never exposed to
GL apps so it should be possible to get this right.
Furthermore apps with GL widgets and test suits create and destroy many
contexts and objects, so bad reference counting is not really an option.
Always use _mesa_reference_buffer_object, and never call
ctx->Driver.DeleteBuffer() directly to prevent dangling pointers to the
null buffer object.
This fixes crash/assertions in sharedtex_mt and Autodesk Mudbox.
Commit 2708ddfb06 caused a few regressions.
We need to check/validate state after calling bind_arrays() because
it might set the _NEW_ARRAYS flag if the varying VP inputs change.
The symptom of this problem was some attribute arrays being ignored
(or interpreted as constant-valued) in glDrawRangeElements or
glMultiDrawElements.
A follow-on patch will add some additional asserts to try to catch
this kind of thing in the future.
...rather than checking/validating before all the calls to
_mesa_valid_to_render() and valid_to_render().
The next patch will actually fix some bugs...
Not since 6094e79f4e.
Drivers now need to flush draw module explicitely (which explains why
all those previous commits adding draw_flushes calls were necessary).
This is a good thing, but it's tricky to get this right in face of user buffers
(it's not even clear who has the responsibility to flush when a user buffer
is seen -- statetracker or pipe driver), so just force flush (temporarily)
since it's not a bottleneck now.
That is:
- check for no op
- update/flush draw module
- update bound state and mark it as dirty
In particular flushing the draw module is important since it may contain
unflushed primitives which would otherwise be draw with wrong state.
