Re: accel handling

Stephen C. Tweedie
1999-08-29T16:14:00Z

Hi,

On Sun, 29 Aug 1999 10:52:29 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> My name is James Simmons and I'm one of the new core designers for the
> framebuffer devices for linux. Well I have redesigned the framebuffer
> system and now it takes advantages of accels. Now the problem is that alot
> of cards can't have simulanteous access to the framebuffer and the accel
> engine. What I need to a way to put any process to sleep when they access
> the framebuffer while the accel engine is active. This is for both read
> and write access. Then once the accel engine is idle wake up the
> process.

You really need to have a cooperative locking engine. Doing this sort
of thing by playing VM tricks is not acceptable: you are just making the
driver side of things simpler by placing a whole extra lot of work onto
the VM, and things will not necessarily go any faster.

The real problem with a VM solution is that threaded applications on a
multi-processor machine will go *immensely* slower. Every time you need
to lock out a VM region, you have to send a storm of interrupts to the
other CPUs to make sure they aren't in the middle of accessing the same
region from a related thread. In general, any solution which requires
fast twiddling of VM to make this work just will not be accepted.

A combination of shared-memory spinlocks (for fast tight-loop locking)
and SysV semaphores (for a blocking lock if the lock is taken for too
long) can be combined to give a simple but very efficient locking engine
for this type of thing.

Cheers,
Stephen