| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
TargetOptions::NoFramePointerElimNonLeaf was removed in LLVM 3.4
r187093.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The is_loop_terminator() function was asserting that the following
kind of if statement could never occur:
if (...) { } else { }
(presumably based on the assumption that such an if statement would be
eliminated by previous optimization stages). But that isn't the
case--it's possible that previous optimization stages might simplify
more complex code down to this empty if statement, in which case it
won't be eliminated until the next time through the optimization loop.
So is_loop_terminator() needs to handle it. Fortunately it's easy to
handle--it's not a loop terminator because it does nothing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64330
CC: [email protected]
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two callers of brw_search_cache() weren't initializing that function's
inout_offset parameter: brw_blorp_const_color_params::get_wm_prog()
and brw_blorp_const_color_params::get_wm_prog().
That's a benign problem, since the only effect of not initializing
inout_offset prior to calling brw_search_cache() is that the bit
corresponding to cache_id in brw->state.dirty.cache may not be set
reliably. This is ok, since the cache_id's used by
brw_blorp_const_color_params::get_wm_prog() and
brw_blorp_blit_params::get_wm_prog() (BRW_BLORP_CONST_COLOR_PROG and
BRW_BLORP_BLIT_PROG, respectively) correspond to dirty bits that are
not used.
However, failing to initialize this parameter causes valgrind to
complain. So let's go ahead and fix it to reduce valgrind noise.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66779
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The linker matches up variables in interface blocks according to their
block name and variable name. When support for interface block arrays
was added in commit d6863acb, we renamed variables appearing in
interface blocks so that their name included the array size. For
example, in a block like this:
out foo {
float bar
} baz[3];
The variable "bar" would get renamed to "bar[3]".
This is unnecessary, and leads to problems in supporting geometry
shaders, since geometry shaders require vertex shader outputs which
are non-arrays to be linked up to geometry shader inputs which are
arrays.
This patch makes the behaviour of interface block arrays the same as
simple non-array interface blocks; in both cases, the variables
contained within them are not renamed.
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vertex id has to be unaffected by the start index (i.e. when calling
draw arrays with start_index = 5, the first vertex_id has to still
be 0, not 5) and it has to be equal to the index when performing
indexed rendering (in which case it has to be unaffected by the
index bias). This fixes our behavior.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The instance id system value always starts at 0, even if the
specified start instance is larger than 0. Instead of implicitly
setting instance id to instance id plus start instance and then
having to subtract instance id when computing the buffer offsets
lets just set instance id to the proper instance id. This fixes
instance id computation and cleansup buffer offset computation.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
There are earlier returns for PIPE_FUNC_NEVER and PIPE_FUNC_ALWAYS. The
switch value of 'func' cannot be either of those values.
Fixes "Logically dead code" defects reported by Coverity.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We weren't looping over all the slices in the array. The updated
code should also correctly handle 3D compressed textures too, whenever
we have that feature.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850
NOTE: This is a candidate for the 9.x branches
Cc: [email protected]
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850
NOTE: This is a candidate for the 9.x branches.
Cc: [email protected]
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
If we call glGetTexImage() for a compressed 2D texture array we need
to loop over all the slices.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850
NOTE: This is a candidate for the 9.x branches.
Cc: [email protected]
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
|
|
|
| |
Looks like a thinko, "Hey, constant buffers can be at most 64 KiB
in size, offset can't be larger." But it can, of course.
I think piglit lacks a test for UBO and BindBufferRange that
tests if it actually works.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since disabling denorms in draw_vbo() we require the util_cpu_caps to be
initialized there. Hence add another util_cpu_detect() call in
draw_create_context() which should ensure this.
(There is another call in draw_get_option_use_llvm() which only gets called
with x86 (not x86_64) but calling it always there wouldn't help since it most
likely wouldn't get called when compiling without llvm, so leave it alone
there.)
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=66806.
(Because util_cpu_caps wasn't initialized when first calling util_fpstate_get()
hence it returning zero, but it would later get initialized by rtasm translate
code hence when draw call returned it unmasked all exceptions by calling
util_fpstate_set(). This was happening only with DRAW_USE_LLVM=0 or not
compiling with llvm, otherwise the llvm init code was calling it on time too.)
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Zack Rusin <[email protected]>
Tested-by: Vinson Lee <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The codeword must be unsigned (otherwise will shift in 1's from above when
merging low/high parts so some texels decode wrong).
This also affects gallium's util/u_format_rgtc.
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Zack Rusin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For AVX it's not sufficient to only rely on the cpuid flags. If the CPU
supports these extensions, but the OS doesn't, issuing these insns will
trigger an undefined opcode exception.
In addition to the AVX cpuid bit we also need to:
* test cpuid for OSXSAVE support
* XGETBV to check if the OS saves/restores AVX regs on context switches
See "Detecting Availability and Support" at
http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions
Signed-off-by: Andre Heider <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Cc: [email protected]
Reviewed-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
| |
Loosely based on a similar patch by Tom Stellard.
Cc: [email protected]
Reviewed-by: Tom Stellard <[email protected]>
|
|
|
|
|
| |
Cc: [email protected]
Reviewed-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
| |
Loosely based on a similar patch by Tom Stellard.
Cc: [email protected]
Reviewed-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
|
| |
And remove size information from most kernel::argument derived
classes, it's no longer going to be necessary.
Cc: [email protected]
Reviewed-by: Tom Stellard <[email protected]>
|
|
|
|
|
|
|
|
| |
Query the driver using PIPE_CAP_ENDIANNESS rather than always returning
true.
Cc: [email protected]
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
| |
Cc: [email protected]
[ Francisco Jerez: Fix "PIPE_ENDIAN_SMALL" in the documentation,
define PIPE_ENDIAN_NATIVE. ]
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes a problem with distcheck.
|
|
|
|
| |
Tested-by: José Fonseca <[email protected]>
|
|
|
|
|
|
| |
Never called.
Trivial.
|
|
|
|
| |
Should fix fdo bug 67098.
|
|
|
|
|
|
| |
Fixes "Uninitialized pointer field" defect reported by Coverity.
Signed-off-by: Vinson Lee <[email protected]>
|
|
|
|
|
|
| |
<rdar://problem/14496373>
Signed-off-by: Jeremy Huddleston Sequoia <[email protected]>
|
|
|
|
| |
Untested. But should hopefully fix the build.
|
|
|
|
|
|
|
|
|
| |
Test infs, zeros and nans with our arith functions to assure
correct/defined behavior with those values.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Same as log2_safe, which means that it can handle infs, 0s and
nans.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Only the floating point operarators change everything else
is the same so it makes sense to share the code.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
| |
sin/cos for anything not finite is nan and everything else has
to be between [-1, 1].
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That means that if input is:
* - less than zero (to and including -inf) then NaN will be returned
* - equal to zero (-denorm, -0, +0 or +denorm), then -inf will be returned
* - +infinity, then +infinity will be returned
* - NaN, then NaN will be returned
It's a separate function because the checks are a little bit costly
and in most cases are likely unnecessary.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
exp(0) has to be exactly 1, exp(-inf) has to be 0, exp(inf) has
to be inf and exp(nan) has to be nan, this fixes all of those
cases.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Both D3D10 and OpenCL say that if one the inputs is nan then
the other should be returned. To preserve that behavior
the patch fixes both the sse and the non-sse paths in both
functions and adds helper code for handling nans.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
| |
It's not the first time that, due to missing build dependencies or
incomplete commits, we end up with a broken libGL.so that's missing
symbols, causing all tests to fail catastrophically.
Instead try to catch this sort of issues earlier.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Almost all of the functions between the ARB and the EXT share the same
GLX protocol because the functionality is, essentially, identical.
However, there are some differences between the extensions:
- In the ARB extension, names must come from glGenBuffers.
- In the ARB extension, framebuffer objects are not shared (but they are
in the EXT).
For these reasons, glBindFramebuffer and glBindRenderbuffer have
different GLX protocol opcodes than their EXT counterparts. Currently
these functions alias each other in the dispatch table. This makes it
impossible to be truly spec conformant.
This patch enables fixing the conformance issue by splitting
glBindFramebuffer / glBindFramebufferEXT and glBindRenderbuffer /
glBindRenderbufferEXT into separate dispatch table entries.
Patches will be available shortly to:
- Fix the conformance issue.
- Stop advertising the EXT in OpenGL 3.1 (or core profiles).
HOWEVER, this does represent a compatibility break between the loader
(libGL or the Xserver GLX module) and the driver. Mesa drivers compiled
without this change will request a single dispatch table entry for
glBindFramebuffer and glBindFramebufferEXT. Since the updated loader
has different entries for each, the request will fail, and the driver
will die in a fire.
Drivers built with the change should continue to load fine on loaders
without the change. In this case, the driver will separately ask for
entries for glBindFramebuffer and glBindFramebufferEXT, and the loader
will tell it the same location. Since the loader in the server's GLX
module is not (yet) updated, this should not be a problem. We also do
not advertise the ARB extension from the server, so, again, this should
not be a problem for the server.
HOWEVER, this means that DRI1 drivers (remember mga_dri.so?) will no
longer load with libGL build hereafter. That means this patch will need
to be back ported to the 8.0 branch.
v2 (idr): Added missing GLX protocol opcodes for the EXT functions and
corrected the opcodes for the ARB functions. Updated GLX indirect_api
unit test and dispatch sanity unit test.
Signed-off-by: Tomasz Lis <[email protected]>
Signed-off-by: Bartosz Zawistowski <[email protected]>
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Ian Romanick <[email protected]> [v1]
|
|
|
|
|
|
|
|
| |
Any driver that supports GLSL 1.30 should be able to handle this
extension, as it's entirely implemented in the GLSL compiler.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
While all the work is in the shared GLSL compiler, this extension
requires GLSL 1.30, which is currently only supported on Gen6+.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
layout(binding = N) is equivalent to calling glUniformBlockBinding(_,N).
This currently only handles the GLSL 1.40 case - no interface names, no
arrays of uniform blocks. This is okay since we don't yet support GLSL
1.50, and don't expose ARB_shading_language_420pack in ES 3.0.
v2: Move into the other function; use binding, not constant_value.
Signed-off-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without an instance name, there is no ir_variable representing the
actual uniform block declaration. When the linker goes to set uniform
initializers, it only sees the members as ir_variables; never the block.
So, unfortunately, the members need to know about the binding.
There has to be a better way to do this.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, uniform array variables are initialized by array literals.
That is, val->type->array_elements >= storage->array_elements.
However, samplers are different. Consider a declaration such as:
layout(binding = 5) uniform sampler2D[3];
The initializer value is a single integer (5), while the storage has 3
array elements. The proper behavior here is to increment one for each
element; they should be initialized to 5, 6, and 7.
This patch introduces new code for sampler types which handles both
arrays of samplers and single samplers correctly.
v2: Move into the other function; use binding, not constant_value.
Signed-off-by: Kenneth Graunke <[email protected]>
Acked-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sampler uniforms and uniform blocks do not have a var->constant_value.
Instead, they have an integer var->binding value.
This makes extending set_uniform_initializer() somewhat problematic: it
assumes that there is an ir_constant * which represents the initializer,
and that it's safe to dereference that without any NULL checks.
Instead, this patch creates an analogous function for binding
qualifiers, and calls one or the other as appropriate.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is existing code to handle sampler uniform initializers. Prior to
GLSL 4.20's "binding" keyword, sampler uniforms don't have initializers
at all, so this is somewhat surprising.
The existing code is broken into two cases: one where both the variable and
initializer are arrays, and a second where the variable and initializer are
scalars.
The first case should never occur, since array-typed initializers do not
exist for sampler uniforms. Even with the binding keyword, the
initializer is a single integer which represents the texture unit to use
for the first array element.
The second is apparently used for some fixed-function code.
v2: Rewrite the commit message - suggested by Paul.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
All compilation units need to agree on the binding point, if they
specify one at all.
v2: Use binding, not constant_value.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than creating a new "binding" field in ir_variable, we reuse
constant_value since the linker code for handling uniform initializers
uses that.
Since UBOs and samplers can't otherwise have initializers/constant
values, there shouldn't be a conflict.
v2: Propagate the new binding variable around too.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
|