aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/draw
Commit message (Collapse)AuthorAgeFilesLines
* 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.)
* draw: implement support for the VERTEXID_NOBASE and BASEVERTEX semantics.Roland Scheidegger2014-12-162-19/+35
| | | | | | This fixes 4 vertexid related piglit tests with llvmpipe due to switching behavior of vertexid to the one gl expects. (Won't fix non-llvm draw path since we don't get the basevertex currently.)
* draw: simplify prim id insertion in prim assemblerRoland Scheidegger2014-12-101-34/+5
| | | | | | | | | | | | | | | | | | Because all topologies are reduced to basic primitives (i.e. no strips, fans) and the vertices involved are all copied, there's no need for any elaborate decisions where to insert the prim id. The logic employed was correct for first provoking vertex, but didn't account at all for the last provoking vertex case. And since we now will get the right constant value even if the primitive type is later changed (for unfilled etc.) this is no longer required to pass certain tests (which were checking for prim_id == some const interpolated value so passing because both were wrong in the end). This is a bit overkill (3x4 values assigned in total even though it's really one scalar per prim...) but the code is now much easier and I don't need to add more cases for last provoking vertex. This fixes piglit primitive-id-no-gs-strip test. Reviewed-by: Jose Fonseca <[email protected]>
* draw: fix another decompose bug affecting constant interpolated attributesRoland Scheidegger2014-12-101-2/+1
| | | | | | | | | | | Previously the first provoking vertex convention would only be used if flatshading were enabled. No matter how I look at it that cannot be possibly correct. Maybe the code getting used was somewhat simpler that way at a time where there weren't constant interpolated attributes, only flatshading... (Note that all other places including the decomposition macros already do the same.) Reviewed-by: Jose Fonseca <[email protected]>
* draw: fix flatshade stage for constant interpolated valuesRoland Scheidegger2014-12-103-69/+126
| | | | | | | | | | | | | | | | | | | | This stage only worked for traditional old-school flatshading, it did ignore constant interpolated values and only handled colors, the code probably predates using of constant interpolated values in gallium. So fix this - the clip stage apparently did this a long time ago already. Unfortunately this also means the stage needs to be invoked when flatshading isn't enabled but some other prim changing stages are - for instance with fill mode line each of the 3 lines in a tri should get the same attribute value from the leading vertex in the original tri if interpolation is constant, which did not happen before Due to that, the stage is now run in more cases, even unnecessary ones. Could in theory skip it completely if there aren't any constant interpolated attributes (and rast->flatshade isn't set), but not sure it's worth bothering, as it looks kinda complicated getting this information in advance. No piglit change (doesn't really cover this directly). Reviewed-by: Jose Fonseca <[email protected]>
* draw: copy over prim id header in flatshade stage when emitting linesRoland Scheidegger2014-12-101-3/+6
| | | | | | | | | | Just like we do for tris (det shouldn't matter at this point, however can have flags for things like line stipple reset). No piglit change, it would fail line stippling tests if the flatshade stage were run, which will happen with the next commit. Reviewed-by: Jose Fonseca <[email protected]>
* draw: implement TGSI_PROPERTY_VS_WINDOW_SPACE_POSITIONMarek Olšák2014-12-097-10/+44
| | | | | | | Required by Nine. Tested with util_run_tests. It's added to softpipe, llvmpipe, and r300g/swtcl. Tested-by: David Heidelberg <[email protected]>
* draw: (trivial): remove double semicolonRoland Scheidegger2014-12-091-1/+1
|
* draw: use the prim type from prim_info not emit in passthrough emitRoland Scheidegger2014-12-061-2/+2
| | | | | | | | | | | | The prim assembler may change the prim type when injecting prim ids now, which isn't reflected by what's stored in emit. This looks brittle and potentially dangerous (it is not obvious if such prim type changes are really supported by pt emit, the prim type is actually also set in prepare which would then be different). This fixes piglit primitive-id-no-gs-first-vertex.shader_test. Reviewed-by: Jose Fonseca <[email protected]>
* draw: use correct output prim for non-adjacent topologies in prim assembler.Roland Scheidegger2014-12-061-4/+4
| | | | | | | | | | | | | | | | | The decomposition done in the prim assembler will turn tri fans into tris, but this wasn't reflected in the output prim type. Meaning with a tri fan with 6 verts input, the output was a tri fan with 12 vertices instead of a tri list with 12 vertices (not as bad as it sounds, since the additional tris created would all be degenerate since they'd all have two times vertex zero but still bogus). This is because the prim assembler is used if either the input topology is something with adjacency, or if prim id needs to be injected, and for the latter case topologies without adjacency can be converted to basic ones. Unfortunately decomposition here for inserting prim ids is necessary, at least for the indexed case where we can't just insert the prim id at the right place depending on provoking vertex. Reviewed-by: Jose Fonseca <[email protected]>
* draw: kill off unneded prim assembler code for handling adjacency vertsRoland Scheidegger2014-12-062-60/+0
| | | | | | | | The default macros when the adjacency macros aren't defined will already exactly do that (that is, drop the adjacent vertices and call the non-adjacent macro). Reviewed-by: Jose Fonseca <[email protected]>
* draw,gallivm,llvmpipe: Avoid implicit casts of 32-bit shifts to 64-bits.José Fonseca2014-11-261-2/+2
| | | | | | | | | Addresses MSVC warnings "result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)", which can often be symptom of bugs, but in these cases were all benign. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: allow LLVM use on non-SSE2 X86 cpusDavid Heidelberg2014-11-221-14/+1
| | | | | | | | | | | | | | | | This patch remove workaround related to LLVM < 3.2 bug. Original bug has been closed as fixed in 2011. At this moment gallium requires LLVM 3.3 (2013). LLVM has been tested without SSE2 support in commit ca70de9bd20bc4a11b2d2d368e0cc1f49527a947 and removed after requiring LLVM 3.3 in commit 013ff2fae13da41c2f5619c4698b0a7b5aa6a06d Original LLVM bug: http://llvm.org/bugs/show_bug.cgi?id=6960 Signed-off-by: David Heidelberg <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: fixes for vertex shaders outputting layer or viewport indexRoland Scheidegger2014-11-196-8/+15
| | | | | | | | | | Mostly add a couple cases so we don't just check gs for this. There's only one gotcha, the built-in vp transform in the llvm vs can't handle it (this would be fixable though non-trivial due to vp index being non-constant for the SoA outputs, but we don't use it if there's a gs neither - the whole clip/vp transform integration there is suboptimal). Reviewed-by: Jose Fonseca <[email protected]>
* draw: Fixed inline commentsAndres Gomez2014-11-182-2/+2
| | | | Reviewed-by: Brian Paul <[email protected]>
* gallivm: fix alignment issue for vertex data fetchRoland Scheidegger2014-11-181-0/+1
| | | | | | | | | | | | | | 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.
* draw: Make it more clear that *_jit_context points to pipe_viewport_state ↵José Fonseca2014-11-163-13/+13
| | | | | | structures. No change in behavior.
* draw: Fix breakage due to removal pipe_viewport_state::translate[3] and ↵José Fonseca2014-11-161-2/+6
| | | | | | | | scale[3]. Unfortunately no LLVM type was generated for pipe_viewport_state -- it was being treated as a single floating point array --, so llvmpipe (and any driver that relies on draw/llvm) got totally busted.
* gallium: remove unused pipe_viewport_state::translate[3] and scale[3]Marek Olšák2014-11-161-3/+1
| | | | Almost all drivers ignore them.
* tgsi: change tgsi_shader_info::properties to a one-dimensional arrayMarek Olšák2014-10-041-3/+3
| | | | | | Reviewed-by: Roland Scheidegger <[email protected]> v2: fix svga too
* tgsi: simplify shader properties in tgsi_shader_infoMarek Olšák2014-10-041-14/+9
| | | | Use an array of properties indexed by TGSI_PROPERTY_* definitions.
* llvmpipe: Reuse llvmpipes LLVMContext in the draw context.Mathias Fröhlich2014-09-304-8/+29
| | | | | | | | | | | 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-302-2/+15
| | | | | | | | | | | | This is one step to make llvmpipe thread safe as mandated by the OpenGL standard. Using the global LLVMContext is obviously a problem for that kind of use pattern. The patch introduces two LLVMContext instances that are private to an OpenGL context and used for all compiles. One is put into struct draw_llvm and the other one into struct llvmpipe_context. Reviewed-by: Jose Fonseca <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
* gallivm: More fallout from disabling with LLVM 3.6Michel Dänzer2014-09-262-4/+3
| | | | | | | | 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]>
* mesa: Replace IS_NEGATIVE(x) with x < 0.0f.Matt Turner2014-09-251-6/+2
| | | | | | | | I only made IS_NEGATIVE(x) use signbit in commit 0f3ba405 in an attempt to fix 54805, but it didn't help. We didn't use signbit on some platforms and instead defined it to x < 0.0f. Reviewed-by: Kenneth Graunke <[email protected]>
* draw: use new tgsi_transform inst/decl helpers in pstipple codeBrian Paul2014-09-221-68/+19
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* draw: use new tgsi_transform inst/decl helpers in aapoint codeBrian Paul2014-09-221-202/+54
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* draw: use new tgsi_transform inst/decl helpers in aaline codeBrian Paul2014-09-221-66/+21
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* draw: use tgsi transform prolog callback in polygon stipple codeBrian Paul2014-09-221-125/+110
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* draw: use tgsi transform prolog/epilog callbacks in AA line codeBrian Paul2014-09-221-90/+92
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* draw: use tgsi transform prolog/epilog callbacks in AA point codeBrian Paul2014-09-221-305/+316
| | | | | | This simplifies the code and makes it a little easier to understand. Reviewed-by: Charmaine Lee <[email protected]>
* draw: (trivial) remove duplicated linesRoland Scheidegger2014-09-181-12/+0
|
* draw: kill off bogus assertion in tgsi_fetch_gs_outputsRoland Scheidegger2014-08-301-3/+2
| | | | | | | | | | | | Not sure why it was there but it is definitely not an error if gs outputs are infs/nans. Besides, the outputs can be ints, in which case any small negative number asserted. This fixes piglit's texelFetch gs isamplerXX crashes with softpipe (down from 14 to 2). Bug https://bugs.freedesktop.org/show_bug.cgi?id=80012 Reviewed-by: Jose Fonseca <[email protected]>
* draw: remove fishy num_samplers/num_sampler_views check in llvm pathRoland Scheidegger2014-08-301-5/+1
| | | | | | | | | | | | | | | | | | | | This was meant for softpipe to not crash at some point if vertex texturing was used. It is, however, fishy because it uses values from draw_set_samplers/draw_set_sampler_views and not from the shader key. Albeit we should still in all cases actually generate a new shader if this changes (because the samplers and views themselves are in the key) I don't want to think again wondering if that's really correct in the future. Besides, at least today, it does not actually work for softpipe, as this was relying on softpipe not actually calling draw_set_samplers/sampler_views at all - I've verified it crashes regardless (if there were a tex instruction in the vs, which normally should not happen anyway). For drivers which do indeed not call these functions because they don't support vertex texturing at all (r300), this should still not crash because the static texture data is all zero, which causes the sampling functions to take an early out (same as is done if no texture is bound at the slot used for sampling - verified with hacked up softpipe). Reviewed-by: Jose Fonseca <[email protected]>
* draw: fix base instance handling in llvm pathRoland Scheidegger2014-08-283-10/+18
| | | | | | | | | | | | | 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]>
* draw: (trivial) use information about gs being present from variant keyRoland Scheidegger2014-08-091-5/+4
| | | | | | This is a purely cosmetic change. Reviewed-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 14:45:05 +0000