| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
ported from r600c, fixes fp-cmp, glsl1-sqrt*
|
|
|
|
| |
Should fix errors on the original nv30, reported by pmdata.
|
|
|
|
|
|
|
| |
This prevents assertion failures or cascading errors after we've
logged the fact that we were unable to handle the initializer.
Fixes unsized-array-non-const-index-2.vert
|
| |
|
|
|
|
| |
Bug #29608.
|
| |
|
| |
|
|
|
|
|
|
|
| |
The previous any() implementation would generate arg0.x || arg0.y ||
arg0.z. Having an expression operation for this makes it easy for the
backend to generate something easier (DPn + SNE for 915 FS, .any
predication on 965 VS)
|
| |
|
|
|
|
| |
Fixes: glsl-fs-any
|
|
|
|
| |
Fixes: glsl-vs-position-outval. Bug #28138 (regnum online)
|
|
|
|
| |
Signed-off-by: José Fonseca <[email protected]>
|
|
|
|
| |
Signed-off-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
| |
s->close_first was on the wrong side of the inequality.
Caught by blender.
Thanks to AndrewR for reporting this.
|
|
|
|
|
|
|
| |
We need to always at least export one component (wether it's depth
or color. Add valid r7xx shader program for depth decompression.
Signed-off-by: Jerome Glisse <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We ended up returning CONST[loc] rather than TEMP[loc2]. Things would
*usually* end up working out OK, since the constants often ended up
getting allocated to CONST[loc..loc+columns] with no swizzle. But for
the case where the contigous temporary copy of the swizzled constant
vec4 args was actually needed, we'd end up reading some other constant
values, possibly including ones not actually allocated.
Fixes: glsl-varying-mat3x2.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously glcpp would silently abort if it couldn't fstat the file being
read, (so it would work with stdin redirected from a file, but would not
work with stdin as a tty). The stat was so that glcpp could allocate
a buffer for the file content in a single call.
We now use talloc_realloc instead, (even if the fstat is
possible). This is theoretically less efficient, but quite irrelevant,
(particularly because the standalone preprocessor is used only for
testing).
|
|
|
|
|
|
|
|
|
|
| |
We recently added several tests that intentionally trigger
preprocessor errors. During valgrind-based testing, our test script
was noticing the non-zero return value from the preprocessor and
incorrectly flagging the valgrind-based test as failing.
To fix this, we make valgrind return an error code that is otherwise
unused by the preprocessor.
|
|
|
|
|
|
|
|
| |
This error message was missing so that the program would simply
segfault if the provided filename could not be opened for some reason.
While we're at it, we add explicit support for a filename of "-" to
indicate input from stdin.
|
|
|
|
|
| |
This fixes both "#line 0" and "#line XXX YYY" as described in the two
most recent commits.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing DECIMAL_INTEGER pattern is the correct thing to use when
looking for a C decimal integer, (that is, a digit-sequence not
starting with 0 which would instead be an octal integer).
But for #line, we really want to accept any digit sequence, (including
"0"), and always interpret it as a decimal constant. So we add a new
DIGITS pattern for this case.
This should fix the compilation failure noted in bug #28138
https://bugs.freedesktop.org/show_bug.cgi?id=28138
(Though the generated file will not be updated until the next commit.)
|
|
|
|
|
|
|
| |
Previously, the YY_USER_ACTION was overwriting the yylloc->source value
in every action, (after that value had been carefully set by the handling
of the #line directive). Instead, we want to initialize it once in
YY_USER_INIT and then not touch it at all in YY_USER_ACTION.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test exposes two current bugs:
1. The source number is not being correctly emitted in error
messages (instead, it's always 0).
2. A directive of "#line 0" is resulting in the following
parse error:
preprocessor error: Invalid tokens after #
|
|
|
|
|
|
|
| |
The README file had grown a little bit stale. We've been using newer
versions of both the GLSL and C99 specifications, so list those. Also,
several of the documented known limitations have since been fixed, so
remove those.
|
|
|
|
|
|
|
| |
This directive is already implemented nicely, but wasn't previously tested.
It will be convenient to use this directive in further tests that rely
on error messages, (such as ensuring that #line correctly sets the line
number in the error message).
|
|
|
|
| |
Fixes glsl-getactiveuniform-array-size.
|
|
|
|
| |
Fixes: glsl-getactiveuniform-length.
|
|
|
|
|
|
|
|
| |
util_fill_rect could not handle formats with more than 32 bits,
since the fill color was a uint32_t value. Fix this by using
a util_color union instead, and also expand the union so it
works with formats which have up to 256 bits (the max of any
format currently defined).
|
|
|
|
| |
Should improve performance, possibly significantly.
|
| |
|
|
|
|
|
|
|
| |
Gallium always puts gl_PointCoord in GENERIC[0] if
point_quad_rasterization is enabled.
This is silly, but for now it makes mesa-demos/glsl/pointcoord work.
|
|
|
|
|
|
|
|
|
|
| |
Before, we were discarding the compiled vertex program on each
vertex program change.
Now we compile the program as if there were 6 clip planes and
dynamically patch in an "end program" bit at the right place.
Also, nv30 should now work.
|
|
|
|
|
|
|
|
|
| |
the current code reuses the same vbo over and over, however after a flush
we'd stall and wait for mapping on the vbo when we should just fire and forget.
On a gears test this brings me from ~620 to ~750 on my rv530 in swtcl mode.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
| |
Do not rely on PUBLIC being defined in glapi.h. Do not include core
mesa headers.
|
|
|
|
|
| |
Fix mixed use of GL_APIENTRY and GLAPIENTRY. Parameter list of a function
prototype should never be empty.
|
|
|
|
| |
Signed-off-by: Zhenyu Wang <[email protected]>
|
| |
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is the same issue as in the previous patch, but here the Blit is not
implemented for separate depth and stencil buffers at all (such
a configuration is not supported in Gallium) and the code incorrectly treated
a D24S8 texture as two separate buffers, making this Blit a no-op.
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
This code is part of a patch by Marek Olšák.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This should be mostly a noop, except that a plain dereference of a
variable that is not part of a constant expression could now get
"constant folded". I expect that for all current backends this will
be either a noop, or possibly a win when it provokes more
ir_algebraic. It'll also ensure that when new features are added,
tree walking will work normally. Before this, constants weren't
getting folded inside of loops.
|
|
|
|
| |
Fixes: glsl-constant-folding-call-1 (bug #29737)
|
|
|
|
|
|
| |
This is based on a patch from Marek Olšák.
NOTE: This is a candidate for the Mesa 7.8 branch.
|
| |
|
| |
|