dEQP noticed that we were advertising completely bogus values. The
actual maximum is 127.0f.
*But* we have to use an artifically low maximum to work around a bug
in the dEQP test, which gets confused when the max line width is too
large and lines start going off-screen.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
There are still some edge cases which result in a neighbor-loop. Which
needs to be fixed, but this hack at least makes deqp tests finish.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Fixes a bunch of flat-varying fail on a4xx (where we need to use ldlv to
read the un-interpolated varying).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Since we cannot mov into a predicate register, the frontend uses a
'cmps.s p0.x, cond, 0' as a stand-in for mov to p0.x. It does this
since it has no way to know that the source cond instruction (ie.
for a kill, br, etc) will only be used to write the predicate reg.
Detect this, and re-write the instruction writing p0.x to skip the
original cmps.[sfu]. (It is done like this, rather than re-writing
the dest of the first cmps.[sfu] in case the first cmps.[sfu]
actually has other users.)
Signed-off-by: Rob Clark <robclark@freedesktop.org>
vertex_input_slots would be an appropriate name for an integer, but not
a bool.
Also remove a cond ? true : false from a count_attribute_slots() call
site, noticed during the rename.
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
The credit for finding and isolating this bug goes to Vinson and Roland.
The buggy LLVM versions were found by doing
opt -instcombine llvm-pr27332.ll > /dev/null
where llvm-pr27332.ll is the IR from
https://llvm.org/bugs/show_bug.cgi?id=27332#c3
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
We used to use sse roundps intrinsic directly, but switched to use the llvm
intrinsics for rounding with e4f01da15d.
However, llvm semantics follows standard math lib round function which is
specced to do roundNearestAwayFromZero but we really want roundNearestEven
(moreoever, using round generates atrocious code since the cpu can't do it
directly and it results in scalar calls to libm __roundf).
So, use llvm.nearbyint instead, which does exactly the right thing, and even
has the advantage of being available with llvm 3.3 too. (I've verified it
actually generates a roundps instruction with llvm 3.3.)
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=94909
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
libasan is never linked to shared objects (which doesn't go well with
-z,defs). It must either be linked to the main executable, or (more
practically for OpenGL drivers) be pre-loaded via LD_PRELOAD.
Otherwise works.
I didn't find anything with llvmpipe. I suspect the fact that the
JIT compiled code isn't instrumented means there are lots of errors it
can't catch.
But for non-JIT drivers, the Address/Leak Sanitizers seem like a faster
alternative to Valgrind.
Usage (Ubuntu 15.10):
scons asan=1 libgl-xlib
export LD_LIBRARY_PATH=$PWD/build/linux-x86_64-debug/gallium/targets/libgl-xlib
LD_PRELOAD=libasan.so.2 any-opengl-application
Acked-by: Roland Scheidegger <sroland@vmware.com>
This is supposed to be INVALID_OPERATION in ES. We already did this
for the fv/iv variants, but not Iiv/Iuv, which are new in ES 3.2 (or
extensions).
Fixes:
ES31-CTS.texture_border_clamp.samplerparameteri_non_gen_sampler_error
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Courtesy of address sanitizer.
[airlied: free buffers as well]
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is the last necessary bit for OpenGL 4.2 support. All driver-specific
functionality has already been implemented as part of extensions.
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This is kind of a hack. We currently track precise requirements
by decorating ir_variables. Propagating or grafting the RHS of an
assignment to a precise value into some other expression tree can
lose those decorations.
In the long run, it might be better to replace these ir_variable
decorations with an "exact" decoration on ir_expression nodes,
similar to what NIR does.
In the short run, this is probably good enough. It preserves
enough information for glsl_to_nir to generate "exact" decorations,
and NIR will then handle optimizing these expressions reasonably.
Fixes ES31-CTS.gpu_shader5.precise_qualifier.
v2: Drop invariant handling, as it shouldn't be necessary (caught
by Jason Ekstrand).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
ARB_program_interface_query requires that we add struct fields
recursively down to basic types.
Fixes 52 struct test cases in dEQP-GLES31.functional.program_interface_query.*
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
No functional change here, but this now lets us recurse throught structs
in add_shader_variable().
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This lets us pass in the absolution location of a variable instead of
computing it in add_shader_variable() based on variable location and
bias. This is in preparation for recursing into struct variables.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This consolidates the combination of create_shader_variable() and
add_program_resource() into a new helper function. No functional
difference, but we'll expand add_shader_variable() in the next few
commits.
Signed-off-by: Kristian Høgsberg Kristensen <kristian.h.kristensen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The existing code uses SSSE3, and because it isn't compiled in a
separate file compiled with that, it is usually not used (that, of
course, could be fixed...), whereas SSE2 is always present with 64-bit
builds. This should be pretty much as fast as the pshufb version,
albeit those code paths aren't really used on chips without llc in any
case.
v2: fix andnot argument order, add comments
v3: use pshuflw/hw instead of shifts (suggested by Matt Turner), cut comments
v4: [mattst88] Rebase
Reviewed-by: Matt Turner <mattst88@gmail.com>
Replaces four byte loads and four byte stores with a load, bswap,
rotate, store; or a movbe, rotate, store.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
It is incorrect to assume that pixel format is always in BGR byte order.
We need to check bitmask parameters (such as |redMask|) to determine whether
the RGB or BGR byte order is requested.
v2: reformat code to stay within 80 character per line limit.
v3: just fix the byte order problem first and investigate SRGB later.
v4: rebased on top of the GLES3 sRGB workaround fix.
v5: rebased on top of the GLES3 sRGB workaround fix v2.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes
dEQP-GLES31.functional.uniform_location.negative.atomic_fragment
dEQP-GLES31.functional.uniform_location.negative.atomic_vertex
Both of which have lines like
layout(location = 3, binding = 0, offset = 0) uniform atomic_uint uni0;
The ARB_explicit_uniform_location spec makes a very tangential mention
regarding atomic counters, but location isn't something that makes sense
with them.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
