| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Necessary to prevent performance regressions due to extra flushing.
Probably should enlarge it even further when also updating
uniforms through the CE, but this seems large enough for now.
v2: Add preamble IB.
Signed-off-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
v2: Use the correct IB to update request (Bas Nieuwenhuizen)
v3: Add preamble IB. (Bas Nieuwenhuizen)
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
| |
Not used by drivers.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
| |
So that LLVM frees its globals.
Trivial.
|
|
|
|
| |
Trivial.
|
|
|
|
|
|
|
|
|
| |
64bits MSVCRT's exp2f(-inf) returns -inf instead of 0. Tested with
MSVC 2013's CRT. (I haven't tried 2015 yet.)
Also this does not happen with MinGW.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
All power of two of up native vector length.
There is actually a bug in lp_build_round for v2, whereby it doesn't
round to nearest. Fixing is left to the future, but the test is now
able to expect it to fail.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
| |
Just use LLVM_HOST_TRIPLE, which is available at least from LLVM 3.3
onwards, and is pretty much what llvm::sys::getProcessTriple() does anyway,
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
| |
Just keep a copy of the module_name in gallivm.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
One needs to call setJITMemoryManager for LLVM 3.3, instead of
setMCJITMemoryManager.
This regressed in commits 065256df/75ad4fe7 when trying to make the
code to build with LLVM 3.6.
Tested MCJIT with LLVM 3.3 to 3.6.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the LLVM versions that support it, so we can easily switch between
MCJIT/old-jit for testing.
The new option is GALLIVM_MCJIT.
Unfortunately setting GALLIVM_MCJIT=1 for LLVM 3.3 or 3.4 causes
segfault, both on Linux and Windows. I'm almost certain this used to
work, so there probably is a regression somewhere.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
| |
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
| |
Instead of LLVM C++ interfaces.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And llvm::raw_string_ostream where not (LLVM 3.3).
Thereby eliminating yet another dependency on unstable LLVM interfaces.
As a bonus this also gets LLVM IR on OutputDebugMessageA on MSVC (which
was disabled, probably due to C++ issues.)
Tested `lp_test_arit -v -v` on LLVM 3.3, 3.4 and 3.8.
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
| |
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
| |
This reverts commit f525db6358fbaa7b4296d2e6484e0b1ae703ac78.
It was superseeded by commit 649704f1f7c9e1d0990d34a76154b2eb656bee42.
|
|
|
|
|
|
|
| |
Single-sampled texture miplevels > 1 are stored in POT-aligned areas, but
we only get one value to control the stride of the src and dst for single
sampled buffers. A RCL tile blit from level != 1 to level == 0 would
therefore load from the wrong stride.
|
|
|
|
| |
This was for TGSI, which we no longer have to deal with.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They were already declared as such. It was changed here:
commit 31f0967fb50101437d2568e9ab9640ffbcbf7ef9
Author: Ian Romanick <[email protected]>
Date: Wed Sep 2 14:43:18 2015 -0700
i965: Make intel_miptree_map_raw static
Cc: Ian Romanick <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This isn't currently that easy to expand, so fix it up
before expanding it later to include dynamic samplers.
[airlied: use some local variables (Roland)]
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
| |
Fixes resource memory leaks.
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we have something like:
MOV OUT[n], IN[m].wzyx
the existing grouping code was missing a potential conflict. Due to
input needing to be sequential scalar regs, we have:
IN: x <-> y <-> z <-> w
which would be grouped to:
OUT: w <-> z2 <-> y2 <-> x (where the 2 denotes a copy/mov)
but that can't actually work. We need to realize that x and w are
already in the same chain, not just that they aren't both already in
new chain being built.
With this fixed, we probably no longer need the hack from f68f6c0.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
This is typically used by the closed driver before SURFACE_SYNC.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
| |
It's only required on the compute ring. This matches the closed driver.
The compute flag is removed to prevent confusion and Bas's compute shader
patches remove it in the whole function.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
| |
Yes, that flag is really needed.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
I'm not sure about this. This will make the engines go idle, but the caches
will be unflushed. This should match app behavior without performance
counters, which can be a good thing.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
| |
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
| |
The second ffs returns 0, yielding count == -1.
v2: change 1 to 1u
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
| |
just need to do the calculation in floating-point and then round things
properly
Reviewed-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
| |
When this extension was added, an underscore were mistakenly replaced
by a space. Let's correct this, so it's a tad easier to grep for this
extension.
Signed-off-by: Erik Faye-Lund <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Color clears should respect each drawbuffer's color mask state.
Previously, we tried to leave the color mask untouched. However,
_mesa_meta_drawbuffers_from_bitfield() ended up rebinding all the
color drawbuffers in a different order, so we ended up pairing
drawbuffers with the wrong color mask state.
The new _mesa_meta_drawbuffers_and_colormask() function does the
same job as the old _mesa_meta_drawbuffers_from_bitfield(), but
also rearranges the color mask state to match the new drawbuffer
configuration.
This code was largely ripped off from Gallium's st_Clear code.
This fixes ES31-CTS.draw_buffers_indexed.color_masks, which binds
up to 8 drawbuffers, sets color masks for each, and then calls
glClearBufferfv to clear each buffer individually. ClearBuffer
causes us to rebind only one drawbuffer, at which point we used
ctx->Color.ColorMask[0] (draw buffer 0's state) for everything.
We could probably delete _mesa_meta_drawbuffers_from_bitfield(),
but I'd rather not think about the i965 fast clear code. Topi is
rewriting a bunch of that soon anyway, so let's delete it then.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94847
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This allows meta operations to inspect the existing color mask, and
then do their own smashing.
BlitFramebuffer and Clear already override the color mask, so this
was also redundant.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
| |
We need to fix up the offset to point at the face of the cube. Fixes
piglit fbo-cubemap, copyteximage CUBE, and glean's fbo test.
Cc: "11.1 11.2" <[email protected]>
|
|
|
|
|
|
| |
Fixes piglit mixed-immediate-and-vbo, and may significantly improve
performance of applications that store a 4-byte IB in the same VBO as
vertex data.
|
|
|
|
|
|
| |
Catches the cause of failure in
arb_vertex_buffer_object-mixed-immediate-and-vbo, I've had this class of
failure before, and it probably won't be the last time.
|
|
|
|
|
|
|
| |
If we're going to sample from or render to them at some particular size,
we'd better make sure that they actually are that size. Causes some tests
under simulation to generate appropriate error messages instead of
failures.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting from C++11, several math functions, like isinf, moved into the std
namespace. Since cmath undefines those functions before redefining them inside
the namespace, and glibc 2.23 defines the C variants as macros, the C variants
in global namespace are not accessible any longer.
v2: Move the fix outside of Nouveau, as suggested by Jose Fonseca, since anyone
might need it when GCC switches to C++14 by default with GCC 6.0.
v3:
* Put the code directly inside c99_math.h rather than creating a new header
file, as asked by Jose Fonseca;
* Guard the code behind glibc version checks, as only glibc > =2.23 defines
isinf & co. as functions, as suggested by Jose Fonseca.
Signed-off-by: Pierre Moreau <[email protected]>
Signed-off-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
I need to do this so I could use R600_BIG_ENDIAN in files which include
r600_pipe_common.h but not r600_pipe.h
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Oded Gabbay <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
(cherry picked from commit 596c6504b3dcab318dc93ec42517c9a0fde1b255)
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
(cherry picked from commit ca2fbf6f8fe5e1853064c81fd3334a8172d65689)
|
|
|
|
|
|
|
|
|
|
| |
llvm 3.7 sometimes simply miscompiles vector selects.
See https://bugs.freedesktop.org/show_bug.cgi?id=94972
This was fixed in llvm r249669
(https://llvm.org/bugs/show_bug.cgi?id=24532).
Reviewed-by: Jose Fonseca <[email protected]>
|