I removed that return 0 by mistake. Ooops.
Fixes: 6e23fd4 ("nvc0: allow to use compute support on GM200")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This works like a charm but please not that NVF0_COMPUTE have to be set
because compute support is still not enabled by default on GK110+. This
will require more testing to make sure it won't break the 3D state.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Rather than having two almost identical Makefiles, with various VPATH
hacks just fold them, using COMMON_* variables and actually getting
things buildable/shipable.
v2: whitespace fixes, remove Makefile.sources-arch
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Tim Rowley <timothy.o.rowley@intel.com>
This fixes GS piglit failures after adding SI_PARAM_SHADER_BUFFERS,
which bumped NUM_USER_SGPRS and uncovered this bug on SI.
If this was fixed in LLVM, these workarounds wouldn't be needed.
LLVM would have to look at the calling convention to know how many SGPR
inputs are declared, and add VCC and the scratch wave offset (which is
enabled even if we spill SGPRs but not VGPRs, oh well).
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Except:
- u_cache_test -- too long
- translate_test -- unreliable (it's probably testing corner cases that
translate module doesn't care about.)
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The old version of the pass only worked on globals and locals and always
left inputs, outputs, uniforms, etc. alone.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
- Incorporate flatshade flag into the shader generation
- Use provoking vertex (vc) in shader when flat shading.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This reverts commit 62fa868728.
dEQP-GLES3.functional.occlusion_query.* was unhappy about that change.
Still not really sure *what* the other slots in the sample results
buffer are.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
This one is slightly annoying, since trying to write RBRC from draw
would clobber values set in the tiling/gmem code. We could do command-
stream patching for RBRC, as is done on a3xx. Although since it seems
to be a rarely used feature, it is easier just to do RMW to set/clear
the bit.
Fixes dEQP-GLES3.functional.rasterizer_discard.basic.write_depth_triangles
and related tests.
a3xx still needs the same feature, although there it probably makes more
sense to take advantage of the existing cmdstream patching which is
required for RBRC for other reasons.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Seems like a4xx needs offset added to array index for all arrays,
whereas a3xx only for cubemap arrays. Fixes a whole swath of dEQP fails
(roughly *sampler2darray*).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We need to increment offset by # of vertices, not by # of prims. Fixes
a bunch of dEQP fails involving prims other than points. For example,
dEQP-GLES3.functional.transform_feedback.position.lines_separate
Signed-off-by: Rob Clark <robclark@freedesktop.org>
If changed && append, we shouldn't be resetting the internal offset back
to zero. This fixes issues w/ sequences like:
glBeginTransformFeedback()
glDraw()
glPauseTransformFeedback()
glDraw()
glResumeTransformFeedback()
glDraw()
glEndTransformFeedback()
Fixes dEQP-GLES3.functional.transform_feedback.array.separate.points.lowp_vec3
and related tests.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
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>
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>
Otherwise we incorrectly claim ARB_ssbo support even with older LLVM versions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94917
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.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>
This fixes a compile error while building Nouveau with C++11 enabled (and
glibc >= 2.23). This happens if SWR is enabled, as it forces C++11.
Signed-off-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Jose Fonseca <jfonseca@vmware.com>
https://bugs.freedesktop.org/show_bug.cgi?id=94907
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>
Courtesy of address sanitizer.
[airlied: free buffers as well]
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Increase r to four channels as rgba is written to it
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.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 was triggered by
dEQP-GLES3.functional.vertex_array_objects.all_attributes
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Move the buffer resource extraction code out into its own function.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
