Invalid shaders containing the character % at an unexpected location
would cause Bison to call yyerror with a message of:
syntax error, unexpected '%'
Bison expects yyerror() to take a string, while _mesa_glsl_error() is a
printf-style function. This hit the classic printf string escape issue:
_mesa_glsl_error(loc, state, "unexpected '%'"); // invalid!
_mesa_glsl_error(loc, state, "%s", "unexpected '%'"); // correct.
This caused assertion failures after ralloc_asprintf_append called
vsnprintf to determine the length of the text that would be printed:
vsnprintf would see the invalid format and return -1, an invalid length.
The solution is to define a proper yyerror() wrapper function that calls
_mesa_glsl_error with the "%s". Since we compile with -p "_mesa_glsl",
yyerror is defined as:
#define yyerror _mesa_glsl_error
So we have to #undef yyerror in order to be able to declare it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43564
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Paul Berry <stereotype441@gmail.com>
The versions in the xserver and in libGL have diverged enough that the
xserver doesn't want these.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glext.h doesn't have GL_MIN_PROGRAM_TEXEL_OFFSET_EXT or
GL_MAX_PROGRAM_TEXEL_OFFSET_EXT. Using them in the XML causes code to
be generated for the xserver that won't compile. Use the names that
exist instead.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
That file was removed from the xserver with commit:
commit a80780a7638f847c3be20e5e0c7fe85e83d9bdd1
Author: Adam Jackson <ajax@redhat.com>
Date: Wed Nov 17 09:03:06 2010 -0500
glx: Remove swap barrier and hyperpipe support
Never implemented in any open source driver. The implementation
assumed explicit DDX driver knowledge of how the client-side driver
worked, since at the time the server's GL renderer was not a DRI driver.
But now, it is, so any implementation of these should be done with
additional DRI driver API, like the swap control extension.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is only temporary until a better solution is available.
v2: print warnings and add gallium CAPs
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Since gl_framebuffer::_DepthBuffer and _StencilBuffer are only used
by swrast, do the validation of those fields in swrast too.
The main/depthstencil.[ch] code is no longer used and will be removed
next.
Reviewed-by: Eric Anholt <eric@anholt.net>
These files are copies of main/depthstencil.[ch] with s/mesa/swrast/.
The main/depthstencil.[ch] will go away soon.
Reviewed-by: Eric Anholt <eric@anholt.net>
These functions update the gl_framebuffer::_DepthBuffer and _StencilBuffer
fields, possibly creating renderbuffer wrappers that make a shared
depth+stencil accessible as depth-only or stencil only.
This stuff is only used by swrast now and will be moved there next.
Reviewed-by: Eric Anholt <eric@anholt.net>
We're just looking at the depth/stencil renderbuffers to do error
checking. We don't need to look at the depth/stencil wrappers to do
that. Also, remove pointless readRb = depthRb = NULL assignments.
Reviewed-by: Eric Anholt <eric@anholt.net>
We never want to use the depth/stencil buffer wrappers so always just
use the attachment renderbuffers. This is a step toward removing the
_DepthBuffer, _StencilBuffer fields.
Reviewed-by: Eric Anholt <eric@anholt.net>
GLfloat doesn't have enough precision to exactly represent 0xffffff
and 0xffffffff. (and a reciprocal of those, if I am not mistaken)
If -ffast-math is enabled, using GLfloat causes assertion failures in:
- fbo-blit-d24s8
- fbo-depth-sample-compare
- fbo-readpixels-depth-formats
- glean/depthStencil
For example:
fbo-depth-sample-compare: main/format_unpack.c:1769:
unpack_float_z_Z24_X8: Assertion `dst[i] <= 1.0F' failed.
Reviewed-by: Brian Paul <brianp@vmware.com>
fixes the following build error since
c83fb4d45f:
/usr/include/strings.h:46:13: error: expected declaration specifiers or
‘...’ before numeric constant
/usr/include/strings.h:46:13: error: conflicting types for ‘memset’
In file included from
../../../../src/gallium/winsys/g3dvl/xlib/xsp_winsys.c:34:0:
../../../../src/gallium/auxiliary/util/u_inlines.h: In function
‘pipe_buffer_create’:
../../../../src/gallium/auxiliary/util/u_inlines.h:189:4: error: too
many arguments to function ‘memset’
/usr/include/strings.h:46:13: note: declared here
bzero is defined in X11 as: #define bzero(b,len) memset(b,0,len)
including strings.h after the X11 header results in preprocessor
replacing 'bzero' in strings.h and generating unbuildable code.
Signed-off-by: Tobias Droste <tdroste@gmx.de>
This fixes the segfault, and seems to put this closer to where other
properties are being set. Hopefully it still conforms.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This just adds the correct checks and asserts in the right places. This doesn't
fix all the tests that I've sent to piglit, need to add int paths to go alongside the uint paths that don't go via float to fix it up properly.
I'm not sure how much of that could be templated/shared will have a look
once I write it the long way.
Reviewed-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It sets the wrong values (GL_XXX_LEFT instead of GL_XXX), and no other
Mesa driver does this, given that Mesa sets the right draw/read buffers
provided the Mesa visual has the doublebuffer flag filled correctly
which is the case.
Reviewed-by: Brian Paul <brianp@vmware.com>
This avoids forming invalid pointers needlessly, which even if
never dereferenced is undefined behavior. It also makes
_mesa_validate_pbo_access() more comprehensible.
Reviewed-by: Brian Paul <brianp@vmware.com>
NULL as an error indicator is meaningless, since it will return NULL
on success anyway if the caller passes in zero as the image's address
and asks to calculate the offset of the first pixel. For example,
_mesa_validate_pbo_access() does this.
This also matches the code in the non-GL_BITMAP codepath, which
already has an assert like this.
v2: Per Brian Paul's review, remove the function call entirely
and tighten the assert to only accept the two formats compatible with
GL_BITMAP. They always have one component per pixel.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
