summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/gallivm
Commit message (Collapse)AuthorAgeFilesLines
* gallivm: Fix build with LLVM 3.6 (r221751).José Fonseca2014-11-121-1/+10
| | | | | | Tested with LLVM 3.3, 3.4, 3.5, and 3.6. Trivial.
* gallivm: Disable frame-pointer-omission on x86 to ensure right stack alignment.José Fonseca2014-11-031-1/+3
| | | | | | | | | | | | | | | | | | | Between release 3.2 and 3.3 LLVM stopped aligning properly when certain conditions (no allocas, but large number of vectors causing spills to the stack, and frame pointer omission enabled). We were already disabling frame-pointer-omission on several build types, but we now disable it on all build types. It's not clear whether this affects 32-bits x86 processes only, or if it can also affect 64-bits x86_64 processes when AVX registers are available and used. So disable frame-pointer-omission on both x86/x86_64 to be on the safe side. See also: - http://llvm.org/PR21435 Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: When disassemble a function, start by printing out its name.José Fonseca2014-11-031-0/+1
| | | | | | To help recognize what's supposed to do. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Fix build with LLVM 3.3.José Fonseca2014-10-231-0/+2
| | | | | | | | | The setMCJITMemoryManager method doesn't exist in LLVM 3.3. I thought I had tested the latest version of my earlier change with LLVM 3.3, but it looks I missed it. Trivial.
* gallivm: Properly update for removal of JITMemoryManager in LLVM 3.6.José Fonseca2014-10-232-38/+41
| | | | | | | | | | | | | | | | | | JITMemoryManager was removed in LLVM 3.6, and replaced by its base class RTDyldMemoryManager. This change fixes our JIT memory managers specializations to derive from RTDyldMemoryManager in LLVM 3.6 instead of JITMemoryManager. This enables llvmpipe to run with LLVM 3.6. However, lp_free_generated_code is basically a no-op because there are not enough hook points in RTDyldMemoryManager to track and free the code of a module. In other words, with MCJIT, code once created, stays forever allocated until process destruction. This is not speicfic to LLVM 3.6 -- it will happen whenever MCJIT is used regardless of version. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Fix white-space.José Fonseca2014-10-231-7/+7
| | | | | | Replace tabs with spaces. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm,llvmpipe,clover: Bump required LLVM version to 3.3.José Fonseca2014-10-234-70/+7
| | | | | | | | | | | | | | We'll need to update gallivm for the interface changes in LLVM 3.6, and the fewer the number of older LLVM versions we support the less hairy that will be. As consequence HAVE_AVX define can disappear. (Note HAVE_AVX meant whether LLVM version supports AVX or not. Runtime support for AVX is always checked and enforced independently.) Verified llvmpipe builds and runs with with LLVM 3.3, 3.4, and 3.5. Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add PIPE_SHADER_CAP_MAX_OUTPUTS and use it in st/mesaMarek Olšák2014-10-211-0/+2
| | | | | | | | With 5 shader stages and various combinations of enabled and disabled shaders, the maximum number of outputs in one shader doesn't have to be equal to the maximum number of inputs in the following shader. v2: return 32 for softpipe and llvmpipe
* tgsi: change tgsi_shader_info::properties to a one-dimensional arrayMarek Olšák2014-10-041-1/+1
| | | | | | Reviewed-by: Roland Scheidegger <[email protected]> v2: fix svga too
* tgsi: simplify shader properties in tgsi_shader_infoMarek Olšák2014-10-041-8/+7
| | | | Use an array of properties indexed by TGSI_PROPERTY_* definitions.
* gallivm: Fix build for LLVM 3.2Mathias Fröhlich2014-10-014-3/+21
| | | | | | | | | | | | Do not rely on LLVMMCJITMemoryManagerRef being available. The c binding to the memory manager objects only appeared on llvm-3.4. The change is based on an initial patch of Brian Paul. Reviewed-by: Brian Paul <[email protected]> Tested-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
* llvmpipe: Make a llvmpipe OpenGL context thread safe.Mathias Fröhlich2014-09-304-18/+40
| | | | | | | | | | | | | | | | | This fixes the remaining problem with the recently introduced global jit memory manager. This change again uses a memory manager that is local to gallivm_state. This implementation still frees the majority of the memory immediately after compilation. Only the generated code is deferred until this code is no longer used. This change and the previous one using private LLVMContext instances I can now safely run several independent OpenGL contexts driven by llvmpipe from different threads. v3: Rebase on llvm-3.6 compile fixes. Reviewed-by: Jose Fonseca <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
* llvmpipe: Use two LLVMContexts per OpenGL context instead of a global one.Mathias Fröhlich2014-09-302-22/+8
| | | | | | | | | | | | This is one step to make llvmpipe thread safe as mandated by the OpenGL standard. Using the global LLVMContext is obviously a problem for that kind of use pattern. The patch introduces two LLVMContext instances that are private to an OpenGL context and used for all compiles. One is put into struct draw_llvm and the other one into struct llvmpipe_context. Reviewed-by: Jose Fonseca <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
* gallivm: More fallout from disabling with LLVM 3.6Michel Dänzer2014-09-262-4/+14
| | | | | | | | The draw module would still try to use gallivm, causing many piglit tests to fail with an assertion failure. llvmpipe might have been similarly affected. Reviewed-by: Tom Stellard <[email protected]>
* gallivm: Wrap deleted inlcude in if HAVE_LLVM < 0x0306Tom Stellard2014-09-241-0/+2
| | | | This was missed in 8f4ee56.
* gallivm: Disable gallivm to fix build with LLVM 3.6Tom Stellard2014-09-241-0/+10
| | | | | | | | | | | | | | | | LLVM commit r218316 removes the JITMemoryManager class, which is the parent for a seemingly important class in gallivm. In order to fix the build, I've wrapped most of lp_bld_misc.cpp in if HAVE_LLVM < 0x0306 and modifyed the lp_build_create_jit_compiler_for_module() function to return false for 3.6 and newer which effectively disables the gallivm functionality. I realize this is overkill, but I could not come up with a simple solution to fix the build. Also, since 3.6 will be the first release without the old JIT, it would be really great if we could move gallivm to use the C API only for accessing MCJIT. There is still time before the 3.6 release to extend the C API in case it is missing some functionality that is required by gallivm.
* gallivm: fix idivRoland Scheidegger2014-09-231-7/+5
| | | | | | | | | | | ffeb77c7b0552a8624e46e65d6347240ac5ae84d had a typo which turned all signed integer divisions into unsigned ones. Oops. This gets us back the 51 little piglits (all from glsl built-in-functions, fs/vs/gs-op-div-int-ivec2 and similar). Cc: "10.2 10.3" <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: add information about different sampler/view units if analyzing shaderRoland Scheidegger2014-09-202-0/+10
| | | | | | Useful to know in some cases. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm,tgsi: fix idiv by zero crashrconde2014-09-171-3/+21
| | | | | | | | While the result of signed integer division by zero is undefined by glsl (and doesn't exist with d3d10), we must not crash, so need to make sure we don't get sigfpe much like udiv already does. Unlike udiv where we return 0xffffffff (as required by d3d10) there is no requirement right now to return anything specific so we use zero.
* gallivm: add texture target information for sample opcodes to tgsi infoRoland Scheidegger2014-09-171-14/+43
| | | | | | | | | | | | | | sample opcodes don't have valid texture target information (and I don't think this should be changed), however it would be nice if we had that information ready elsewhere, so stuff that information into the tgsi info when analyzing a shader. v2: Ilja Mirkin spotted some bugs wrt not handling msaa resources. So add them and while there also add them to the tex opcode analysis this was cloned from as well (plus get rid of some bug not detecting indirect textures there in some cases too). Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Fix uses of 2^24Richard Sandiford2014-09-161-4/+4
| | | | | | | | | | Fallback cases in lp_bld_arit.c used 2^24 to mean "2 to the power 24", but in C it's "2 xor 24", i.e. 26. Fixed by using 1<< instead. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Cc: "10.2 10.3" <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallivm: Add SNORM clamping to lp_build_{add, sub}Richard Sandiford2014-09-161-6/+28
| | | | | | | ...fixing the associated TODO. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Richard Sandiford <[email protected]>
* gallivm: attach DataLayout to module too, not just pass manager.Rafael Ávila de Espíndola2014-09-161-0/+7
| | | | | | | | | It looks like it was possible to attach it to both for a long time, however since llvm r217548 attaching it to just the pass manager is no longer sufficient and causes bugs (see http://llvm.org/bugs/show_bug.cgi?id=20903). Tested-by: Vinson Lee <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: handle SAMPLE opcode in aos samplingRoland Scheidegger2014-09-162-13/+50
| | | | | | | | | | | This is just a very limited version, in particular sampler and sampler view index must be the same. It cannot handle any modifiers neither. Works much the same as soa version otherwise, to figure out the target we need to store the sampler view dcls. While here, also handle (no-op) RET and get rid of a couple bogus deprecated comments. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) don't try to use rcp when the division 1/x is integerRoland Scheidegger2014-09-091-1/+1
| | | | | | | | This would just crash. Noticed by accident while checking int divisions by zero with a quickly hacked piglit test. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) fix min / max variable namesRoland Scheidegger2014-09-091-8/+8
| | | | | | | | Calling the variable min when it's really max and vice versa seems a bit confusing. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Fix Altivec pack intrinsics for little-endianUlrich Weigand2014-09-061-5/+21
| | | | | | | | | | | | | | | | | | | | This patch fixes use of Altivec pack intrinsics on little-endian PowerPC systems. Since little-endian operation only affects the load and store instructions, the semantics of pack (and other) instructions that take two input vectors implicitly change: the pack instructions still fill a register placing values from the first operand into the "high" parts of the register, and values from the second operand into the "low" parts of the register, but since vector loads and stores perform an endian swap, the high parts end up at high memory addresses. To still achieve the desired effect, we have to swap the two inputs to the pack instruction on little-endian systems. This is done automatically by the back-end for instructions generated by LLVM, but needs to be done manually when emitting intrisincs (which still result in that instruction being emitted directly). Signed-off-by: Ulrich Weigand <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]>
* gallivm: Fix build against LLVM SVN >= r216982Michel Dänzer2014-09-032-0/+11
| | | | | | | Only MCJIT is available anymore. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Michel Dänzer <[email protected]>
* gallivm: fix somewhat broken NaN behavior for exp2Roland Scheidegger2014-08-302-13/+25
| | | | | | | | | | | I actually screwed that up in 754319490f6946a9ad5ee619822d5fe4254e6759, mistakenly thinking the code actually wanted the non-nan result before. So, introduce that missing nan behavior case and use that instead. For sse, there's no actual change in the resulting code at all, the fallback code wouldn't have done the right thing though. Of course, the actual issue I saw with pow() was completely unrelated... Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: handle cube map arrays for texture samplingRoland Scheidegger2014-08-305-44/+107
| | | | | | | | | | | | | | | Pretty easy, just make sure that all paths testing for PIPE_TEXTURE_CUBE also recognize PIPE_TEXTURE_CUBE_ARRAY, and add the layer * 6 calculation to the calculated face. Also handle it for texture size query, looks like OpenGL wants the number of cubes, not layers (so need division by 6). No piglit regressions. v2: fix up adding cube layer to face for seamless filtering (needs to happen after calculating per-sample face). Undetected by piglit unfortunately. Reviewed-by: Jose Fonseca <[email protected]> (v1)
* gallivm: Fix build with LLVM >= 3.6 r215967.Vinson Lee2014-08-201-0/+4
| | | | | | | | | | | | | | | This LLVM 3.6 commit changed EngineBuilder constructor. commit 3f4ed32b4398eaf4fe0080d8001ba01e6c2f43c8 Author: Rafael Espindola <[email protected]> Date: Tue Aug 19 04:04:25 2014 +0000 Make it explicit that ExecutionEngine takes ownership of the modules. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215967 91177308-0d34-0410-b5e6-96231b3b80d8 Signed-off-by: Vinson Lee <[email protected]> Reviewed-and-Tested-by: Michel Dänzer <[email protected]>
* gallium: remove PIPE_SHADER_CAP_MAX_ADDRSMarek Olšák2014-08-111-2/+0
| | | | | | | | | | | | | | | This limit is fixed in Mesa core and cannot be changed. It only affects ARB_vertex_program and ARB_fragment_program. The minimum value for ARB_vertex_program is 1 according to the spec. The maximum value for ARB_vertex_program is limited to 1 by Mesa core. The value should be zero for ARB_fragment_program, because it doesn't support ARL. Finally, drivers shouldn't mess with these values arbitrarily. Reviewed-by: Ilia Mirkin <[email protected]>
* gallivm: Handle MSAA textures in emit_fetch_texelsDarius Goad2014-08-081-2/+7
| | | | | | | | | | | | This support is preliminary due to the fact that MSAA is not actually implemented. However, this patch does fix the piglit test: spec/!OpenGL 3.2/glsl-resource-not-bound 2DMS (bug #79740). (v2 RS: don't emit 4th coord as explicit lod) Reviewed-by: Roland Scheidegger <[email protected]>
* draw: hack around weird primitive id input in gsRoland Scheidegger2014-08-081-0/+12
| | | | | | | | | | | | | | | | | | | | | | The distinction between system values and ordinary inputs is not very obvious in gallium - further fueled by the fact that they use the same semantic names. Still, if there's any value which imho really is a system value, it's the primitive id input into the gs (while earlier (tessleation) stages could read it, it is _always_ generated by the system). For some odd reason though (which I'd classify as a bug but seems too complicated to fix) the glsl compiler in mesa treats this as an ordinary varying, and everything else after that (including the state tracker and other drivers) just go along with that. But input fetching in gs for llvm based draw was definitely limited to the ordinary (2-dimensional) inputs so only worked with other state trackers, the code was also additionally relying on tgsi_scan_shader filling uses_primid correctly which did not happen neither (would set it only for all stages if it was a system value, but only set it for the fragment shader if it was an input value). This fixes piglit glsl-1.50-geometry-primitive-id-restart and primitive-id-in in llvmpipe. Reviewed-by: Brian Paul <[email protected]>
* gallivm: Fix build with latest LLVMJan Vesely2014-08-051-0/+8
| | | | | Signed-off-by: Jan Vesely <[email protected]> Reviewed-and-Tested-by: Michel Dänzer <[email protected]>
* gallivm: fix cube map array (and cube map shadow with bias) handlingRoland Scheidegger2014-08-052-29/+125
| | | | | | | | | | | In particular need to handle TEX2/TXB2/TXL2 opcodes. cube map shadow with bias already used TXB2 which didn't work before at all, despite that there's by default no piglit change (but using no_quad_lod and no_rho_opt indeed passes some more tex-miplevel-selection tests). The actual sampling code still won't handle cube map arrays. Reviewed-by: Brian Paul <[email protected]>
* gallivm: fix up out-of-bounds level when using conformant out-of-bound behaviorRoland Scheidegger2014-07-311-0/+1
| | | | | | | | | | | | | | | | | | | When using (d3d10) conformant out-of-bound behavior for texel fetching (currently always enabled) the level still needs to be set to a safe value even though the offset in the end won't get used because the level is used to look up the mip offset itself and the actual strides, which might otherwise crash. For simplicity, we'll use level 0 in this case (this ought to be safe, llvmpipe does not actually fill in level 0 information if first_level is larger, but some random strides / offsets shouldn't hurt as ultimately we always use offset 0 in this case). Fixes a crash in some in-house test where random huge levels appear in lp_build_fetch_texel() (the test actually uses level 0 always but if the fetching happens in a block with a execution mask random values may appear). CC: <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallium: rename shader cap MAX_CONSTS to MAX_CONST_BUFFER_SIZEMarek Olšák2014-07-281-2/+2
| | | | | | | | | | This new name isn't so confusing. I also changed the gallivm limit, because it looked wrong. Reviewed-by: Brian Paul <[email protected]> v2: use sizeof(float[4])
* gallium: Add PIPE_SHADER_CAP_DOUBLESTom Stellard2014-07-021-0/+2
| | | | | | | This is for reporting whether or not double precision floating-point operations are supported. Reviewed-by: Francisco Jerez <[email protected]>
* gallivm: Fix build after LLVM commit 211259Aaron Watry2014-06-201-1/+3
| | | | | Signed-off-by: Aaron Watry <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* gallivm: set mcpu when initializing llvm execution engineRoland Scheidegger2014-06-191-2/+20
| | | | | | | | | | | | | | | Previously llvm detected cpu features automatically when the execution engine was created (based on host cpu). This is no longer the case, which meant llvm was then not able to emit some of the intrinsics we used as we didn't specify any sse attributes (only on avx supporting systems this was not a problem since despite at least some llvm versions enabling it anyway we always set this manually). So, instead of trying to figure out which MAttrs to set just set MCPU. This fixes https://bugs.freedesktop.org/show_bug.cgi?id=77493. Reviewed-by: Jose Fonseca <[email protected]> Tested-by: Vinson Lee <[email protected]>
* gallium: implement ARB_texture_query_levelsMarek Olšák2014-06-191-1/+1
| | | | | | | | | The extension is always supported if GLSL 1.30 is supported. Softpipe and llvmpipe support is also added (trivial). Radeon and nouveau support is already done. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: fix SCALED -> NORM conversionsRoland Scheidegger2014-06-181-16/+23
| | | | | | | | | | | | | | | Such conversions (which are most likely rather pointless in practice) were resulting in shifts with negative shift counts and shifts with counts the same as the bit width. This was always undefined in llvm, the code generated was rather horrendous but happened to work. So make sure such shifts are filtered out and replaced with something that works (the generated code is still just as horrendous as before). This fixes lp_test_format, https://bugs.freedesktop.org/show_bug.cgi?id=73846. v2: prettify by using build context shift helpers. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Disable workaround for PR12833 on LLVM 3.2+.José Fonseca2014-05-231-2/+2
| | | | Fixed upstream.
* gallivm: Support MCJIT on Windows.José Fonseca2014-05-231-0/+9
| | | | | | | It works fine, though it requires using ELF objects. With this change there is nothing preventing us to switch exclusively to MCJIT, everywhere. It's still off though.
* llvmpipe: do IR counting for shader cache management after optimization.Roland Scheidegger2014-05-192-2/+20
| | | | | | | | | | | 2ea923cf571235dfe573c35c3f0d90f632bd86d8 had the side effect of IR counting now being done after IR optimization instead of before. Some quick analysis shows that there's roughly 1.5 times more IR instructions before optimization than after, hence the effective shader cache size got quite a bit smaller. Could counter this with an increase of the instruction limit but it probably makes more sense to count them after optimizations, so move that code. Reviewed-by: Brian Paul <[email protected]>
* gallivm: (trivial) fix compilation with llvm 3.1, 3.2Roland Scheidegger2014-05-171-0/+4
| | | | | | I actually checked the getModuleIdentifier() function exists with 3.1 but missed that the file moved... This fixes https://bugs.freedesktop.org/show_bug.cgi?id=78803
* gallivm: print out how long it takes to optimize shader IR.Roland Scheidegger2014-05-163-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enabled with GALLIVM_DEBUG=perf (which up to now was only used to print warnings for unoptimized code). While some unexpectedly long shader compile times for some shaders were fixed with 8a9f5ecdb116d0449d63f7b94efbfa8b205d826f this should help recognize such problems in the future. For now though only available in debug builds (which are not always suitable for such analysis). And since this uses system time, it might not be all that accurate (even llvmpipe's own rasterization threads might be running at the same time, or just other tasks). (llvmpipe also has LP_DEBUG=counters but this only gives an average per shader and the the total time for all shaders.) This prints information like this: optimizing module fs17_variant0 took 1 msec optimizing module setup_variant_0 took 0 msec optimizing module draw_llvm_vs_variant0 took 9 msec optimizing module draw_llvm_vs_variant0 took 12 msec optimizing module fs17_variant1 took 2 msec v2: rebase for recent gallivm compilation changes, and print time for whole modules instead of functions (otherwise it would be very spammy since it would include all trivial inline sse2 functions), using the shiny new module names, prying them off LLVM using new helper (not available through C bindings). Per function timings, while possibly giving more information (if there'd be a problem only in for instance the partial not the whole function), don't seem all that useful for now. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: give more verbose names to modulesRoland Scheidegger2014-05-162-6/+5
| | | | | | | | | When we had just one module "gallivm" was an appropriate name. But now we have modules containing all functions for a particular variant, so give it a corresponding name (this is really just for helping debugging). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: remove optimization workaround when not having sse 4.1Roland Scheidegger2014-05-161-8/+1
| | | | | | | | | | | This workaround doesn't list any llvm version, but it was introduced 2010-06-10 (e277d5c1f6b2c5a6d202561e67d2b6821a69ecc4). It is unlikely this bug is still present in llvm versions we support (3.1+). There's no specific test listed, but I ran lp_test_arit (which uses the mentioned functions) on llvm 3.1 and 3.3 with sse41 disabled and this pass enabled without issues. Reviewed-by: Jose Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 05:39:24 +0000