summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* llvmpipe: get rid of linear_img structRoland Scheidegger2014-07-024-33/+19
| | | | | | | Just use a tex_data pointer directly - the description was no longer correct neither. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: (trivial) rename linear_mip_offsets to mip_offsetsRoland Scheidegger2014-07-024-6/+6
| | | | | | | Since switching to non-swizzled rendering we only have "normal", aka linear, offsets. Reviewed-by: Brian Paul <[email protected]>
* gallium: add facilities for indirect drawingChristoph Bumiller2014-07-022-0/+8
| | | | | | v2: Added comments to util_draw_indirect, clarified and fixed map size. Removed unlikely().
* gallium: add a cap for max vertex streamsIlia Mirkin2014-07-011-0/+2
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add an index argument to create_queryIlia Mirkin2014-07-011-1/+2
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Fix zero-division in llvmpipe_texture_layout()Takashi Iwai2014-06-251-1/+1
| | | | | | | | | | | Fix the crash of "gnome-control-center info" invocation on QEMU where zero height is passed at init. (sroland: simplify logic by eliminating the div altogether, using 64bit mul.) Fixes: https://bugzilla.novell.com/show_bug.cgi?id=879462 Cc: "10.2" <[email protected]>
* llvmpipe: increase number of queries which can be binned simultaneously to 64Roland Scheidegger2014-06-131-1/+1
| | | | | | | | | | | Gallium (but not OpenGL) does allow nesting of queries, but there's no limit specified (d3d10 has no limit neither). Nevertheless, for practical purposes we need some limit in llvmpipe, otherwise we'd need more complex handling of queries as we need to keep track of all binned queries (this only affects queries which gather data past setup). A limit of 16 is too small though, while 64 would suffice. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: create TGSI_PROPERTY to disable viewport and clippingChristoph Bumiller2014-06-021-0/+1
| | | | | | Marek v2: add a cap Signed-off-by: Marek Olšák <[email protected]>
* llvmpipe: (trivial) drop "unswizzled" from some function namesRoland Scheidegger2014-05-312-28/+30
| | | | | | | This made sense when swizzled storage layout was used for rendering to tiles. But nowadays the name just adds confusion (and makes for long lines). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: fix crash when not all attachments are populated in a fbRoland Scheidegger2014-05-311-3/+9
| | | | | | | | | | | | Framebuffers can have NULL attachments since a while. llvmpipe handled that properly for lp_rast_shade_quads_mask but it seems the change didn't make it to lp_rast_shade_tile. This fixes piglit fbo-drawbuffers-none test (though I need to increase the FB_SIZE from 32 to 256 so the tris cover some tiles fully). https://bugs.freedesktop.org/show_bug.cgi?id=79421 Cc: "10.1 10.2" <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: honor the render_condition_enable bit in blits.Roland Scheidegger2014-05-311-0/+3
| | | | | | | This fixes piglit nv_conditional_render-blitframebuffer. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: do IR counting for shader cache management after optimization.Roland Scheidegger2014-05-191-2/+2
| | | | | | | | | | | 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: give more verbose names to modulesRoland Scheidegger2014-05-167-16/+21
| | | | | | | | | 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]>
* llvmpipe: improve setup shader names (for debugging)Roland Scheidegger2014-05-151-38/+40
| | | | | | | | | | | | | The setup shaders were composed of both a fs shader number and a variant number. But since they aren't tied to a particular fragment shader, the former was a fixed zero while the latter was also always zero because it was never assigned. So, similar to what the fs code does, use a ever increasing number to give it a more catchy name (unlike fragment shaders though where this number is for each explicitly created shader, we just use it for the implicitly created variants). And while here, fix whitespace a bit. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: kill off llvmpipe_variant_countRoland Scheidegger2014-05-154-20/+4
| | | | | | | Unused except it was increased for both fs and setup shader variants created. Probably some leftover from ages ago. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Delete unneeded LLVM stuff earlier.José Fonseca2014-05-147-34/+16
| | | | | | Same as Frank's change to draw module but for llvmpipe module. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm,draw,llvmpipe: Remove support for versions of LLVM prior to 3.1.José Fonseca2014-05-141-28/+0
| | | | | | | Older versions haven't been tested probably don't work anyway. But more importantly, code supporting it is hindering further work. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: change LP_MAX_SHADER_INSTRUCTIONS limit definition.Roland Scheidegger2014-05-081-1/+3
| | | | | | | | | | When the limit was changed to be defined in terms of LP_MAX_SHADER_VARIANTS (75f1fea14f524ef05e980d825fda3ae226ae2ffe) when it was increased, this inadvertently lowered the limit in some branches (that have a lower LP_MAX_SHADER_VARIANTS number) when merged. So, make sure the limit is always at least the number it once was. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: add a cap for supporting 4-offset TG4 opcodesIlia Mirkin2014-05-071-0/+1
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add basic support for ARB_sample_shadingIlia Mirkin2014-04-261-0/+1
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: fix clearing of individual color buffers in a fbRoland Scheidegger2014-04-256-163/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GL (3.0) allows you to clear individual color buffers in a fb. In fact for fbs containing both int and float/normalized color buffers this is required (because the clearing values are otherwise undefined if applied to all buffers). The gallium interface was changed a while ago, but llvmpipe ignored it (hence doing such individual clears always resulted in clearing all buffers, plus some assorted asserts due to the mixed fbs). So change the clear command to indicate the buffer to be cleared. Also, because indicating the buffer to be cleared would have made lp_rast_arg_cmd larger which is unacceptable (we're trying to shrink it some day) allocate the clear value in the scene and just pass a pointer. There's several advantages and disadvantages here: + clearing individual buffers works (we could also actually bin such clears now if they'd come through clear_render_target() if the surface is in the current fb, though we didn't do this before for the single rb case and still don't try). + since there's one clear per rb, we do the format conversion in setup rather than per bin. Aside from the (drop in the ocean...) performance advantage this means that clearing to very small values (that is, denormal when converted to the format) should work for small float (fp16 etc.) formats, as the util code couldn't handle it correctly before (because cpu denorms are disabled when executing the bin commands, screwing up the magic conversion and flushing the values to 0, though this was not verified). - there's some overhead for traditional old-style clear-all MRT cases, since there's one rast clear command per rb instead of one for all rbs. This fixes https://bugs.freedesktop.org/show_bug.cgi?id=76976. v2: get rid of the ugly manual memcpy stuff and just use union util_color. This is 32 bytes instead of 16 but as the allocation is per scene we can live with those additional 16 bytes (and the additional 128 bytes in the setup context), which makes the code much more obvious. Suggested by Brian. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: (trivial) use correct LP_MIN_VECTOR_ALIGN define for alignment.Roland Scheidegger2014-04-251-1/+1
| | | | | | Currently it's the same value. Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 10:27:29 +0000