summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe
Commit message (Collapse)AuthorAgeFilesLines
* llvmpipe: simplify lp_resource_copy()Brian Paul2015-06-101-59/+2
| | | | | | | | | | Just implement it in terms of util_resource_copy_region(). Both the original code and util_resource_copy_region() boil down to mapping, calling util_copy_box() and unmapping. No piglit regressions. This will also help to implement GL_ARB_copy_image. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Implement stencil exportRoland Scheidegger2015-06-044-15/+21
| | | | | | | | | | | | | Pretty trivial, fixes the issue that we're expected to be able to blit stencil surfaces (as the blit just relies on util blitter code which needs stencil export to do it). 2 piglits skip->pass, 11 fail->pass v2: prettify, keep different stencil ref value handling out of depth/stencil test itself. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* llvmpipe: (trivial) add parantheses in (!x == y) expressionRoland Scheidegger2015-05-251-1/+1
| | | | | | | Apparently some compilers think we probably wanted to do !(x == y) instead and issue a warning, so just shut it up... No functional change, obviously. Cc: <[email protected]>
* gallium/drivers: Add extern "C" wrappers to public entryAlexander von Gluck IV2015-05-151-0/+8
| | | | Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: enable ARB_texture_viewRoland Scheidegger2015-05-133-9/+44
| | | | | | | | | | | | | | | All the functionality was pretty much there, just not tested. Trivially fix up the missing pieces (take target info from view not resource), and add some missing bits for cubes. Also add some minimal debug validation to detect uninitialized target values in the view... 49 new piglits, 47 pass, 2 fail (both related to fake multisampling, not texture_view itself). No other piglit changes. v2: move sampler view validation to sampler view creation, update docs. Reviewed-by: Brian Paul <[email protected]>
* gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERYMarek Olšák2015-05-121-0/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* gallium: make pipe_context::begin_query return a booleanSamuel Pitoiset2015-05-061-1/+2
| | | | | | | | | GL_AMD_performance_monitor must return an error when a monitoring session cannot be started. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Martin Peres <[email protected]>
* Fix a few typosZoë Blade2015-04-272-2/+2
| | | | Reviewed-by: Francisco Jerez <[email protected]>
* gallivm: don't use control flow when doing indirect constant buffer lookupsRoland Scheidegger2015-04-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | llvm goes crazy when doing that, using way more memory and time, though there's probably more to it - this points to a very much similar issue as fixed in 8a9f5ecdb116d0449d63f7b94efbfa8b205d826f. In any case I've seen a quite plain looking vertex shader with just ~50 simple tgsi instructions (but with a dozen or so such indirect constant buffer lookups) go from a terribly high ~440ms compile time (consuming 25MB of memory in the process) down to a still awful ~230ms and 13MB with this fix (with llvm 3.3), so there's still obvious improvements possible (but I have no clue why it's so slow...). The resulting shader is most likely also faster (certainly seemed so though I don't have any hard numbers as it may have been influenced by compile times) since generally fetching constants outside the buffer range is most likely an app error (that is we expect all indices to be valid). It is possible this fixes some mysterious vertex shader slowdowns we've seen ever since we are conforming to newer apis at least partially (the main draw loop also has similar looking conditionals which we probably could do without - if not for the fetch at least for the additional elts condition.) v2: use static vars for the fake bufs, minor code cleanups Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: enable ARB_texture_gatherRoland Scheidegger2015-03-311-2/+3
| | | | | | | | | | | | Just announce support for 4 components. While here also increase the max/min texel offsets (the limit is completely artificial, was chosen because that's what other hardware did, however there's other drivers using larger limits). Over a thousand little piglits skip->pass. v2: update docs/GL3.txt Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: simplify sampler interfaceRoland Scheidegger2015-03-311-26/+7
| | | | | | | | | | | | | | | | | | This has got a bit out of control with more and more parameters added. Worse, whenever something in there changes all callees have to be updated for that, even though they don't really do much with any parameter in there except pass it on to the actual sampling function. Hence simply put almost everything into a struct. Also instead of relying on some arguments being NULL, be explicit and set this in a key (which is just reused for function generation for simplicity). (The code still relies on them being NULL in the end for now.) Technically there is a minimal functional change here for shadow sampling: if shadow sampling is done is now determined explicitly by the texture function (either sample_c or the gl-style tex func inherit this from target) instead of the static texture state. These two should always match, however. Otherwise, it should generate all the same code. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: simplify address calculation for 4x4 blocksRoland Scheidegger2015-03-284-76/+35
| | | | | | | | | | | | | | These functions looked quite complicated, even though what they actually did was trivial (ever since we dropped swizzled rendering). Also drop lookup of format block per bytes done for each block, and do it once per scene instead. This improves everybody's favorite "benchmark" by 3% or so, though lp_rast_shade_quads_all() which calls this shows up still quite high for a function which does little more than call the jit function. (This would most likely be much better handled by the jit function itself, the strides are passed through anyway already, though for being able to handle layers it would definitely add some complexity.) Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: pass jit_context pointer through to samplingRoland Scheidegger2015-03-273-18/+19
| | | | | | | | | | | | | | The callbacks used for getting the dynamic texture/sampler state were using the jit_context from the generated jit function. This works just fine, however that way it's impossible to generate separate functions for texture sampling, as will be done in the next commit. Hence, pass this pointer through all interfaces so it can be passed to a separate function (technically, it would probably be possible to extract this pointer from the current function instead, but this feels hacky and would probably require some more hacks if we'd use real functions instead of inlining all shader functions at some point). There should be no difference in the generated code for now. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: implement get_device_vendor() for existing driversGiuseppe Bilotta2015-03-231-0/+1
| | | | | | | | | The only hackish ones are llvmpipe and softpipe, which currently return the same string as for get_vendor(), while ideally they should return the CPU vendor. Signed-off-by: Giuseppe Bilotta <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* llvmpipe: use global llvm context for PIPE_SUBSYSTEM_EMBEDDEDRoland Scheidegger2015-03-211-0/+11
| | | | | | | | | | | | | | | | | There's 2 reasons why we'd want to use the global context: 1) There still seems to be one memory "leak" left when using multiple llvm contexts (it is not a true leak as the memory disappears into some still addressable pool but nevertheless the memory consumption grows). See http://cgit.freedesktop.org/~jrfonseca/llvm-jitstress/ 2) These contexts get kinda big - even when disposing modules etc. after compiling a shader the LLVMContext can easily be over 100kB. So when there's lots of llvm contexts arounds it adds up. The downside is that at least right now this is absolutely not thread safe, so this only works safely in environments where multiple pipe contexts are not used concurrently. Reviewed-by: Jose Fonseca <[email protected]>
* scons: Use -Werror MSVC compatibility flags per-directory.Jose Fonseca2015-03-041-0/+2
| | | | | | Matching what we already do with autotools builds. Reviewed-by: Brian Paul <[email protected]>
* configure: Leverage gcc warn options to enable safe use of C99 features ↵Jose Fonseca2015-03-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | | where possible. The main objective of this change is to enable Linux developers to use more of C99 throughout Mesa, with confidence that the portions that need to be built with MSVC -- and only those portions --, stay portable. This is achieved by using the appropriate -Werror= options only on the places they need to be used. Unfortunately we still need MSVC 2008 on a few portions of the code (namely llvmpipe and its dependencies). I hope to eventually eliminate this so that we can use C99 everywhere, but there are technical/logistic challenges (specifically, newer Windows SDKs no longer bundle MSVC, instead require a full installation of Visual Studio, and that has hindered adoption of newer MSVC versions on our build processes.) Thankfully we have more directy control over our OpenGL driver, which is why we're now able to migrate to MSVC 2013 for most of the tree. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* Revert "configure: Leverage gcc warn options to enable safe use of C99 ↵Kenneth Graunke2015-02-271-4/+2
| | | | | | | | | features where possible." This reverts commit 79daa510c7a871a33797308a2ccb4b83a067ffbe. I apparently hadn't done a clean build when testing this; it broke the build for Tom, Ben, and myself. We like the idea; let's try a v2.
* configure: Leverage gcc warn options to enable safe use of C99 features ↵Jose Fonseca2015-02-271-2/+4
| | | | | | | | | | | | | | | | | | | | | | | where possible. The main objective of this change is to enable Linux developers to use more of C99 throughout Mesa, with confidence that the portions that need to be built with MSVC -- and only those portions --, stay portable. This is achieved by using the appropriate -Werror= options only on the places they need to be used. Unfortunately we still need MSVC 2008 on a few portions of the code (namely llvmpipe and its dependencies). I hope to eventually eliminate this so that we can use C99 everywhere, but there are technical/logistic challenges (specifically, newer Windows SDKs no longer bundle MSVC, instead require a full installation of Visual Studio, and that has hindered adoption of newer MSVC versions on our build processes.) Thankfully we have more directy control over our OpenGL driver, which is why we're now able to migrate to MSVC 2013 for most of the tree. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* llvmpipe,softpipe: only support ETC1, not the upcoming ETC2Ilia Mirkin2015-02-181-0/+4
| | | | Signed-off-by: Ilia Mirkin <[email protected]>
* gallium: add interface and state tracker support for GL_AMD_pinned_memoryMarek Olšák2015-02-171-0/+1
| | | | | | v2: add alignment restrictions to docs, fix indentation in headers Reviewed-by: Christian König <[email protected]>
* os,llvmpipe: Set rasterizer thread names on Linux.Jose Fonseca2015-02-131-1/+7
| | | | | | | | | | | To help identify llvmpipe rasterizer threads -- especially when there can be so many. We can eventually generalize this to other OSes, but for that we must restrict the function to be called from the current thread. See also http://stackoverflow.com/a/7989973 Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: Add MULTISAMPLE_Z_RESOLVE capAxel Davy2015-02-061-0/+2
| | | | | | | | | | | | | | | | Resolving a multisampled depth texture into a single sampled texture is supported on >= SM4.1 hw. It is possible some previous hw support it. The ability was tested on radeonsi and nvc0. Apparently is is also supported for radeon >= r700. This patch adds the MULTISAMPLE_Z_RESOLVE cap and add it to the drivers. It is advertised for drivers for which it is sure the ability is supported. Reviewed-by: Marek Olšák <[email protected]> Signed-off-by: Axel Davy <[email protected]>
* llvmpipe: Trivially advertise PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT.Jose Fonseca2015-02-051-1/+2
| | | | | | | | | | | Nothing special needs to be done. Even though llvmpipe copies constant (ie uniform) buffers internally, the application is supposed to flush and sync, so all should work. All bufferstorage piglit tests pass. Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add a cap to determine whether the driver supports offset_clampIlia Mirkin2015-02-021-0/+2
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Glenn Kennard <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: Replace u_simple_list.h with util/simple_list.hEric Anholt2015-01-285-5/+5
| | | | | | | The code was exactly the same, except util/ has c++ guards and a struct simple_node declaration. Reviewed-by: Marek Olšák <[email protected]>
* gallium: add TGSI_SEMANTIC_VERTEXID_NOBASE and TGSI_SEMANTIC_BASEVERTEXRoland Scheidegger2014-12-161-0/+2
| | | | | | | | | | | | | | | | | | | Plus a new PIPE_CAP_VERTEXID_NOBASE query. The idea is that drivers not supporting vertex ids with base vertex offset applied (so, only support d3d10-style vertex ids) will get such a d3d10-style vertex id instead - with the caveat they'll also need to handle the basevertex system value too (this follows what core mesa already does). Additionally, this is also useful for other state trackers (for instance llvmpipe / draw right now implement the d3d10 behavior on purpose, but with different semantics it can just do both). Doesn't do anything yet. And fix up the docs wrt similar values. v2: incorporate feedback from Brian and others, better names, better docs. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* draw: implement TGSI_PROPERTY_VS_WINDOW_SPACE_POSITIONMarek Olšák2014-12-091-0/+2
| | | | | | | Required by Nine. Tested with util_run_tests. It's added to softpipe, llvmpipe, and r300g/swtcl. Tested-by: David Heidelberg <[email protected]>
* llvmpipe: decrease MAX_SCENES from 2 to 1Roland Scheidegger2014-12-062-1/+13
| | | | | | | | | | | | | | | | | | Multiple scenes per context are meant to be used so a new scene can be built while another one is processed in rasterization. However, quite surprisingly, this does not actually work (and according to git log, possibly never did, though maybe it did at some point further back (5 years+) but was buggy) because we always wait immediately on the rasterizer to finish the scene when contexts (and hence setup/scene) is flushed. This means when we try to get an empty scene later, any old one is already empty again. Thus using multiple scenes is just a waste of memory (not too bad, since the additional scenes are guaranteed to be empty, which means their size ought to be one data block (64kB) plus the size of some structs), without actually really doing anything. (There is also quite some code for the whole concept of multiple scenes which doesn't really do much in practice, but keep it hoping the wait-on-scene-flush can be fixed some day.) Reviewed-by: Jose Fonseca <[email protected]>
* draw,gallivm,llvmpipe: Avoid implicit casts of 32-bit shifts to 64-bits.José Fonseca2014-11-262-6/+6
| | | | | | | | | 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]>
* llvmpipe: (trivial) remove redundant util_cpu_detect() call in lp_test_mainRoland Scheidegger2014-11-251-2/+0
| | | | Already called earlier.
* llvmpipe: fix lp_test_arit denorm handlingRoland Scheidegger2014-11-251-1/+37
| | | | | | | | | | | | | | | | | | llvmpipe disables denorms on purpose (on x86/sse only), because denorms are generally neither required nor desired for graphic apis (and in case of d3d10, they are forbidden). However, this caused some arithmetic tests using denorms to fail on some systems, because the reference did not generate the same results anymore. (It did not fail on all systems - behavior of these math functions is sort of undefined when called with non-standard floating point mode, hence the result differing depending on implementation and in particular the sse capabilities.) So, for the reference, simply flush all (input/output) denorms manually to zero in this case. This fixes https://bugs.freedesktop.org/show_bug.cgi?id=67672. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: enable PIPE_CAP_TGSI_VS_LAYER_VIEWPORTRoland Scheidegger2014-11-191-0/+1
| | | | | | | | | | | | No changes required in the driver itself, all handled by draw. piglit results in a quick run: skip->pass 7 skip->fail 2 (The new failures in the ARB_fragment_layer_viewport group are expected, we fail the same if gs doesn't write these outputs regardless of the vs.) Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: fix alignment issue for vertex data fetchRoland Scheidegger2014-11-181-1/+2
| | | | | | | | | | | | | | 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.
* llvmpipe: Call pipe_thread_wait() on Linux.José Fonseca2014-11-131-0/+6
| | | | | | | To address http://lists.freedesktop.org/archives/mesa-dev/2014-November/070569.html In short, revert 706ad3b649e6a75fdac9dc9acc3caa9e6067b853 for non-Windows OSes.
* llvmpipe: Avoid deadlock when unloading opengl32.dllJosé Fonseca2014-11-071-2/+6
| | | | | | | | | | | | | | | | | | | | | | On Windows, DllMain calls and thread creation/destruction are serialized, so when llvmpipe is destroyed from DllMain waiting for the rasterizer threads to finish will deadlock. So, instead of waiting for rasterizer threads to have finished, simply wait for the rasterizer threads to notify they are just about to finish. Verified with this very simple program: #include <windows.h> int main() { HMODULE hModule = LoadLibraryA("opengl32.dll"); FreeLibrary(hModule); } Fixes https://bugs.freedesktop.org/show_bug.cgi?id=76252 Reviewed-by: Roland Scheidegger <[email protected]> Cc: 10.2 10.3 <[email protected]>
* llvmpipe: Ensure the packed input of the lp_test_format is aligned.José Fonseca2014-10-241-2/+10
| | | | | | | | Fixes: - https://bugs.freedesktop.org/show_bug.cgi?id=85377 - http://llvm.org/bugs/show_bug.cgi?id=21365 Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Flush stdout on lp_test_* unit tests.José Fonseca2014-10-242-0/+3
| | | | | | | So that the order of test messages and gallivm/llvmpipe debug output is preserved. Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: introduce PIPE_CAP_CLIP_HALFZ.Mathias Fröhlich2014-10-241-0/+2
| | | | | | | | | | | | In preparation of ARB_clip_control. Let the driver decide if it supports pipe_rasterizer_state::clip_halfz being set to true. v3: Initially enable on ilo. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]
* gallivm,llvmpipe,clover: Bump required LLVM version to 3.3.José Fonseca2014-10-232-14/+0
| | | | | | | | | | | | | | 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]>
* tgsi: change tgsi_shader_info::properties to a one-dimensional arrayMarek Olšák2014-10-041-2/+2
| | | | | | Reviewed-by: Roland Scheidegger <[email protected]> v2: fix svga too
* tgsi: remove some not so useful variables from tgsi_shader_infoMarek Olšák2014-10-041-1/+3
|
* tgsi: simplify shader properties in tgsi_shader_infoMarek Olšák2014-10-041-8/+2
| | | | Use an array of properties indexed by TGSI_PROPERTY_* definitions.
* llvmpipe: Add missing LLVMGetGlobalContext() arg in lp_test_format.c.Vinson Lee2014-09-301-1/+1
| | | | | | | | | | | | | | | | | | Fix build error introduced with commit eedbce9c63a3f385908bdc8a69e8be98dd3522ff. lp_test_format.c: In function ‘test_format_unorm8’: lp_test_format.c:226:4: error: too few arguments to function ‘gallivm_create’ gallivm = gallivm_create("test_module_unorm8"); ^ In file included from ../../../../src/gallium/auxiliary/gallivm/lp_bld_format.h:38:0, from lp_test_format.c:42: ../../../../src/gallium/auxiliary/gallivm/lp_bld_init.h:58:1: note: declared here gallivm_create(const char *name, LLVMContextRef context); ^ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84538 Signed-off-by: Vinson Lee <[email protected]>
* llvmpipe: Reuse llvmpipes LLVMContext in the draw context.Mathias Fröhlich2014-09-301-1/+2
| | | | | | | | | | | Reuse the LLVMContext already allocated in llvmpipe_context for draw_llvm if ppossible. This should decrease the memory footprint of an llvmpipe context. v2: Fix compile with llvm disabled. 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-309-7/+17
| | | | | | | | | | | | 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]>
* llvmpipe: move lp_jit_screen_init() call after allocation of screen objectBrian Paul2014-09-301-3/+5
| | | | | | | | | The screen argument isn't actually used by lp_jit_screen_init() at this time, but let's move the call so that we pass a valid pointer. v2: don't leak screen if lp_jit_screen_init() fails. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: remove special case for PIPE_TEXTURE_CUBE in llvmpipe_texture_layout()Brian Paul2014-09-301-3/+6
| | | | | | | layers (aka array_size) should be 6 for cube textures so we don't need to special-case it. But add an assertion just to be safe. Reviewed-by: Ilia Mirkin <[email protected]>
* gallivm: More fallout from disabling with LLVM 3.6Michel Dänzer2014-09-264-7/+9
| | | | | | | | 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]>
* gallium/softpipe,llvmpipe: add automake target 'templates'Emil Velikov2014-09-241-0/+7
| | | | | | | | Rather than duplicating the libdeps, extra define... all over the targets, define them only once and use when applicable. Signed-off-by: Emil Velikov <[email protected]> Acked-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 00:59:31 +0000