[Intel-gfx] Guidance on speed for various GL operations with Intel HW

[Peter Clifton]

On Fri, 2009-02-20 at 14:54 +0000, Chris Wilson wrote:
> On Thu, 2009-02-19 at 17:42 +0000, Peter Clifton wrote:
> > I'm writing a GL frontend for the gEDA/PCB electronic CAD software for
> > circuit board design, and since both my laptops so far have had Intel
> > GPUs (by deliberate choice), I'm trying to target the code such that it
> > will work quickly on these cards (945 and GM45).
> 
> [snip]
> 
> > The other usage I'm making of stencil buffers, is that we draw polygons
> > with holes cut out of them. The GLU tessellator gets really bogged down
> > if you hand it the whole thing to chew on, so I found it is faster to
> > use bit in the stencil buffer to mask out where the holes are before
> > filling the whole outer contour with triangles.
> 
> Hi Peter, going slightly off-topic...
> 
> I know that you've talked about using Cairo in the past, I presume in
> this task, so I was wondering how it compares. Layout of 2D objects and
> compositing of translucent layers is where Cairo should shine. In
> particular, I'm interested in looking over a cairo-trace of your layout
> engine to analyse the bottlenecks within Cairo.

I ported the schematic capture tool to use cairo for rendering, however
we were not so concerned with antialiasing in the PCB layout tool, and
GL won hands down with regards speed.

I tried the glitz cairo back-end when I first attemptd using cairo with
PCB, but even after patching it to get past the bit-rot, I couldn't make
it work properly (or particularly fast).

I'll see if I still have the early code I was playing with. I'm not
quite sure what the best way to do subcompositing of layers is.
cairo_push_group() / cairo_pop_group() would be one possibility I
guess. 

Would another sensible approach be to construct a single path of all my
primitives, and stroke / fill it as a single operation? (To avoid the
highlight you otherwise get when overlapping two translucent lines).


The other scary thought I'm having, is that if the glClear() performance
can't be improved, I might have to just avoid drawing overlapping pieces
of primitives within each layer. We have some polygon arithmetic code in
PCB, which _could_ do that, it just isn't particularly fast at
intersecting contours, so the results would have to be cached).

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)