summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/draw
Commit message (Collapse)AuthorAgeFilesLines
* gallivm: Use standard LLVMSetAlignment from LLVM 3.4 onwards.Jose Fonseca2016-04-031-2/+2
| | | | | | | | | Only provide a fallback for LLVM 3.3. One less dependency on LLVM C++ interface. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: add support for passing images to vs/gs shaders.Dave Airlie2016-03-315-2/+29
| | | | | | | | This just adds support for passing through images to the tgsi execution stage. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* tgsi: add support for image operations to tgsi_exec. (v2.1)Dave Airlie2016-03-312-2/+2
| | | | | | | | | | | | This adds support for load/store/atomic operations on images along with image tracking support. v2: add RESQ support. (Ilia) v2.1: constify interface (Brian) split get_image_coord_dim (Brian) Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* tgsi: drop unused set_exec/kill_mask interfaces.Dave Airlie2016-03-222-12/+0
| | | | | | | | | These don't get used and haven't been in git history from what I can see, so drop them. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallium/tgsi: pass TGSI tex target to tgsi_transform_tex_inst()Brian Paul2016-03-211-5/+5
| | | | | | | Instead of hard-coded 2D tex target in tgsi_transform_tex_2d_inst() Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* draw: fix line stipplingRoland Scheidegger2016-03-151-15/+15
| | | | | | | | | | | | | | | | The logic was comparing actual ints, not true/false values. This meant that it was emitting always multiple line segments instead of just one even if the stipple test had the same result, which looks inefficient, and the segments also overlapped thus breaking line aa as well. (In practice, with the no-op default line stipple pattern, for a 10-pixel long line from 0-9 it was emitting 10 segments, with the individual segments ranging from 0-1, 0-2, 0-3 and so on.) This fixes https://bugs.freedesktop.org/show_bug.cgi?id=94193 Reviewed-by: Jose Fonseca <[email protected]> CC: <[email protected]>
* draw: use util_pstipple_* function for stipple pattern textures and samplersNicolai Hähnle2016-02-091-110/+11
| | | | | | | | This reduces code duplication. Suggested-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* draw: use util_pstipple_create_fragment_shaderNicolai Hähnle2016-02-091-197/+12
| | | | | | | | | This reduces code duplication. It also adds support for drivers where the fragment position is a system value. Suggested-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe,i915: add back NEW_RASTERIZER dependency when computing vertex infoRoland Scheidegger2016-01-211-0/+6
| | | | | | | | | | | | | | | | | | | | I removed this mistakenly in 2dbc20e45689e09766552517a74e2270e49817b5. I actually thought it should not be necessary and a piglit run didn't show any differences, but this shouldn't have been in there. draw_prepare_shader_outputs() is in fact dependent on NEW_RASTERIZER. The new polygon-mode-facing test indeed shows why this is necessary, there's lots of invalid reads and writes with valgrind (also crashes without valgrind), because the pre-pipeline vertex size doesn't match the post-pipeline vertex size (note this won't help much with stages which don't have the prepare hook which can grow the vertex size, in particular the wide point stage, but this isn't used by llvmpipe). The test still won't pass, of course, but it is only usage of uninitialized values now, which is much less dangerous... (Albeit I'm pretty sure for i915 it really is not needed anymore as it doesn't care about the extra outputs and doesn't call draw_prepare_shader_outputs().) Reviewed-by: Jose Fonseca <[email protected]>
* draw: fix key comparison with uninitialized valueRoland Scheidegger2016-01-132-6/+6
| | | | | | | | Discovered by accident, valgrind was complaining (could have possibly caused us to create redundant geometry shader variants). v2: convinced by Brian and Jose, just use memset for both gs and vs keys, just as easy and less error prone.
* draw: initialize prim header flags when clipping linesRoland Scheidegger2016-01-081-0/+2
| | | | | | | | | Otherwise, clipped lines would have undefined stippling reset bit if line stippling is enabled. (Untested, and I just assume copying over the bits from the original line is actually the right thing to do.) Reviewed-by: Jose Fonseca <[email protected]>
* draw: fix line stippling with unfilled primsRoland Scheidegger2016-01-081-18/+38
| | | | | | | | | | | | | The unfilled stage was not filling in the prim header, and the line stage then decided to reset the stipple counter or not based on the uninitialized data. This causes some failures in conform linestipple test (albeit quite randomly happening depending on environment). So fill in the prim header in the unfilled stage - I am not entirely sure if anybody really needs determinant after that stage, but there's at least later stages (wide line for instance) which copy over the determinant as well. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: nuke the interp parameter from vertex_infoRoland Scheidegger2016-01-071-16/+1
| | | | | | | | | | | | | draw emit couldn't care less what the interpolation mode is... This somehow looked like it would matter, all drivers more or less dutifully filled that in correctly. But this is only used for emit, if draw needs to know about interpolation mode (for clipping for instance) it will get that information from the vs anyway. softpipe actually used to depend on that interpolation parameter, as it abused that structure quite a bit but no longer. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]>
* draw: rework handling of non-existing outputs in emit codeRoland Scheidegger2016-01-073-23/+46
| | | | | | | | | | | | | Previously the code would just redirect requests for attributes which don't exist to use output 0. Rework this to output all zeros instead which seems more useful - in particular some extensions like ARB_fragment_layer_viewport require 0 in the fs even if it wasn't output by previous stages. That way, drivers don't have to special case this depending if the vs/gs outputs some attribute or not. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]>
* gallium: Remove unnecessary semicolonsEdward O'Callaghan2016-01-061-1/+1
| | | | | | | | | Fix silly issue with MSVC case fall-though support to need a extra 'break;' Found-by: Coccinelle Signed-off-by: Edward O'Callaghan <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: minor indentation fixBrian Paul2016-01-051-1/+1
|
* draw: fix clip test with NaNsRoland Scheidegger2015-12-182-14/+18
| | | | | | | | | | | | | | | | NaNs mean it should be clipped, otherwise the NaNs might get passed to the next stages (if clipping didn't happen for another reason already), which might cause all kind of problems. The llvm path got this right already (possibly by luck), but this isn't used when there's a gs active. Found by code inspection, verified with some hacked piglit test and some more hacked debug output. (Note the clipper can still itself incorrectly generate NaN and INF position values in its output prims (at least after w divide / viewport transform) even if the inputs weren't NaNs, if the position data of the vertices is "sufficiently bad".) Reviewed-by: Brian Paul <[email protected]>
* draw: fix pstipple and aaline stages wrt sampler_views/samplersRoland Scheidegger2015-12-182-7/+9
| | | | | | | | | | | | | | Those stages only really work for OGL-style texturing (so number of samplers and views mostly the same, certainly for the max values). These get often set up all at once, thus there might be max number of both even if all of them are just NULL. We must not set the max number of samplers and views to the same value since that will lead to terrible things if a driver supports more views than samplers (and the state tracker set up all the views). (This will not make these stages magically work if a shader uses dx10-style texturing, they might still replace an actually used sview in that case.) Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* draw: handle edge flags in llvm pathRoland Scheidegger2015-12-162-26/+61
| | | | | | | | | | | | | We just ignored them altogether. While this feature is rather old-fashioned supporting it is actually rather trivial. This fixes the associated piglit tests (2 gl-1.0-edgeflag, 2 gl-2.0-edgeflag and all (7) of point-vertex-id). v2: comment fixes, and make the use of the edgeflag in clipmask consistent with when it's actually there (should be impossible to hit a case where the difference would actually matter but still...) Reviewed-by: Brian Paul <[email protected]>
* draw: don't set start_instance and instance id for pt emitRoland Scheidegger2015-12-161-31/+31
| | | | | | | | | | | | This just adds confusion, these parameters are used when fetching vertices by translate, but certainly not when emitting hw vertices for drivers, they make no sense there (setting them has no consequences otherwise since there won't be any elements with instance_divisor set). So just set them to 0 (the draw_pipe_vbuf code for emitting vertices when the draw pipeline is run already does exactly that). Also while here do some whitespace cleanup. Reviewed-by: Brian Paul <[email protected]>
* draw: remove clip_vertex from vertex headerRoland Scheidegger2015-12-155-40/+54
| | | | | | | | | | | | | | | | | | vertex header had both clip_pos and clip_vertex. We only really need one (clip_pos) because the draw llvm shader would overwrite the position output from the vs with the viewport transformed. However, we don't really need the second one, which was only really used for gl_ClipVertex - if the shader didn't have that the values were just duplicated to both clip_pos and clip_vertex. So, just use this from the vs output instead when we actually need it. Also change clip debug to output both the data from clip_pos and the clipVertex output (if available). Makes some things more complex, some things less complex, but seems more easy to understand what clipping actually does (and what values it uses to do its magic). Reviewed-by: Brian Paul <[email protected] Reviewed-by: Jose Fonseca <[email protected]>
* draw: use clip_pos, not clip_vertex for the fake guardband xy point clippingRoland Scheidegger2015-12-151-3/+3
| | | | | | | | Seems obvious now this should use the data from position and not clip_vertex (albeit might not really make a difference). Reviewed-by: Brian Paul <[email protected] Reviewed-by: Jose Fonseca <[email protected]>
* draw: rename vertex header membersRoland Scheidegger2015-12-156-42/+46
| | | | | | | | | clip -> clip_vertex and pre_clip_pos -> clip_pos. Looks more obvious to me what these values actually represent (so use something resembling the vs output names). Reviewed-by: Brian Paul <[email protected] Reviewed-by: Jose Fonseca <[email protected]>
* draw: don't pretend have_clipdist is per-vertexRoland Scheidegger2015-12-155-18/+20
| | | | | | | | | | This is just for code cleanup, conceptually the have_clipdist really isn't per-vertex state, so don't put it there (just dependent on the shader). Even though there wasn't really any overhead associated with this, we shouldn't store random shader information in the vertex header. Reviewed-by: Brian Paul <[email protected] Reviewed-by: Jose Fonseca <[email protected]>
* draw: use position not clipVertex output for xyz view volume clippingRoland Scheidegger2015-12-151-1/+10
| | | | | | | | | | | I'm pretty sure this should use position (i.e. pre_clip_pos) and not the output from clipVertex. Albeit piglit doesn't care. It is what we use in the clip test, and it is what every other driver does (as they don't even have clipVertex output and lower the additional planes to clip distances). Reviewed-by: Brian Paul <[email protected] Reviewed-by: Jose Fonseca <[email protected]>
* draw: don't assume fixed offset for data in struct vertex_infoRoland Scheidegger2015-12-111-5/+3
| | | | | | Otherwise, if struct vertex_info is changed, you're in for some surprises... Reviewed-by: Jose Fonseca <[email protected]>
* draw: fix clipping with linear interpolated values and gl_ClipVertexRoland Scheidegger2015-12-111-4/+4
| | | | | | | | | | | | | | | | Discovered this when working on other clip code, apparently didn't work correctly - the combination of linear interpolated values and using gl_ClipVertex produced wrong values (failing all such combinations in piglits glsl-1.30 interpolation tests, named interpolation-noperspective-XXX-vertex). Use the pre-clip-pos values when determining the interpolation factor to fix this. Noone really understands this code well, but everybody agrees this looks sane... This fixes all those failing tests (10 in total) both with the llvm and non-llvm draw paths, with no piglit regressions. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* gallium: Remove redundant NULL ptr checksEdward O'Callaghan2015-12-061-2/+1
| | | | | Signed-off-by: Edward O'Callaghan <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* gallium/auxiliary: Sanitize NULL checks into canonical formEdward O'Callaghan2015-12-0623-35/+35
| | | | | | | | | | Use NULL tests of the form `if (ptr)' or `if (!ptr)'. They do not depend on the definition of the symbol NULL. Further, they provide the opportunity for the accidental assignment, are clear and succinct. Signed-off-by: Edward O'Callaghan <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* gallium/auxiliary: Trivial code style cleanupEdward O'Callaghan2015-12-062-2/+2
| | | | | Signed-off-by: Edward O'Callaghan <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* draw: fix clipping of layer/vp index outputsRoland Scheidegger2015-12-041-139/+186
| | | | | | | | | | | | | | | | | | | | | This was just plain broken. It used always the value from v0 (for vp_index) but would pass the value from the provoking vertex to later stages - but only if there was a corresponding fs input, otherwise the layer/vp index would get lost completely (as it would try to interpolate the (unsigned) values as floats). So, make it obey provoking vertex rules (drivers relying on draw will need to do the same). And make sure that the default interpolation mode (when no corresponding fs input is found) for them is constant. Also, change the code a bit so constant inputs aren't interpolated then copied over later. Fixes the new piglit test gl-layer-render-clipped. v2: more consistent whitespaces fixes for function defs, and more tab killing (overall still not quite right however). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: add cache for compressed texturesRoland Scheidegger2015-11-041-1/+4
| | | | | | | | | | | | | | | | | | | | | | compressed textures are very slow because decoding is rather complex (and because there's no jit code code to decode them too for non-technical reasons). Thus, add some texture cache which holds a couple of decoded blocks. Right now this handles only s3tc format albeit it could be extended to work with other formats rather trivially as long as the result of decode fits into 32bit per texel (ideally, rgtc actually would decode to more than 8 bits per channel, but even then making it work for it shouldn't be too difficult). This can improve performance noticeably but don't expect wonders (uncompressed is unsurprisingly still faster). It's also possible it might be slower in some cases (using nearest filtering for example or if there's otherwise not many cache hits, the cache is only direct mapped which isn't great). Also, actual decode of a block relies on util code, thus even though always full blocks are decoded it is done texel by texel - this could obviously benefit greatly from simd-optimized code decoding full blocks at once... Note the cache is per (raster) thread, and currently only used for fragment shaders. Reviewed-by: Jose Fonseca <[email protected]>
* draw: fix splitting of line loops (v2)Brian Paul2015-10-204-8/+32
| | | | | | | | | | | | | | | | | When the draw module splits long line loops, the sections are emitted as line strips. But the primitive type wasn't set correctly so each section was being drawn as a loop, introducing extra line segments. To fix this, we pass a new DRAW_LINE_LOOP_AS_STRIP flag to the run() function. The linear/elt_run() functions have to check for this flag and set their primitive type accordingly. No piglit regressions. Fixes piglit's lineloop with -count 4097 or higher. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174 Reviewed-by: Roland Scheidegger <[email protected]>
* tgsi: add negate parameter to tgsi_transform_kill_inst()Brian Paul2015-09-012-2/+4
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* gallium: replace INLINE with inlineIlia Mirkin2015-07-2126-56/+56
| | | | | | | | | | | | | | | | Generated by running: git grep -l INLINE src/gallium/ | xargs sed -i 's/\bINLINE\b/inline/g' git grep -l INLINE src/mesa/state_tracker/ | xargs sed -i 's/\bINLINE\b/inline/g' git checkout src/gallium/state_trackers/clover/Doxyfile and manual edits to src/gallium/include/pipe/p_compiler.h src/gallium/README.portability to remove mentions of the inline define. Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Marek Olšák <[email protected]>
* draw/gallivm: add invocation ID support for llvmpipe.Dave Airlie2015-06-233-3/+8
| | | | | | | This extends the draw code to add support for invocations. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* draw/tgsi: implement geom shader invocation support.Dave Airlie2015-06-232-18/+31
| | | | | | | | This is just for softpipe, llvmpipe won't work without some changes. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* draw: updates to support SVIEW declsRob Clark2015-06-212-2/+32
| | | | | | | | | | To allow for shaders which use SVIEW decls for TEX* instructions, we need to preserve the constraint that the shader either has no SVIEW's or it has one matching SVIEW for each SAMP. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* draw: (trivial) fix NULL pointer dereferenceRoland Scheidegger2015-06-051-2/+2
| | | | | | | | | | | This probably got broken when the samplers were converted to be indexed by shader type. Seen when looking at bug 89819 though I'm not sure if that really was what the bug was about... Cc: "10.5 10.6" <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: silence unused var warnings for non-debug buildBrian Paul2015-06-011-0/+4
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* draw: (trivial) fix out-of-bounds vector initializationRoland Scheidegger2015-05-061-1/+1
| | | | | | | | | | | | Was off-by-one. llvm says inserting an element with an index higher than the number of elements yields undefined results. Previously such inserts were ignored but as of llvm revision 235854 the vector gets replaced with undef, causing failures. This fixes piglit gl-3.2-layered-rendering-gl-layer, as mentioned in https://llvm.org/bugs/show_bug.cgi?id=23424. Reviewed-by: Brian Paul <[email protected]> Cc: [email protected]
* draw: fix prim ids when there's no gsRoland Scheidegger2015-04-233-2/+15
| | | | | | | | | | | | | | | We were resetting the prim id count for each run of the prim assembler, hence this only worked when the draw calls were very small (the exact limit depending on the vertex size), since larger draw calls get split up. So, do the same as we do already if there's a gs, reset it to zero explicitly for every new instance (this possibly could use the same variable but that isn't doable without some heavy refactoring and I'm not sure it makes sense). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90130. Reviewed-by: Jose Fonseca <[email protected]> CC: <[email protected]>
* draw: (trivial) don't print the shader twice with GALLIVM_DEBUG=tgsi (or ir)Roland Scheidegger2015-04-091-5/+5
| | | | | | | | Neither the shader nor the key change when doing elts or linear variant, so this was just annoying (probably mildly useful at some point when we printed the IR per function too). Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: don't use control flow when doing indirect constant buffer lookupsRoland Scheidegger2015-04-091-10/+18
| | | | | | | | | | | | | | | | | | | | | | | 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]>
* gallivm: simplify sampler interfaceRoland Scheidegger2015-03-311-25/+6
| | | | | | | | | | | | | | | | | | 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]>
* gallivm: pass jit_context pointer through to samplingRoland Scheidegger2015-03-273-20/+20
| | | | | | | | | | | | | | 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]>
* draw: fix division-by-zero for empty geometry shadersMarek Olšák2015-03-021-2/+5
| | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89372 Reviewed-by: Dave Airlie <[email protected]>
* gallium: Replace u_simple_list.h with util/simple_list.hEric Anholt2015-01-282-2/+2
| | | | | | | The code was exactly the same, except util/ has c++ guards and a struct simple_node declaration. Reviewed-by: Marek Olšák <[email protected]>
* draw: silence uninitialized variable warningBrian Paul2015-01-051-1/+1
| | | | | | v2: move initialization of llvm_gs to declaration. Reviewed-by: Roland Scheidegger <[email protected]>
* draw: revert using correct order for prim decomposition.Roland Scheidegger2014-12-171-1/+3
| | | | | | | | | This reverts db3dfcfe90a3d27e6020e0d3642f8ab0330e57be. The commit was correct but we've got some precision problems later in llvmpipe (or possibly in draw clip) due to the vertices coming in in different order, causing some internal test failures. So revert for now. (Will only affect drivers which actually support constant-interpolated attributes and not just flatshading.)
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 12:27:42 +0000