[Glamor] [PATCH 1/2] Change the trapezoid render to use VBO

[He Junyan]

Hi Chris:


> On Tue, 17 Jul 2012 06:53:41 +0800, junyan.he at linux.intel.com wrote:
>> From: Junyan He <junyan.he at linux.intel.com>
>>
>>   Because some uniform variables need to be set for every
>>   trapezoid rendering, we can not use vbo to render multi
>>   trapezoids one time, which have performance big loss.
>>   We now add attributes which contain the same value to bypass
>>   the uniform variable problem. The uniform value for one
>>   trapezoid will be set to the same value to all the vertex
>>   of that trapezoid as an attribute, then in FS, it is still
>>   a constant.
>
> This still has the problem that it misrenders neighbouring trapezoids,
> which is not permitted even in the imprecise specification (and since it
> does not conform to the specification of precise rasterisation it should
> not be used there either). To get around the former issue with the
> current design you still need an intermediate accumulation buffer.

I really encounter some problems when the trapezoids adjoin each other.
The EDGE area will get a wrong result. Now in glamor, it generates a 
temp mask
which stores the result of all the trapezoids's alpha value. By setting
glBlendFunc(GL_ONE, GL_ONE), if one pixel belong to two adjacent trapezoids,
the alpha value will accumulate and cut to 1.0 . So I think the problem of
misrendering neighbouring trapezoids may not exist.

About the specification of precise rasterisation problem, the standard 
manner
will expand one pixel to n pixels, caculate how may expanded pixels are 
completely
inside the trapezoid and get the result by insides/total. If alpha depth 
is 8,
it should be expanded to 8*8 pixels and caculate whether the pixel is 
inside the
trapezoid for each of these 64 pixels. I find the trapezoid code in 
pixman is
a kind of approximation by iteration and have high performance. But for 
shader
I do not find an efficient way to do this. So I use float to caculate 
the area
inside the trapezoid, and get the result by (inside area)/(one pixel 
total area).
The difference is that some area that belongs to not completely inside 
pixel has
been caculated in, and that's why my result is always a little deeper 
than the
pixman's result in color. Do you think that the difference is acceptable?