aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/gallivm
Commit message (Collapse)AuthorAgeFilesLines
* gallium: Replace u_simple_list.h with util/simple_list.hEric Anholt2015-01-281-1/+1
| | | | | | | The code was exactly the same, except util/ has c++ guards and a struct simple_node declaration. Reviewed-by: Marek Olšák <[email protected]>
* gallivm: silence a couple compiler warningsBrian Paul2015-01-052-1/+4
| | | | | | | Silence warnings about possibly uninitialized variables when making a release build. Reviewed-by: José Fonseca <[email protected]>
* draw: implement support for the VERTEXID_NOBASE and BASEVERTEX semantics.Roland Scheidegger2014-12-162-0/+12
| | | | | | This fixes 4 vertexid related piglit tests with llvmpipe due to switching behavior of vertexid to the one gl expects. (Won't fix non-llvm draw path since we don't get the basevertex currently.)
* gallivm: Update for RTDyldMemoryManager becoming an unique_ptr.José Fonseca2014-12-031-0/+4
| | | | | | Trivial. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=86958
* gallivm: Removed unused variable.José Fonseca2014-11-261-1/+1
| | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw,gallivm,llvmpipe: Avoid implicit casts of 32-bit shifts to 64-bits.José Fonseca2014-11-262-2/+2
| | | | | | | | | Addresses MSVC warnings "result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)", which can often be symptom of bugs, but in these cases were all benign. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: Drop the unused CND opcode.Eric Anholt2014-11-242-28/+0
| | | | | | Nothing in the tree generates it. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Drop unused BRA opcode.Eric Anholt2014-11-242-7/+0
| | | | | | Never generated, and implemented in only nvfx vertprog. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Drop the unused SFL/STR opcodes.Eric Anholt2014-11-242-32/+0
| | | | | | Nothing generated them. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Drop the unused RFL opcode.Eric Anholt2014-11-241-3/+0
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Drop unused X2D opcode.Eric Anholt2014-11-242-7/+0
| | | | | | Nothing in the tree generates it. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Drop the unused ARA opcode.Eric Anholt2014-11-242-7/+0
| | | | | | | | Nothing in the tree generated it. v2: Only drop ARA, not ARR as well. Reviewed-by: Jose Fonseca <[email protected]> (v2)
* gallium: Drop the unused RCC opcode.Eric Anholt2014-11-242-6/+0
| | | | | | Nothing in the tree generated it. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Drop the NRM and NRM4 opcodes.Eric Anholt2014-11-242-100/+0
| | | | | | | They weren't generated in tree, and as far as I know all hardware had to lower it to a DP, RSQ, MUL. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: fix alignment issue for vertex data fetchRoland Scheidegger2014-11-187-13/+47
| | | | | | | | | | | | | | We cannot guarantee that vertex buffers have the necessary alignment for fetching all AoS members at once (for instance 4x32bit XYZW data). We can however guarantee that for textures. This did not cause errors for older llvm versions but it now matters and will cause segfaults if the data happens to not be aligned. Thus we need to set alignment manually. (Note that we can't actually really guarantee data to be even element aligned due to offsets in vertex buffers being bytes and OpenGL allowing this, but it does not matter for x86 as alignment is only required for sse vectors - not sure what happens on other archs, however.) This fixes https://bugs.freedesktop.org/show_bug.cgi?id=85467.
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 02:05:30 +0000