aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/draw/draw_pipe_clip.c
Commit message (Collapse)AuthorAgeFilesLines
* draw: Avoid aliasing violations.Matt Turner2016-08-011-1/+2
| | | | Reviewed-by: Marek Olšák <[email protected]>
* draw: stop using CULLDIST semantic.Dave Airlie2016-05-231-1/+1
| | | | | | | | | | | The way the HW works doesn't really fit with having two semantics for this. The GLSL compiler emits 2 vec4s and two properties, this makes draw use those instead of CULLDIST semantics. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* 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: remove clip_vertex from vertex headerRoland Scheidegger2015-12-151-18/+49
| | | | | | | | | | | | | | | | | | 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-151-19/+19
| | | | | | | | | 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-151-3/+5
| | | | | | | | | | 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: 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/auxiliary: Sanitize NULL checks into canonical formEdward O'Callaghan2015-12-061-1/+1
| | | | | | | | | | 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]>
* 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]>
* gallium: replace INLINE with inlineIlia Mirkin2015-07-211-5/+5
| | | | | | | | | | | | | | | | 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: fix flatshade stage for constant interpolated valuesRoland Scheidegger2014-12-101-6/+7
| | | | | | | | | | | | | | | | | | | | 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]>
* 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: 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: 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: clean up d3d style point clippingRoland Scheidegger2014-01-201-10/+24
| | | | | | | | | | | | | | | | | | | | 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]>
* s/Tungsten Graphics/VMware/José Fonseca2014-01-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tungsten Graphics Inc. was acquired by VMware Inc. in 2008. Leaving the old copyright name is creating unnecessary confusion, hence this change. This was the sed script I used: $ cat tg2vmw.sed # Run as: # # git reset --hard HEAD && find include scons src -type f -not -name 'sed*' -print0 | xargs -0 sed -i -f tg2vmw.sed # # Rename copyrights s/Tungsten Gra\(ph\|hp\)ics,\? [iI]nc\.\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./g /Copyright/s/Tungsten Graphics\(,\? [iI]nc\.\)\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./ s/TUNGSTEN GRAPHICS/VMWARE/g # Rename emails s/[email protected]/[email protected]/ s/[email protected]/[email protected]/g s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/ s/jrfonseca\[email protected]/[email protected]/g s/keithw\[email protected]/[email protected]/g s/[email protected]/[email protected]/g s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/ s/[email protected]/[email protected]/ # Remove dead links s@Tungsten Graphics (http://www.tungstengraphics.com)@Tungsten Graphics@g # C string src/gallium/state_trackers/vega/api_misc.c s/"Tungsten Graphics, Inc"/"VMware, Inc"/ Reviewed-by: Brian Paul <[email protected]>
* gallium: add bits for clipping points as tris (d3d-style)Roland Scheidegger2014-01-171-3/+28
| | | | | | | | | | | | | | | | | | | | | | OpenGL does whole-point clipping, that is a large point is either fully clipped or fully unclipped (the latter means it may extend beyond the viewport as long as the center is inside the viewport). d3d9 (d3d10 has no large points) however requires points to be clipped after they are expanded to a rectangle. (Note some IHVs are known to ignore GL rules at least with some hw/drivers.) Hence add a rasterizer bit indicating which way points should be clipped (some drivers probably will always ignore this), and add the draw interaction this requires. Drivers wanting to support this and using draw must support large points on their own as draw doesn't implement vp clipping on the expanded points (it potentially could but the complexity doesn't seem warranted), and the driver needs to do viewport scissoring on such points. Conflicts: src/gallium/drivers/llvmpipe/lp_context.c src/gallium/drivers/llvmpipe/lp_state_derived.c Reviewed-by: Jose Fonseca <[email protected]>
* draw/clip: don't emit so many empty trianglesZack Rusin2013-09-251-0/+39
| | | | | | | | | | | | Compress empty triangles (don't emit more than one in a row) and never emit empty triangles if we already generated a triangle covering a non-null area. We can't skip all null-triangles because c_primitives expects ones that were generated from vertices exactly at the clipping-plane, to be emitted. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: handle nan clipdistanceZack Rusin2013-08-151-3/+12
| | | | | | | | If clipdistance for one of the vertices is nan (or inf) then the entire primitive should be discarded. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: make sure clipping works with injected outputsZack Rusin2013-08-021-35/+54
| | | | | | | | | | | | | clipping would drop the extra outputs because it always used the number of standard vertex shader outputs, without geometry shader or extra outputs. The commit makes sure that clipping with geometry shaders which have more outputs than the current vertex shader and with extra outputs correctly propagates the entire vertex. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* draw: make sure viewport index is fetched from leading vertexZack Rusin2013-05-251-14/+27
| | | | | | | | | | | | | Viewport index should only be used on a per primitive basis, so instead of fetching it from each vertex, potentially making each vertex in a primitive use a different viewport index, which is obviously broken, make sure that we only fetch from the first vertex in the primitive making the viewport index the same for the entire primtive. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca<[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: clamp the viewports to always be between 0 and maxZack Rusin2013-05-251-4/+4
| | | | | | | | | If the viewport index is larger than the PIPE_MAX_VIEWPORTS, then the first (0-th) viewport should be used. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca<[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: implement support for multiple viewportsZack Rusin2013-05-251-2/+9
| | | | | | | | | | | This adds support for multiple viewports to the draw module. Multiple viewports depend on the presence of geometry shaders which can write the viewport index. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca<[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: add const qualifier to silence compiler warningBrian Paul2013-03-071-1/+1
|
* draw: use geometry shader info in clip_init_state if appropriateBryan Cain2013-03-051-6/+9
| | | | | | Reviewed-by: Zack Rusin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* draw: fix non-perspective interpolation in interp()Brian Paul2013-02-191-3/+8
| | | | | | | | | | | This fixes a regression from ab74fee5e1a3fc3323b7238278637b232c2d0d95. When we use the clip coordinate to compute the screen-space interpolation factor, we need to first apply the divide-by-W step to the clip coordinate. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=60938 Note: This is a candidate for the 9.1 branch.
* draw: fix problem in screen-space interpolation clip codeBrian Paul2013-01-221-3/+3
| | | | | | | | | | | | | | | | | | I don't see how this could have ever worked right. The screen-space interpolation code uses the vertex->data[pos_attr] position which contain window coords. But window coords are only computed for the unclipped vertices; the clipped vertices have undefined window coords (see draw_cliptest_tmp.h). Use the vertex clip coords instead which are always defined. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=55476 (piglit fbo-blit-stretch failure on softpipe) Note: This is a candidate for the 9.0 branch. Reviewed-by: José Fonseca <[email protected]>
* draw: improve the clipper debug/printf codeBrian Paul2013-01-221-1/+20
| | | | Reviewed-by: José Fonseca <[email protected]>
* draw: Handle the case when there isn't a fragment shader.Olivier Galibert2012-06-221-10/+17
| | | | | Signed-off-by: Olivier Galibert <[email protected]> Signed-off-by: José Fonseca <[email protected]>
* draw: fix flat shading and screen-space linear interpolation in clipperOlivier Galibert2012-06-191-31/+113
| | | | | | | | | | | | | | | This includes: - picking up correctly which attributes are flatshaded and which are noperspective - copying the flatshaded attributes when needed, including the non-built-in ones - correctly interpolating the noperspective attributes in screen-space instead than in a 3d-correct fashion. Signed-off-by: Olivier Galibert <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* draw: Remove unused variables.Vinson Lee2012-01-281-4/+0
| | | | | | | | | | Fix this GCC warning. draw_pipe_clip.c: In function ‘interp’: draw_pipe_clip.c:122:13: warning: variable ‘clip_dist’ set but not used [-Wunused-but-set-variable] Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* draw: clipdistance support (v2)Dave Airlie2012-01-111-9/+33
| | | | | | | | | | Add support for using the clipdistance instead of clip plane. Passes all piglit clipdistance tests. v2: fixup some comments from Brian in review. Signed-off-by: Dave Airlie <[email protected]>
* draw/softpipe: add clip vertex support. (v2)Dave Airlie2012-01-111-3/+6
| | | | | | | | | | | | | | | | softpipe always clipped using the position vector, however for unclipped vertices it stored the position in window coordinates, however when position and clipping are separated, we need to store the clip-space position and the clip-space vertex clip, so we can interpolate both separately. This means we have to take the clip space position and store it to use later. This allows softpipe to pass all the clip-vertex piglit tests. v2: fix llvm draw regression, the structure being passed into llvm needed updating, remove some hardcoded ints that should have been enums while there. Signed-off-by: Dave Airlie <[email protected]>
* Gallium: remove unnecessary ifdef for MAX_CLIPPED_VERTICES.Paul Berry2011-09-201-2/+0
| | | | | | | | | | | draw_pipe_clip.c contained an ifdef to ensure that its local definition of MAX_CLIPPED_VERTICES would not take effect if the global MAX_CLIPPED_VERTICES (defined in src/mesa/main/config.h) was already defined. This was unnecessary because draw_pipe_clip.c doesn't directly or indirectly include src/mesa/main/config.h. Removed the ifdef to reduce confusion. Reviewed-by: Brian Paul <[email protected]>
* draw: fix edge flag handling in clipper (for unfilled tris/quads/polygons)Brian Paul2011-06-081-5/+57
| | | | | | | | | | | | | | | | | | | | Previously, we were errantly drawing some interior edges of clipped polygons and quads. Also, we were introducing extra edges where polygons intersected the view frustum clip planes. The main problem was that we were ignoring the edgeflags encoded in the primitive header's 'flags' field which are set during polygon/quad ->tri decomposition. We need to observe those during clipping. Since we can't modify the existing vert's edgeflag fields, we need to store them in a parallel array. Edge flags also need to be handled differently for view frustum planes vs. user-defined clip planes. In the former case we don't want to draw new clip edges but in the later case we do. This matches NVIDIA's behaviour and it just looks right. Finally, note that the LLVM draw code does not properly set vertex edge flags. It's OK on the regular software path though.
* draw: Prevent clipped vertices overflow.José Fonseca2010-09-231-1/+13
| | | | | | | | Some pathological triangles cause a theoritically impossible number of clipped vertices. The clipper will still assert, but at least release builds will not crash, while this problem is further investigated.
* draw: don't apply flatshading to clipped tris with <3 vertsKeith Whitwell2010-09-231-17/+18
| | | | | If a triangle was completely culled by clipping, we would still try to fix up its provoking vertex.
* draw: assorted clean-ups in clipper codeBrian Paul2010-07-291-20/+20
|
* draw: added new assertions to clipping codeBrian Paul2010-07-221-1/+10
|
* draw: handle some out of memory conditionsAlan Hourihane2010-06-161-3/+3
|
* gallium/draw: additional comments in the clipping codeBrian Paul2010-05-071-5/+10
|
* gallium: rework provoking vertex codeBrian Paul2010-05-051-14/+22
| | | | | | | | | | | | | | Builds on commit ddb0e18f6c5582d4d2cc59ffd16ad9c4639ed059 and fixes regressions in glean clipFlat test. We assume that Gallium drivers observe flatshade_first for all triangles and that all the assorted per-triangle calls in the 'draw' module also follow flatshade_first. Everything else builds on those rules. Gallium does not use follow flatshade_first for GL quads, quad strips and polygons; the "last" vertex is always the provoking vertex for those prims. So now there are separate QUAD_FIRST_PV and QUAD_LAST_PV macros in the draw primitive decomposition code instead of one QUAD macro.
* draw: Preserve the provoking vertex both when decomposing and clipping.José Fonseca2010-05-051-6/+23
| | | | Based on John Lawless' feedback.
* gallium/draw: s/clipper/clip_stage/ to be consistant with other stagesBrian Paul2010-01-131-9/+9
|
* gallium/draw: whitespace and commentsBrian Paul2010-01-131-7/+9
|
* gallium/draw: remove always-true conditionalBrian Paul2010-01-131-3/+1
|
* gallium: add geometry shader support to galliumZack Rusin2009-12-251-2/+2
|
* gallium/draw: add ability to print out active pipeline stagesKeith Whitwell2009-04-281-0/+1
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 16:20:38 +0000