The driver (or preferably the hardware) should handle out of bounds
indices.
If there are problems then it's better to detect those in the debug
builds.
Do this by extending the nearest range to cover the new range.
This fixes an access fault in Call of Duty which was doing many disjoint
glBufferSubData calls.
So if we don't actually emit an atom to the hw because we don't
need it in the current state (e.g. lighting related atoms when
lighting is off) then don't mark it as clean, because when
lighting gets switched on we won't emit it at all.
This fixes funky gears colors.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If GL_EXT_framebuffer_blit was not supported _mesa_DeleteFramebuffersEXT
would raise an error when deleting the currently bound framebuffer. This
because it tried to bind the default DRAW- and READ_FRAMEBUFFER separately.
This patch binds the default FRAMEBUFFER instead in that case.
Encountered in the fbo/fbo-copyteximage piglit test on R600.
Patch cleaned up a bit by Brian Paul.
Eric added some new code to check if offset < obj_size before computing
_MaxElement but my original code was still present afterward and it
clobbered the _MaxElement value.
Not sure if this came from a bad merge or what.
Based on a patch by Xavier Chantry <chantry.xavier@gmail.com>:
If x+width or y+height is negative, then maxx or maxy will get a bogus value
when converting that to unsigned. Fix this by setting 0 as minimal value.
This was also triggered by teeworlds, but only with some combination of
resolution and map section. For example upper part of dm2 at 1280x1024.
commit 53174afeeb introduced a portability change that converted GLint x,y
to GLuint. That breaks when x and y are negative, which seems to be allowed,
and which at least one game uses : teeworlds.
Rather than simply reverting the change, it seems possible to convert the
16bit unsigned to GLint so that comparisons are made between signed integers
instead. This hopefully does not break anything while keeping MSVC happy.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Brian Paul <brianp@vmware.com>
This is faster and ensures that NaN floats get stored properly.
Before, NaN values (which might be used with UP2H, UP2US, UP4B and
UP4UB) weren't getting stored properly with gcc -O3.
This is the second part of the fix for the piglit fp-unpack-01 failure
(bug 25973).
The UP2H, UP2US, UP4B and UP4UB instructions interpret the float
registers as integers. With gcc -O3 some bits were getting mixed up
somewhere. This is part of the fix for the piglit fp-unpack-01 test
failure (bug 25973).
The previous memory leak fix didn't always work properly.
Now check the xm_buffer::smh field (now documented!) to
see if the buffer points to shared memory.
Depending on first/last provoking vertex either the first or last
element/index may have the extra DRAW_PIPE_x flags. Mask off those
bits for all vertex elements to be safe (esp. for the quad case).
This may be overly cautious, but it's a cheap operation.
Fixes a segfault caused by large/bogus vertex indexes otherwise.
