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

[Chris Wilson]

On Wed, 18 Jul 2012 16:44:32 +0800, He Junyan <junyan.he at linux.intel.com> wrote:
> 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.

Right if you use a mask in that case, you will prevent the overdraw.

> 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?

I think it acceptable for imprecise rendering (which has been cairo's
default mode now for a few years and hopefully the other toolkits will
catch on ;-)

However, the specification for precise mode is that we sample the
trapezoid on the centre points of an 17x15 subpixel grid (for 8-bit
alpha, generally (2*n+1)x(2*n-1) for n-bit). The rationale for
preserving is that it does produce very well defined results for any set
of trapezoids, albeit at a slight cost of sample noise. Unfortunately it
turns out to be computationally expensive...

Just treat Precise rendering as a fallback to a pixman trapezoid mask
for now and focus on making Imprecise fast, and lets focus on making the
next iteration of Render more amenable for GPU offload.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre