Re: [Mesa-dev] Expected wide line rendering with clipping
On Mon, Feb 9, 2015 at 12:35 PM, Roland Scheidegger wrote: > Am 09.02.2015 um 09:53 schrieb Iago Toral: >> On Fri, 2015-02-06 at 21:27 +0100, Roland Scheidegger wrote: >>> Am 06.02.2015 um 13:11 schrieb Iago Toral: Hi, Eduardo and I have been looking into a few dEQP test failures that deal with wide line rendering. There are a few of them that fail because of how clipping is implemented for this case. The problem in these cases seems to be that the hw renders the wide line as a parallelogram so that if an edge of the parallelogram is partially clipped, the other parallel edge will also be clipped at the same height/width so that the resulting wide line stays a parallelogram. The dEQP renders as if a wide line where a collection of 1px lines, so cliping one edge of the resulting line does not have implications for the other edge. This ASCII art illustrates the problem (* represent line pixels, | represents the viewport's rightmost edge): Expected by dEQP i965 rendering | | *| | **| | ***| | | | | | | | We can make the rendering result match dEQP's expectation by enabling the GuardBand in the clip stage (GEN6_CLIP_GB_TEST). This is being disabled by the driver for gen7 in this scenario because the underlying framebuffer surface is larger than the viewport, and per the comment in the code, in gen7 that would make it render beyond the viewport limits in that surface, while it notes that gen8 hw fixes this. So I guess that we do not want to do this in any case in gen7. Then, I have been reviewing the OpenGL specs to see if they clarify what should happen when clipping wide lines and I think the spec does not make a clear point, since when it talks about line clipping it does not cover the case of wide lines specifically: "13.5. PRIMITIVE CLIPPING ... If part of the line segment lies in the volume and part lies outside, then the line segment is clipped and new vertex coordinates are computed for one or both vertices. A clipped line segment endpoint lies on both the original line segment and the boundary of the clip volume. ... " The above description is clear for 1px lines, but where should the new vertex be generated exactly for wide lines, where many points could be at the boundary of the clip volume? Is any point valid? (that would mean the dEQP test is bogus because there are multiple accepted renderings), should the new vertex be exactly at the center of the line? (that would make both deqp and intel rendering bogus). Then there is also this comment in "14.5.2.2 Wide Lines" inside the non-AA line rasterization chapter: "Non-antialiased line segments of width other than one are rasterized by off-setting them in the minor direction (for an x-major line, the minor direction is y, and for a y-major line, the minor direction is x) and replicating fragments in the minor direction (see figure 14.3). Let w be the width rounded to the nearest integer (if w = 0, then it is as if w = 1). If the line segment has endpoints given by (x 0 , y 0 ) and (x 1 , y 1 ) in window coordinates, the segment with endpoints (x 0 , y 0 − (w − 1)/2) and (x 1 , y 1 − (w − 1)/2) is rasterized, but instead of a single fragment, a column of fragments of height w (a row of fragments of length w for a y-major segment) is produced at each x (y for y-major) location. The lowest fragment of this column is the fragment that would be produced by rasterizing the segment of width 1 with the modified coordinates." This "suggests" that wide line rendering should be equivalent to rendering multiple lines of width=1 and if we actually did that then the expected rendering result after clipping would be what dEQP expects. I think the whole thing isn't 100% clear. Does anyone have any thoughts on what should be considered correct behavior in this case? Iago >>> >>> I am quite sure that i965 rendering is what (at least legacy GL) >>> expects. This is because the wide-line expansion is defined to be >>> happening at rasterization time, i.e. past clipping. Thus, at clipping >>> time, no matter if a line is wide or not, it is still really a line, >>> hence clipping will produce a single new endpoint at the viewport edge >>> and in rasterization this is then what will be used as the endpoint. >> >> That makes sense, but in that case I think i965 rendering would still be >> incorrect, the expected result would look something like this: >> >>
Re: [Mesa-dev] Expected wide line rendering with clipping
Am 09.02.2015 um 09:53 schrieb Iago Toral: > On Fri, 2015-02-06 at 21:27 +0100, Roland Scheidegger wrote: >> Am 06.02.2015 um 13:11 schrieb Iago Toral: >>> Hi, >>> >>> Eduardo and I have been looking into a few dEQP test failures that deal >>> with wide line rendering. There are a few of them that fail because of >>> how clipping is implemented for this case. >>> >>> The problem in these cases seems to be that the hw renders the wide line >>> as a parallelogram so that if an edge of the parallelogram is partially >>> clipped, the other parallel edge will also be clipped at the same >>> height/width so that the resulting wide line stays a parallelogram. The >>> dEQP renders as if a wide line where a collection of 1px lines, so >>> cliping one edge of the resulting line does not have implications for >>> the other edge. >>> >>> This ASCII art illustrates the problem (* represent line pixels, | >>> represents the viewport's rightmost edge): >>> >>> Expected by dEQP i965 rendering >>> | | >>> *| | >>>**| | >>> ***| | >>> | | >>> | | >>> | | >>> >>> We can make the rendering result match dEQP's expectation by enabling >>> the GuardBand in the clip stage (GEN6_CLIP_GB_TEST). This is being >>> disabled by the driver for gen7 in this scenario because the underlying >>> framebuffer surface is larger than the viewport, and per the comment in >>> the code, in gen7 that would make it render beyond the viewport limits >>> in that surface, while it notes that gen8 hw fixes this. So I guess that >>> we do not want to do this in any case in gen7. >>> >>> Then, I have been reviewing the OpenGL specs to see if they clarify what >>> should happen when clipping wide lines and I think the spec does not >>> make a clear point, since when it talks about line clipping it does not >>> cover the case of wide lines specifically: >>> >>> "13.5. PRIMITIVE CLIPPING >>> ... >>> If part of the line segment lies in the volume and part lies outside, >>> then the line segment is clipped and new vertex coordinates are computed >>> for one or both vertices. A clipped line segment endpoint lies on both >>> the original line segment and the boundary of the clip volume. >>> ... >>> " >>> >>> The above description is clear for 1px lines, but where should the new >>> vertex be generated exactly for wide lines, where many points could be >>> at the boundary of the clip volume? Is any point valid? (that would mean >>> the dEQP test is bogus because there are multiple accepted renderings), >>> should the new vertex be exactly at the center of the line? (that would >>> make both deqp and intel rendering bogus). >>> >>> Then there is also this comment in "14.5.2.2 Wide Lines" inside the >>> non-AA line rasterization chapter: >>> >>> "Non-antialiased line segments of width other than one are rasterized by >>> off-setting them in the minor direction (for an x-major line, the minor >>> direction is y, and for a y-major line, the minor direction is x) and >>> replicating fragments in the minor direction (see figure 14.3). Let w be >>> the width rounded to the nearest integer (if w = 0, then it is as if w = >>> 1). If the line segment has endpoints given by (x 0 , y 0 ) and (x 1 , y >>> 1 ) in window coordinates, the segment with endpoints (x 0 , y 0 − (w − >>> 1)/2) and (x 1 , y 1 − (w − 1)/2) is rasterized, but instead of a single >>> fragment, a column of fragments of height w (a row of fragments of >>> length w for a y-major segment) is produced at each x (y for y-major) >>> location. The lowest fragment of this column is the fragment that would >>> be produced by rasterizing the segment of width 1 with the modified >>> coordinates." >>> >>> This "suggests" that wide line rendering should be equivalent to >>> rendering multiple lines of width=1 and if we actually did that then the >>> expected rendering result after clipping would be what dEQP expects. >>> >>> I think the whole thing isn't 100% clear. Does anyone have any thoughts >>> on what should be considered correct behavior in this case? >>> >>> Iago >>> >>> >> >> I am quite sure that i965 rendering is what (at least legacy GL) >> expects. This is because the wide-line expansion is defined to be >> happening at rasterization time, i.e. past clipping. Thus, at clipping >> time, no matter if a line is wide or not, it is still really a line, >> hence clipping will produce a single new endpoint at the viewport edge >> and in rasterization this is then what will be used as the endpoint. > > That makes sense, but in that case I think i965 rendering would still be > incorrect, the expected result would look something like this: > > | > | > **| >***| > | > | > | > > However, as far as I can tell, since i965 hardware renders wi
Re: [Mesa-dev] Expected wide line rendering with clipping
On Sat, 2015-02-07 at 13:41 +0100, Erik Faye-Lund wrote: > On Fri, Feb 6, 2015 at 1:11 PM, Iago Toral wrote: > > Hi, > > > > Eduardo and I have been looking into a few dEQP test failures that deal > > with wide line rendering. There are a few of them that fail because of > > how clipping is implemented for this case. > > > > The problem in these cases seems to be that the hw renders the wide line > > as a parallelogram so that if an edge of the parallelogram is partially > > clipped, the other parallel edge will also be clipped at the same > > height/width so that the resulting wide line stays a parallelogram. The > > dEQP renders as if a wide line where a collection of 1px lines, so > > cliping one edge of the resulting line does not have implications for > > the other edge. > > > > This ASCII art illustrates the problem (* represent line pixels, | > > represents the viewport's rightmost edge): > > > > Expected by dEQP i965 rendering > > | | > > *| | > >**| | > > ***| | > > | | > > | | > > | | > > Is that drawing correct? I would expect it to look like this: > > | | > *| | > **|**|** >***| ***|* > | | > | | > | | Yes, it is correct. Your expectation makes sense if things happen as Roland described (first we clip the 1px line, then we expand), but the result in i965 looks more like what you would obtain if you do it the other way around. As I mentioned in my response to Roland, I think i965 can't render what you expect (at least directly), the reason being that it renders wide lines as parallelograms instead of multiple 1px lines. > From the drawing, it looks like the line is exactly 45 degrees, so I > believe this particular case is actually undefined, because of the > following spec wording: Right, that was just my drawing. The dEQP test case renders an x-major line. > "Line segment rasterization begins by characterizing the segment as > either x-major or y-major. x-major line segments have slope in the > closed interval [−1, 1]; all other line segments are y-major (slope is > determined by the segment’s endpoints)." > > A 45 degree line should have a slope of 1, and should in theory be > identified as an x-major line, giving the result dEQP expects (i965 is > in this case rendering the line as similar to y-major, except y-major > rendering should also generate fragments outside the viewport, as > pointed out in my drawing above). However, since we're exactly at the > break-off point, previous calculations are allowed to be off by some > small value, leaving the characterization undefined. > > So I think in this case, both results are allowed, and the test is > therefore somewhat bogus. If the line was tilted a tiny amount so it's > guaranteed to be characterized as an x-major, then it should be > correct again. Not having access to the tests myself, they might > already have done this, though. > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Expected wide line rendering with clipping
On Fri, 2015-02-06 at 21:27 +0100, Roland Scheidegger wrote: > Am 06.02.2015 um 13:11 schrieb Iago Toral: > > Hi, > > > > Eduardo and I have been looking into a few dEQP test failures that deal > > with wide line rendering. There are a few of them that fail because of > > how clipping is implemented for this case. > > > > The problem in these cases seems to be that the hw renders the wide line > > as a parallelogram so that if an edge of the parallelogram is partially > > clipped, the other parallel edge will also be clipped at the same > > height/width so that the resulting wide line stays a parallelogram. The > > dEQP renders as if a wide line where a collection of 1px lines, so > > cliping one edge of the resulting line does not have implications for > > the other edge. > > > > This ASCII art illustrates the problem (* represent line pixels, | > > represents the viewport's rightmost edge): > > > > Expected by dEQP i965 rendering > > | | > > *| | > >**| | > > ***| | > > | | > > | | > > | | > > > > We can make the rendering result match dEQP's expectation by enabling > > the GuardBand in the clip stage (GEN6_CLIP_GB_TEST). This is being > > disabled by the driver for gen7 in this scenario because the underlying > > framebuffer surface is larger than the viewport, and per the comment in > > the code, in gen7 that would make it render beyond the viewport limits > > in that surface, while it notes that gen8 hw fixes this. So I guess that > > we do not want to do this in any case in gen7. > > > > Then, I have been reviewing the OpenGL specs to see if they clarify what > > should happen when clipping wide lines and I think the spec does not > > make a clear point, since when it talks about line clipping it does not > > cover the case of wide lines specifically: > > > > "13.5. PRIMITIVE CLIPPING > > ... > > If part of the line segment lies in the volume and part lies outside, > > then the line segment is clipped and new vertex coordinates are computed > > for one or both vertices. A clipped line segment endpoint lies on both > > the original line segment and the boundary of the clip volume. > > ... > > " > > > > The above description is clear for 1px lines, but where should the new > > vertex be generated exactly for wide lines, where many points could be > > at the boundary of the clip volume? Is any point valid? (that would mean > > the dEQP test is bogus because there are multiple accepted renderings), > > should the new vertex be exactly at the center of the line? (that would > > make both deqp and intel rendering bogus). > > > > Then there is also this comment in "14.5.2.2 Wide Lines" inside the > > non-AA line rasterization chapter: > > > > "Non-antialiased line segments of width other than one are rasterized by > > off-setting them in the minor direction (for an x-major line, the minor > > direction is y, and for a y-major line, the minor direction is x) and > > replicating fragments in the minor direction (see figure 14.3). Let w be > > the width rounded to the nearest integer (if w = 0, then it is as if w = > > 1). If the line segment has endpoints given by (x 0 , y 0 ) and (x 1 , y > > 1 ) in window coordinates, the segment with endpoints (x 0 , y 0 − (w − > > 1)/2) and (x 1 , y 1 − (w − 1)/2) is rasterized, but instead of a single > > fragment, a column of fragments of height w (a row of fragments of > > length w for a y-major segment) is produced at each x (y for y-major) > > location. The lowest fragment of this column is the fragment that would > > be produced by rasterizing the segment of width 1 with the modified > > coordinates." > > > > This "suggests" that wide line rendering should be equivalent to > > rendering multiple lines of width=1 and if we actually did that then the > > expected rendering result after clipping would be what dEQP expects. > > > > I think the whole thing isn't 100% clear. Does anyone have any thoughts > > on what should be considered correct behavior in this case? > > > > Iago > > > > > > I am quite sure that i965 rendering is what (at least legacy GL) > expects. This is because the wide-line expansion is defined to be > happening at rasterization time, i.e. past clipping. Thus, at clipping > time, no matter if a line is wide or not, it is still really a line, > hence clipping will produce a single new endpoint at the viewport edge > and in rasterization this is then what will be used as the endpoint. That makes sense, but in that case I think i965 rendering would still be incorrect, the expected result would look something like this: | | **| ***| | | | However, as far as I can tell, since i965 hardware renders wide lines as parallelograms, it can't render something like this
Re: [Mesa-dev] Expected wide line rendering with clipping
On Fri, Feb 6, 2015 at 1:11 PM, Iago Toral wrote: > Hi, > > Eduardo and I have been looking into a few dEQP test failures that deal > with wide line rendering. There are a few of them that fail because of > how clipping is implemented for this case. > > The problem in these cases seems to be that the hw renders the wide line > as a parallelogram so that if an edge of the parallelogram is partially > clipped, the other parallel edge will also be clipped at the same > height/width so that the resulting wide line stays a parallelogram. The > dEQP renders as if a wide line where a collection of 1px lines, so > cliping one edge of the resulting line does not have implications for > the other edge. > > This ASCII art illustrates the problem (* represent line pixels, | > represents the viewport's rightmost edge): > > Expected by dEQP i965 rendering > | | > *| | >**| | > ***| | > | | > | | > | | Is that drawing correct? I would expect it to look like this: | | *| | **|**|** ***| ***|* | | | | | | From the drawing, it looks like the line is exactly 45 degrees, so I believe this particular case is actually undefined, because of the following spec wording: "Line segment rasterization begins by characterizing the segment as either x-major or y-major. x-major line segments have slope in the closed interval [−1, 1]; all other line segments are y-major (slope is determined by the segment’s endpoints)." A 45 degree line should have a slope of 1, and should in theory be identified as an x-major line, giving the result dEQP expects (i965 is in this case rendering the line as similar to y-major, except y-major rendering should also generate fragments outside the viewport, as pointed out in my drawing above). However, since we're exactly at the break-off point, previous calculations are allowed to be off by some small value, leaving the characterization undefined. So I think in this case, both results are allowed, and the test is therefore somewhat bogus. If the line was tilted a tiny amount so it's guaranteed to be characterized as an x-major, then it should be correct again. Not having access to the tests myself, they might already have done this, though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Expected wide line rendering with clipping
Am 06.02.2015 um 13:11 schrieb Iago Toral: > Hi, > > Eduardo and I have been looking into a few dEQP test failures that deal > with wide line rendering. There are a few of them that fail because of > how clipping is implemented for this case. > > The problem in these cases seems to be that the hw renders the wide line > as a parallelogram so that if an edge of the parallelogram is partially > clipped, the other parallel edge will also be clipped at the same > height/width so that the resulting wide line stays a parallelogram. The > dEQP renders as if a wide line where a collection of 1px lines, so > cliping one edge of the resulting line does not have implications for > the other edge. > > This ASCII art illustrates the problem (* represent line pixels, | > represents the viewport's rightmost edge): > > Expected by dEQP i965 rendering > | | > *| | >**| | > ***| | > | | > | | > | | > > We can make the rendering result match dEQP's expectation by enabling > the GuardBand in the clip stage (GEN6_CLIP_GB_TEST). This is being > disabled by the driver for gen7 in this scenario because the underlying > framebuffer surface is larger than the viewport, and per the comment in > the code, in gen7 that would make it render beyond the viewport limits > in that surface, while it notes that gen8 hw fixes this. So I guess that > we do not want to do this in any case in gen7. > > Then, I have been reviewing the OpenGL specs to see if they clarify what > should happen when clipping wide lines and I think the spec does not > make a clear point, since when it talks about line clipping it does not > cover the case of wide lines specifically: > > "13.5. PRIMITIVE CLIPPING > ... > If part of the line segment lies in the volume and part lies outside, > then the line segment is clipped and new vertex coordinates are computed > for one or both vertices. A clipped line segment endpoint lies on both > the original line segment and the boundary of the clip volume. > ... > " > > The above description is clear for 1px lines, but where should the new > vertex be generated exactly for wide lines, where many points could be > at the boundary of the clip volume? Is any point valid? (that would mean > the dEQP test is bogus because there are multiple accepted renderings), > should the new vertex be exactly at the center of the line? (that would > make both deqp and intel rendering bogus). > > Then there is also this comment in "14.5.2.2 Wide Lines" inside the > non-AA line rasterization chapter: > > "Non-antialiased line segments of width other than one are rasterized by > off-setting them in the minor direction (for an x-major line, the minor > direction is y, and for a y-major line, the minor direction is x) and > replicating fragments in the minor direction (see figure 14.3). Let w be > the width rounded to the nearest integer (if w = 0, then it is as if w = > 1). If the line segment has endpoints given by (x 0 , y 0 ) and (x 1 , y > 1 ) in window coordinates, the segment with endpoints (x 0 , y 0 − (w − > 1)/2) and (x 1 , y 1 − (w − 1)/2) is rasterized, but instead of a single > fragment, a column of fragments of height w (a row of fragments of > length w for a y-major segment) is produced at each x (y for y-major) > location. The lowest fragment of this column is the fragment that would > be produced by rasterizing the segment of width 1 with the modified > coordinates." > > This "suggests" that wide line rendering should be equivalent to > rendering multiple lines of width=1 and if we actually did that then the > expected rendering result after clipping would be what dEQP expects. > > I think the whole thing isn't 100% clear. Does anyone have any thoughts > on what should be considered correct behavior in this case? > > Iago > > I am quite sure that i965 rendering is what (at least legacy GL) expects. This is because the wide-line expansion is defined to be happening at rasterization time, i.e. past clipping. Thus, at clipping time, no matter if a line is wide or not, it is still really a line, hence clipping will produce a single new endpoint at the viewport edge and in rasterization this is then what will be used as the endpoint. FWIW a very similar problem exists for points, and this is something which sometimes comes up. A point is either clipped fully or not at all, which causes large points to both disappear suddenly when the center is outside the viewport, and to get drawn fully even outside the viewport if the center is within the viewport! This is a really annoying difference to d3d (9 as 10 ditched points) which causes us a lot of pain (and it's noteworthy at least nvidia doesn't implement it the GL way all the time, depending on several factors but I don't know them exactly). gallium has the point_
