summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* llvmpipe: fix rast debugging outputDave Airlie2014-09-161-0/+11
| | | | | | | | The triangle_32_ rast functions never made it into the debug output, confused me for a few seconds. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* llvmpipe: Fix PIPE_FORMAT_Z32_FLOAT_S8X24_UINT handling for big-endian.Richard Sandiford2014-09-161-1/+2
| | | | | | | | | | | | | | | | | llvmpipe treats PIPE_FORMAT_Z32_FLOAT_S8X24_UINT as a bit of a special case, handling it as two 32-bit pieces rather than a single 64-bit block: /* 64bit d/s format is special already extracted 32 bits */ total_bits = format_desc->block.bits > 32 ? 32 : format_desc->block.bits; The format_desc describes the whole 64-bit block, so the z shift will be 32 for big-endian. But since we're accessing the z channel as a 32-bit value rather than a 64-bit value, we need to mask the shift with 31. Signed-off-by: Richard Sandiford <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallium: add a texture target to sampler view and a CAP to use itIlia Mirkin2014-09-121-0/+1
| | | | | | | | | | This allows a sampler view to have a different texture target than the underlying resource. This will be used to implement the type casting between 2d arrays and cube maps as specified in ARB_texture_view. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium/llvmpipe: ship all files in the tarballEmil Velikov2014-09-052-3/+35
| | | | | | | | | | | - include all headers in Makefile.sources - sort the list(s) - bundle the scons buildscript v2: Don't double include the test sources. Signed-off-by: Emil Velikov <[email protected]> Acked-by: Matt Turner <[email protected]>
* softpipe: handle vertex texture sampling when using llvm for drawRoland Scheidegger2014-08-302-2/+2
| | | | | | | | | | | | | Pretty trivial, just fill in the offsets and such. The implementation is near 100% copy and paste from llvmpipe. Should be useful for debugging. No piglit change when not using SOFTPIPE_USE_LLVM=1. Now that it can do the same tests with and without using llvm for vs/gs, with llvm more pass, the only things failing only with llvm seems to be edgeflags tests and vs/gs-pow-float-float (and for the latter I'm not convinced the zero tolerance it requires is somehow mandated by glsl). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: (trivial) enable cube map arraysRoland Scheidegger2014-08-301-1/+2
| | | | | | | | The code is all in place now so enable it. Seems to pass all relevant piglit tests (just like cube maps, some of the cube map array tests need GALLIVM_DEBUG=no_quad_lod,no_rho_approx) Reviewed-by: Jose Fonseca <[email protected]>
* gallium: add cap for MAX_VERTEX_ATTRIB_STRIDETimothy Arceri2014-08-271-0/+2
| | | | | Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: fix base instance handling in llvm pathRoland Scheidegger2014-08-281-1/+1
| | | | | | | | | | | | | The base instance needs to be passed to the jited function, otherwise the instanced data fetch will only work with the same start instance when the jit function was created (and baking that into the key instead is not a viable option). This fixes piglit arb_base_instance-drawarrays (modulo some unrelated core/compat context trouble I get for the test). And fix the pipe cap bit in llvmpipe for it now that it actually works (it already worked for softpipe). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: change LP_MAX_SHADER_INSTRUCTIONS definitionRoland Scheidegger2014-08-211-1/+1
| | | | | | | | | | | | | This change will double cache size for branches which have a lower LP_MAX_SHADER_VARIANTS limit (it will not do anything on master). The reason is that nowadays shaders tend to be quite a bit larger than they were (they were big when llvmpipe didn't have a fs loop, got much smaller with that loop, and since then have gradually increased quite a bit though still smaller than without the fs loop for various reasons - among them being d3d10 compliance, usage of 8-wide vectors, non-swizzled blend code). Thus effectively less shaders would be cached (unless they were very small and the variant limit was hit first). Also, since we're getting rid of the IR nowadays, the cached shaders shouldn't need all that much memory actually.
* llvmpipe/softpipe: enable ARB_conditional_render_invertedTobias Klausmann2014-08-191-1/+2
| | | | | | Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Tobias Klausmann <[email protected]>
* gallium: Add and handle PIPE_CAP_CONDITIONAL_RENDER_INVERTEDTobias Klausmann2014-08-191-0/+1
| | | | | | Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Tobias Klausmann <[email protected]>
* gallium/softpipe/llvmpipe: handle query_renderer capsEmil Velikov2014-08-151-0/+19
| | | | | | | | | | Both report 0xffffffff as both vendor and device id, and the maximum amount of system memory as video memory. v2: Use aux helper os_get_total_physical_memory(). Cc: Brian Paul <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* gallium: add opcodes/cap for fine derivative supportIlia Mirkin2014-08-141-0/+1
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> (v1) Reviewed-by: Roland Scheidegger <[email protected]> (v1) v2: Reuse opcode gaps as suggested by Marek
* softpipe,llvmpipe: mark BPTC formats as unsupportedIlia Mirkin2014-08-121-0/+5
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe/tests: automake: link against libmesautil.laEmil Velikov2014-08-051-5/+6
| | | | | | | Or the build will fail due to unresolved symbols. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* llvmpipe: implement support for cube map arraysRoland Scheidegger2014-08-055-4/+16
| | | | | | | | This just covers the resource side of things, not the actual sampling. Here things are trivial as cube map arrays are identical to 2d arrays in all respects. Reviewed-by: Brian Paul <[email protected]>
* gallium: Move sRGB <-> RGB handling to libmesautilJason Ekstrand2014-08-041-1/+1
| | | | | Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: don't store number of layers per levelRoland Scheidegger2014-08-012-78/+50
| | | | | | | | | | | | | | | | This could be recalculated, though it turns out the only use of it after resource allocation is for calculating whole resource size (for scene size accounting though that isn't quite ideal neither). Thus, instead just store the whole resource size and drop it (saving a couple bytes of storage per resource). It makes things simpler too. Note that for the accounting winsys resources always come back with size 0 but this is unchanged (we don't actually know the size in any case). Also reformat llvmpipe_texture_layout (drop unneded indentation). v2: adapt to previous changes. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: integrate memory allocation into llvmpipe_texture_layoutRoland Scheidegger2014-08-011-45/+29
| | | | | | | | | | | | | | | Seems pointless to just duplicate some of the calculations (the calculation of actual memory used compared to what was predicted in llvmpipe_texture_layout actually could have differed slightly in some cases due to different alignment rules used though this should have been of no consequence). v2: keep the previous mip alignment of MAX2(64, cacheline). This was added for ARB_map_buffer_alignment - I'm not convinced it's needed for textures, but it was supposed to be cleanup without functional change. Also replace div with 64bit mul / comparison. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: get rid of impossible code in alloc_image_dataRoland Scheidegger2014-08-011-26/+13
| | | | | | | Only used for non display target resources. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* dri: Add a new capabilities for drivers that can't share buffersGiovanni Campagna2014-07-301-1/+1
| | | | | | | | | | | | | | | | | | | The kms-dri swrast driver cannot share buffers using the GEM, so it must tell the loader to disable extensions relying on that, without disabling the image DRI extension altogether (which would prevent the loader from working at all). This requires a new gallium capability (which is queried on the pipe_screen and for swrast drivers it's forwarded to the winsys), and requires a new version of the DRI image extension. [Emil Velikov] - Rebased on top of gallium-dri megadrivers. - Drop PIPE_CAP_BUFFER_SHARE and sw_winsys::get_param hook. The can_share_buffer cap is set at InitScreen. We use a different InitScreen (and thus value for the cap) function for kms_dri, due to deeper differences originating from dri megadrivers. Signed-off-by: Emil Velikov <[email protected]>
* gallium: rename PIPE_CAP_TGSI_VS_LAYER to also have _VIEWPORTIlia Mirkin2014-07-031-1/+1
| | | | | | | | | Now that this cap is used to determine the availability of both, adjust its name to reflect the new reality. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: get rid of llvmpipe_get_texture_tile_linearRoland Scheidegger2014-07-023-107/+17
| | | | | | | | | | | | | | Because the layout is always linear this didn't really do much any longer - at some point this triggered per-tile swizzled->linear conversion. The x/y coords were ignored too. Apart from triggering conversion, this also invoked alloc_image_data(), which could only actually trigger mapping of display target resources. So, instead just call resource_map in the callers (which also gives the ability to unmap again). Note that mapping/unmapping of display target resources still isn't really all that clean (map/unmap may be unmatched, and all such mappings use the same pointer thus usage flags are a lie). Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: get rid of llvmpipe_get_texture_imageRoland Scheidegger2014-07-022-52/+1
| | | | | | | | The only caller left used it only for non display target textures, hence it was really the same as llvmpipe_get_texture_image_address - it also had a usage flag but this was ignored anyway. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: get rid of llvmpipe_get_texture_image_allRoland Scheidegger2014-07-024-65/+7
| | | | | | | | | | | Once used for invoking swizzled->linear conversion for all needed images. But we now have a single allocation for all images in a resource, thus looping through all slices is rather pointless, conversion doesn't happen neither. Also simplify the sampling setup code to use the mip_offsets array in the resource directly - if the (non display target) resource exists its memory will already be allocated as well. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: allocate regular texture memory upfrontRoland Scheidegger2014-07-021-0/+7
| | | | | | | | | | | The deferred allocation doesn't really make much sense anymore, since we no longer allocate swizzled/linear memory in chunks and not per level / slice neither. This means we could fail resource creation a bit more (could already fail in theory anyway) but should not fail maps later (right now, callers can't deal with neither really). Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 22:34:40 +0000