summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* glsl: don't rename variables in interface block arrays.Paul Berry2013-07-251-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* draw: fix vertex id computationZack Rusin2013-07-255-13/+37
| | | | | | | | | | | | | 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]>
* draw: cleanup and fix instance id computationZack Rusin2013-07-254-13/+8
| | | | | | | | | | | | | | 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]>
* gallivm: Remove dead code in lp_build_compare_ext.Vinson Lee2013-07-241-6/+0
| | | | | | | | | | 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]>
* mesa: implement mipmap generation for compressed 2D array texturesBrian Paul2013-07-241-16/+43
| | | | | | | | | | | | 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]>
* meta: handle 2D texture arrays in decompress_texture_image()Brian Paul2013-07-241-2/+21
| | | | | | | | 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]>
* mesa: handle 2D texture arrays in get_tex_rgba_compressed()Brian Paul2013-07-241-28/+24
| | | | | | | | | | | 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]>
* nv50,nvc0: s/uint16/uint32 for constant buffer offsetChristoph Bumiller2013-07-242-2/+2
| | | | | | | | 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.
* draw: always call util_cpu_detect() in draw context creation.Roland Scheidegger2013-07-241-1/+4
| | | | | | | | | | | | | | | | | | | | 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]>
* mesa: fix rgtc snorm decodingRoland Scheidegger2013-07-241-3/+3
| | | | | | | | | 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]>
* gallium/util: Fix detection of AVX cpu capsAndre Heider2013-07-231-2/+25
| | | | | | | | | | | | | | | | | 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]>
* docs: Add items for GL4.4Chris Forbes2013-07-231-0/+14
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* clover: Respect kernel argument alignment restrictions.Francisco Jerez2013-07-222-2/+19
| | | | | Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
* clover: Extend kernel arguments for differing host and device data types.Francisco Jerez2013-07-222-4/+56
| | | | | | | Loosely based on a similar patch by Tom Stellard. Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
* clover: Byte-swap kernel arguments when host and device endianness differ.Francisco Jerez2013-07-221-37/+65
| | | | | Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
* clover: Add kernel argument fields to allow differing host/target data types.Francisco Jerez2013-07-221-2/+23
| | | | | | | Loosely based on a similar patch by Tom Stellard. Cc: [email protected] Reviewed-by: Tom Stellard <[email protected]>
* clover: Pass corresponding module::argument to kernel::argument::bind().Francisco Jerez2013-07-222-84/+61
| | | | | | | | 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]>
* clover: Return correct value for CL_DEVICE_ENDIAN_LITTLETom Stellard2013-07-223-1/+8
| | | | | | | | Query the driver using PIPE_CAP_ENDIANNESS rather than always returning true. Cc: [email protected] Reviewed-by: Francisco Jerez <[email protected]>
* gallium: Add PIPE_CAP_ENDIANNESSTom Stellard2013-07-2214-1/+38
| | | | | | Cc: [email protected] [ Francisco Jerez: Fix "PIPE_ENDIAN_SMALL" in the documentation, define PIPE_ENDIAN_NATIVE. ]
* configure.ac: Use correct options names in AC_ARG_ENABLE.Matt Turner2013-07-221-4/+4
|
* egl/build: Remove unused GLAPI_LIB.Matt Turner2013-07-221-2/+0
|
* build: Remove unused EGL_PLATFORMS.Matt Turner2013-07-222-7/+1
|
* build: Add tests directories to SUBDIRSMatt Turner2013-07-224-7/+5
| | | | Fixes a problem with distcheck.
* llvmpipe: Ensure FTZ/DAZ flags are set on deferred draw flushes.Zack Rusin2013-07-221-0/+8
| | | | Tested-by: José Fonseca <[email protected]>
* llvmpipe: Remove lp_rast_get_num_threads().José Fonseca2013-07-222-11/+0
| | | | | | Never called. Trivial.
* scons: Don't use -z defs ld option on Mac.José Fonseca2013-07-212-2/+4
| | | | Should fix fdo bug 67098.
* glsl: Initialize ast_function member variables.Vinson Lee2013-07-211-1/+2
| | | | | | Fixes "Uninitialized pointer field" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]>
* Apple: glFlush() is not needed with CGLFlushDrawable()Jeremy Huddleston Sequoia2013-07-201-2/+0
| | | | | | <rdar://problem/14496373> Signed-off-by: Jeremy Huddleston Sequoia <[email protected]>
* util/u_math: Define NAN/INFINITY macros for MSVC.José Fonseca2013-07-201-0/+4
| | | | Untested. But should hopefully fix the build.
* llvmpipe/tests: update arith test to check for edge casesZack Rusin2013-07-191-9/+19
| | | | | | | | | 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]>
* gallivm: add a log function that handles edge casesZack Rusin2013-07-192-0/+21
| | | | | | | | | 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]>
* gallivm: export unordered/ordered cmp to a common functionZack Rusin2013-07-191-283/+158
| | | | | | | | | 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]>
* gallivm: handle -inf, inf and nan's in sin/cos instructionsZack Rusin2013-07-192-0/+49
| | | | | | | | | 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]>
* gallivm: add a version of log2 which handles edge casesZack Rusin2013-07-193-6/+65
| | | | | | | | | | | | | | 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]>
* gallivm: fix edge cases in exp2Zack Rusin2013-07-191-3/+7
| | | | | | | | | | 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]>
* gallivm: handle nan's in min/maxZack Rusin2013-07-196-52/+482
| | | | | | | | | | | 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]>
* scons: Disallow undefined symbols in Xlib libGL.so.José Fonseca2013-07-192-0/+6
| | | | | | | | 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.
* mesa: Dispatch ARB_framebuffer_object and EXT_framebuffer_object differently9.2-branchpointTomasz Lis2013-07-186-6/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* st/mesa: Enable the ARB_shading_language_420pack extension for 1.30+.Kenneth Graunke2013-07-181-0/+1
| | | | | | | | 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]>
* i965: Enable the GL_ARB_shading_language_420pack extension on Gen6+.Kenneth Graunke2013-07-181-0/+1
| | | | | | | | 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]>
* glsl: Handle the binding qualifier for UBO variables.Kenneth Graunke2013-07-181-0/+10
| | | | | | | | | | | | | 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]>
* glsl: Propagate UBO binding qualifier into UBO member variables.Kenneth Graunke2013-07-181-0/+7
| | | | | | | | | | | | | 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]>
* glsl: Handle the binding qualifier for arrays of samplers.Kenneth Graunke2013-07-181-0/+25
| | | | | | | | | | | | | | | | | | | | | 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]>
* glsl: Add plumbing for handling uniform binding qualifiers.Kenneth Graunke2013-07-181-3/+23
| | | | | | | | | | | | | | | 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]>
* glsl: Delete unused code for handling samplers in array-initializers.Kenneth Graunke2013-07-181-14/+0
| | | | | | | | | | | | | | | | | | | | | | 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]>
* glsl: Cross-validate explicit binding points.Kenneth Graunke2013-07-181-0/+19
| | | | | | | | | | 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]>
* glsl: Propagate explicit binding information from AST to IR.Kenneth Graunke2013-07-181-2/+5
| | | | | | | | | | | | | | 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]>
* glsl: Add ir_variable fields for explicit bindings.Kenneth Graunke2013-07-182-0/+17
| | | | | | | | | | These are not used yet, but they exist and are copied appropriately. v2: Add an explicit "int binding" variable rather than reusing constant_value, as suggested by Paul Berry. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* glsl: Add validation for the "binding" qualifier.Kenneth Graunke2013-07-181-0/+81
| | | | | | | | | | | | | The "binding" qualifier only applies to UBO blocks and samplers, along with arrays of those types. (It would also apply to images and atomic counters, but we don't support those yet.) This also validates sampler bindings against the maximum number of texture units, and UBO bindings against the number of uniform buffer binding points. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* glsl: Parse the "binding" keyword and store it in ast_type_qualifier.Kenneth Graunke2013-07-183-1/+25
| | | | | | | | | Nothing actually uses this yet. v2: Remove >= 0 checks. They'll be handled in later validation. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>