If nvfx_framebuffer prepare and validate were called successively with
fb->zsbuf not NULL and then NULL, nvfx->hw_zeta would contain garbage and
this would cause failures in nvfx_framebuffer_relocate/OUT_RELOC(hw_zeta).
This was triggered by piglit/texwrap 2D GL_DEPTH_COMPONENT24 and caused
first a 'write to user buffer!!' error in libdrm and then worse things.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
7e1bf94631 changed
PIPE_CAP_MAX_RENDER_TARGETS to 1 on nv30.
Signed-off-by: Xavier Chantry <chantry.xavier@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Currently, the standalone compiler tries to do function inlining before
linking shaders (including linking against the built-in functions).
This resulted in the built-in function _prototypes_ being inlined rather
than the actual function definition.
This is only known to fix a bug in the standalone compiler; most
programs should be unaffected. Still, it seems like a good idea.
NOTE: This is a candidate for the 7.9 branch.
Fixes this GCC warning with linux-x86 build.
radeon_pair_regalloc.c: In function ‘compute_live_intervals’:
radeon_pair_regalloc.c:222: warning: ISO C90 forbids mixed declarations and code
Fixes this GCC warning with linux-x86 build.
radeon_pair_regalloc.c: In function ‘compute_live_intervals’:
radeon_pair_regalloc.c:221: warning: ISO C90 forbids mixed declarations and code
The alpha mask is addressed with unnormalized coordinates in the
fragment shader. It should have the same orientation as the surface
does.
This fixes "mask" OpenVG demo.
Previously, the get table listed all three as having custom locations,
yet find_custom_value did not have cases to handle them.
MAX_VARYING_VECTORS does not need a custom location since MaxVaryings is
already stored as float[4] (or vec4). MaxUniformComponents is stored as
the number of floats, however, so a custom implementation that divides
by 4 is necessary.
Fixes bugs.freedesktop.org #31495.
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>
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.
(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>
