Am 15.03.2016 um 08:20 schrieb Jose Fonseca:
> On 13/03/16 20:40, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> The logic was comparing actual ints, not true/false values.
>> This meant that it was emitting always multiple line segments instead
>> of just
>> one even if the stipple t
On 13/03/16 20:40, srol...@vmware.com wrote:
From: Roland Scheidegger
The logic was comparing actual ints, not true/false values.
This meant that it was emitting always multiple line segments instead of just
one even if the stipple test had the same result, which looks inefficient, and
the segm
From: Roland Scheidegger
The logic was comparing actual ints, not true/false values.
This meant that it was emitting always multiple line segments instead of just
one even if the stipple test had the same result, which looks inefficient, and
the segments also overlapped thus breaking line aa as w
On 06/01/16 22:26, srol...@vmware.com wrote:
From: Roland Scheidegger
The unfilled stage was not filling in the prim header, and the line stage
then decided to reset the stipple counter or not based on the uninitialized
data. This causes some failures in conform linestipple test (albeit quite
r
Reviewed-by: Brian Paul
On 01/06/2016 03:26 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
The unfilled stage was not filling in the prim header, and the line stage
then decided to reset the stipple counter or not based on the uninitialized
data. This causes some failures in conform
From: Roland Scheidegger
The unfilled stage was not filling in the prim header, and the line stage
then decided to reset the stipple counter or not based on the uninitialized
data. This causes some failures in conform linestipple test (albeit quite
randomly happening depending on environment).
So
