summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/draw
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* draw/llvm: reduce memory usageZack Rusin2014-04-245-20/+27
| | | | | | | | | | Lets make draw_get_option_use_llvm function available unconditionally and use it to avoid useless allocations when LLVM paths are active. TGSI machine is never used when we're using LLVM. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* draw: remove unused 'start' variable in draw_stats_clipper_primitives()Brian Paul2014-04-111-5/+2
| | | | | | It was computed, but never actually used. Reviewed-by: Ian Romanick <[email protected]>
* draw/llvm: improve debugging output a bitZack Rusin2014-03-261-1/+1
| | | | | | | | | | | it's useful to know what the llvmbuildstore arguments are going to be before executing it because it can crash and make sure to print out the inputs only if we're not generating a gs because it fetches inputs differently. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw/gs: reduce the size of the gs output bufferZack Rusin2014-03-261-7/+13
| | | | | | | | | | | | We used to overallocate the output buffer sometimes running out of memory with applications rendering large geometries. The actual maximum number of vertices out is simply the maximum number of primitives in (number of gs invocations) multiplied by the maximum number of output vertices per gs input primitive (i.e. gs invocation). Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: Duplicate TGSI tokens in draw_pipe_pstipple module.José Fonseca2014-03-251-1/+2
| | | | | | | | | As done in draw_pipe_aaline and draw_pipe_aapoint modules. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Cc: "10.0 10.1" <[email protected]>
* gallium: allow setting of the internal stream output offsetZack Rusin2014-03-073-7/+7
| | | | | | | | | | | | | | | | D3D10 allows setting of the internal offset of a buffer, which is in general only incremented via actual stream output writes. By allowing setting of the internal offset draw_auto is capable of rendering from buffers which have not been actually streamed out to. Our interface didn't allow. This change functionally shouldn't make any difference to OpenGL where instead of an append_bitmask you just get a real array where -1 means append (like in D3D) and 0 means do not append. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* draw/llvm: fix generation of the VS with GS presentZack Rusin2014-03-041-7/+7
| | | | | | | | | | | | | | | | | draw_current_shader_* functions return a final output when considering both the geometry shader and the vertex shader. But when code generating vertex shader we can not be using output slots from the geometry shader because, obviously, those can be completely different. This fixes a number of very non-obvious crashes. A side-effect of this bug was that sometimes the vertex shading code could save some random outputs as position/clip when the geometry shader was writing them and vertex shader had different outputs at those slots (sometimes writing garbage and sometimes something correct). Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Matthew McClure <[email protected]>
* draw: fix incorrect color of flat-shaded clipped linesBrian Paul2014-02-031-1/+12
| | | | | | | | | | | | When we clipped a line weren't copying the provoking vertex color to the second vertex. We also weren't checking for first vs. last provoking vertex. Fixes failures found with the new piglit line-flat-clip-color test. Cc: "10.0, 10.1" <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* draw: Save original driver functions earlier.José Fonseca2014-01-232-14/+14
| | | | | | | | Otherwise they will be NULL when stage destroy is invoked prematurely, (i.e, on out of memory). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: fix points with negative w coords for d3d style point clippingRoland Scheidegger2014-01-211-2/+6
| | | | | | | | | | | | | Even with depth clipping disabled, vertices which have negative w coords must be discarded. And since we don't have a proper guardband implementation yet (relying on driver to handle all values except infs/nans in rasterization for such points) we need to kill them off manually (as they can end up with coordinates inside viewport otherwise). v2: use 0.0f instead of 0 (spotted by Brian). Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: use some cast wrappers in draw_pt_fetch_shade_pipeline*.cBrian Paul2014-01-202-19/+29
| | | | Trivial.
* draw: whitespace and formatting fixes in draw_pt_fetch_shade_pipeline*.cBrian Paul2014-01-202-81/+105
| | | | Trivial.
* draw: fix incorrect vertex size computation in LLVM drawing codeBrian Paul2014-01-202-11/+30
| | | | | | | | | | | | | | We were calling draw_total_vs_outputs() too early. The call to draw_pt_emit_prepare() could result in the vertex size changing. So call draw_total_vs_outputs() after draw_pt_emit_prepare(). This fix would seem to be needed for the non-LLVM code as well, but it's not obvious. Instead, I added an assertion there to try to catch this problem if it were to occur there. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72926 Cc: 10.0 <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* draw: clean up d3d style point clippingRoland Scheidegger2014-01-205-25/+42
| | | | | | | | | | | | | | | | | | | | Instead of skipping x/y clipping completely if there's point_tri_clip points use guard band clipping. This should be easier (previously we could not disable generating the x/y bits in the clip mask for llvm path, hence requiring custom clip path), and it also allows us to enable this for tris-as-points more easily too (this would require custom tri clip filtering too otherwise). Moreover, some unexpected things could have happen if there's a NaN or just a huge number in some tri-turned-point, as the driver's rasterizer would need to deal with it and that might well lead to undefined behavior in typical rasterizers (which need to convert these numbers to fixed point). Using a guardband should hence be more robust, while "usually" guaranteeing the same results. (Only "usually" because unlike hw guardbands draw guardband is always just twice the vp size, hence small vp but large points could still lead to different results.) Unfortunately because the clipmask generated is completely unaffected by guard band clipping, we still need a custom clip stage for points (but not for tris, as the actual clipping there takes guard band into account). Reviewed-by: Jose Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 13:09:39 +0000