Age | Commit message (Collapse) | Author |
|
This fixes incorrect behaviour when the stencil clear value exceeds
the size of the stencil buffer, for example, when set with:
glClearStencil (~1); /* Set a bit pattern of 111...11111110 */
glClear (GL_STENCIL_BUFFER_BIT);
The clear value needs to be masked by the value 2^m - 1, where m is the
number of bits in the stencil buffer. Previously, we passed the value
masked with 0x7fffffff to _mesa_StencilFuncSeparate which then clamps,
NOT masks the value to the range 0 to 2^m - 1.
The result would be clearing the stencil buffer to 0xff, rather than 0xfe.
Signed-off-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
This was really just for testing purposes.
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=31894
|
|
Make sure regions are properly updated and that the colorkey painting is
flushed before we update the HW overlay.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
This is needed to properly sync with host side rendering. For example,
make sure we flush colorkey painting before updating the overlay.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
|
|
When a context was made current to another surface, the old code did
this
dri2_dpy->core->bindContext(cctx, ddraw, rdraw);
dri2_dpy->core->unbindContext(old_cctx);
and there will be no current context due to the second line.
unbindContext should be called only when bindContext is not. This fixes
a regression since d19afc57. Thanks to Neil Roberts for noticing the
issue and creating a test case.
|
|
Fixes bugzilla #31832
NOTE: This is a candidate for the 7.9 branch.
|
|
|
|
Upon link error, exit translation loop, free program instructions.
Check for null pointers in calling code.
|
|
|
|
|
|
|
|
Plus remove unused parameter.
|
|
|
|
|
|
Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=31841
|
|
Cuts the extra CMP instruction that used to precede SEL.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=31193
NOTE: This is a candidate for the 7.9 branch.
|
|
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
|
|
|
|
Pending commands to the previous context aren't flushed since commit b4bb668
Reported-by: Oleksiy Krivoshey <oleksiyk@gmail.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
(Marek: added the initializion of "vec" in the default statement)
NOTE: This is a candidate for the 7.9 branch.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
|
|
Are these functions actually used anywhere?
|
|
Add explicit EVENT_TYPE field
|
|
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
This fixes piglit/glsl-vs-main-return and glsl-fs-main-return for the drivers
which don't support RET (i915g, r300g, r600g, svga).
ir_to_mesa does not currently generate subroutines, but it's a matter of time
till it's added. It would then break all the drivers which don't implement
them, so this CAP makes sense.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
|
|
|
|
This fixes fdo bug 31810.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
In addition, the rename_reg pass has been rewritten to use
rc_get_readers().
|
|
Previously, presubtract operations where only being used by instructions
with less than three source source registers.
|
|
|
|
|
|
|
|
|
|
When the result of the alpha instruction is being replicated to the RGB
destination register, we do not need to use alpha's destination register.
This fixes an invalid "Too many hardware temporaries used" error in
the case where a transcendent operation writes to a temporary register
greater than max_temp_regs.
NOTE: This is a candidate for the 7.9 branch.
|
|
This fixes an invalid "Too many hardware temporaries used" error in the
case where a source reads from a temporary register with an index greater
than max_temp_regs and then the source is marked as unused before the
register allocation pass.
NOTE: This is a candidate for the 7.9 branch.
|
|
Reads of registers that where not written to within the same block were
not being tracked. So in a situations like this:
0: IF
1: ADD t0, t1, t2
2: MOV t2, t1
Instruction 2 didn't know that instruction 1 read from t2, so
in some cases instruction 2 was being scheduled before instruction 1.
NOTE: This is a candidate for the 7.9 branch.
|