summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/draw
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* draw: don't use clipvertex output if user plane clipping is disabledRoland Scheidegger2014-08-091-2/+2
| | | | | | | | | | The non-llvm path made sure that both clip and pre_clip_pos point to the data output by position, not clipvertex, if user based clipping is disabled. However, the llvm path did not, which apparently led to failures if gl_ClipVertex was written but user plane clipping not enabled (bug 80183). Why I have no idea really, but just make it match the non-llvm behavior... Reviewed-by: Brian Paul <[email protected]>
* draw: hack around weird primitive id input in gsRoland Scheidegger2014-08-081-2/+6
| | | | | | | | | | | | | | | | | | | | | | The distinction between system values and ordinary inputs is not very obvious in gallium - further fueled by the fact that they use the same semantic names. Still, if there's any value which imho really is a system value, it's the primitive id input into the gs (while earlier (tessleation) stages could read it, it is _always_ generated by the system). For some odd reason though (which I'd classify as a bug but seems too complicated to fix) the glsl compiler in mesa treats this as an ordinary varying, and everything else after that (including the state tracker and other drivers) just go along with that. But input fetching in gs for llvm based draw was definitely limited to the ordinary (2-dimensional) inputs so only worked with other state trackers, the code was also additionally relying on tgsi_scan_shader filling uses_primid correctly which did not happen neither (would set it only for all stages if it was a system value, but only set it for the fragment shader if it was an input value). This fixes piglit glsl-1.50-geometry-primitive-id-restart and primitive-id-in in llvmpipe. Reviewed-by: Brian Paul <[email protected]>
* draw: fix prim id float cast for non-llvm pathRoland Scheidegger2014-08-081-8/+4
| | | | | | | These values are always uints, casting them to floats does no good. Fixes piglit glsl-1.50-geometry-primitive-id-restart tests for softpipe. Reviewed-by: Brian Paul <[email protected]>
* draw: fix clipvertex trouble if position comes from gsRoland Scheidegger2014-08-061-1/+5
| | | | | | | | | | | | | | | If the vertex shader has no position but the gs has, the clipvertex output was -1 (because it's the same as vs position in this case if there's no explicit clipvertex output). This caused crashes (or assertion failures) in clipping since in the end position (which came from gs) was different from cv (-1) and we then tried to use the bogus cv input. Rather than just test for -1 cv value in clipping, make it explicitly return the position output of the gs instead which seems cleaner (since we really don't want to use the clipvertex value from the vs (it could be a valid value in the (unsupported) case of vs writing clipvertex but still using a gs). This fixes piglit shader_runner clip-distance-out-values.shader_test. Reviewed-by: Zack Rusin <[email protected]>
* draw: don't run pipeline stages when gs has no position outputRoland Scheidegger2014-08-062-1/+5
| | | | | | | | | | | | | | | | The clip stage may crash if there's no position output, for this reason code was added to avoid running the pipeline stages in this case (c7c7186045ec617c53f7899280cbe12e59503e4d). However, this failed to actually work when there was a geometry shader, since unlike the vertex shader it did not initialize the position output to -1, hence the code trying to detect this didn't trigger. So simply initialize the position output to -1 just like the vs does. This fixes piglit glsl-1.50-transform-feedback-type-and-size (segfault->pass). clip-distance-out-values.shader_test goes from segfault to assertion failure, suggesting more fixes are needed, no other piglit changes. Reviewed-by: Dave Airlie <[email protected]> Reviewed-by: Zack Rusin <[email protected]>
* draw: (trivial) fix clamping of viewport indexRoland Scheidegger2014-06-241-1/+1
| | | | | | | | | | | | | | The old logic would let all negative values go through unclamped, with potentially disastrous results (probably trying to fetch viewport values from random memory locations). GL has undefined rendering for vp indices outside valid range but that's a bit too undefined... (The logic is now the same as in llvmpipe.) CC: "10.1 10.2" <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Tested-by: Ilia Mirkin <[email protected]>
* gallivm: give more verbose names to modulesRoland Scheidegger2014-05-161-4/+12
| | | | | | | | | 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]>
* draw: better llvm names for shaders for debugging.Roland Scheidegger2014-05-151-6/+12
| | | | | | | | All shaders had the same name. We could probably use some identifier per shader too, but for now only use the variant number. Reviewed-by: Jose Fonseca <[email protected]>
* draw: Delete unneeded LLVM stuff earlier.Frank Henigman2014-05-141-15/+4
| | | | | | | | | | Free up unneeded LLVM stuff immediately after generating vertex shader code. Saves about 500K per shader. v2: Don't bother calling gallivm_free_function (Jose) Signed-off-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm,draw,llvmpipe: Remove support for versions of LLVM prior to 3.1.José Fonseca2014-05-141-48/+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]>
* draw: do not use draw_get_option_use_llvm() inside draw execution pathsRoland Scheidegger2014-05-085-12/+12
| | | | | | | | | | | | | | 1c73e919a4b4dd79166d0633075990056f27fd28 made it possible to not allocate the tgsi machine if llvm was used. However, draw_get_option_use_llvm() is not reliable after draw context creation, since drivers can explicitly request a non-llvm draw context even if draw_get_option_use_llvm() would return true (and softpipe does just that) which leads to crashes. Thus use draw->llvm to determine if we're using llvm or not instead (and make draw->llvm available even if HAVE_LLVM is false so we don't have to put even more ifdefs). Cc: "10.2" <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: Prevent signed/unsigned comparisons.José Fonseca2014-05-021-1/+1
| | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 02:13:45 +0000