Calling interested Glamo OpenGL developers (was: The forbidden topic: Glamo OpenGL)

Carsten Haitzler (The Rasterman) raster at
Fri Nov 21 02:28:44 CET 2008

On Fri, 21 Nov 2008 02:18:25 +0100 Sascha Wessel <wessel at> babbled:

> Hi,
> On Fri, Nov 21, 2008 at 09:16:15AM +1100, Carsten Haitzler wrote:
> > On Thu, 20 Nov 2008 19:00:02 +0100 "Nicola Mfb" <nicola.mfb at>
> > babbled:
> > > I wrote a small code snippet to test XCopyArea performance, and it seems
> > > to do about 25fps smoothscrolling but at the cost of XGlamo using 70/80%
> > > of CPU. This seems very strange, it maybe my code is wrong (I repeat I'm
> > > not an expert :) ), or XCopyArea is not full accelerated, or Xglamo has
> > > to be optimized, or that the Glamo GPU is simply slow :)
> > 
> > it's accelerated - but likely polling the command queue status as you have
> > no interrupts thanks to the linux kernel's policy of not exporting
> > interrupts to userspace, so you're stuck with a poll loop. i can't remember
> > if glamo had a "i'm done" interrupt for the command queue or operations - i
> > know it had several interrupts it can generate (but as the kernel wouldnt
> > allow userspace to make use of them i pretty much ignored them).
> ???
> What's wrong with: interrupt handler -> wait queue -> file operations
> read/poll?

the policy of the kernel developers is not to export interrupts to usersapce in
a generic way - or it hasn't been in the past. this may have changed recently.
so u can patch and create a specific driver just for glamo just to export an
interrupt - and it'll never go upstream most likely, and the kernel supports
no "generic" hook to an interrupt from userspace. one way or another something
will block your path (be it getting patches upstream back to mainline kernel or
just living without interrupts etc.). this is last i checked. 

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at

More information about the community mailing list