Re: accel handling

Re: accel handling

[Jens Owen]

Don't know if this would be any help to this discussion, be we have some
writeups on the mechanisms we use for the DRI at
http://www.precisioninsight.com/dr/ the most useful might be
locking.html

Regards,
Jens

PS I'm not subscribed to this list, just following the mail archive.

--                          /\
    Jens Owen              /  \/\ _      jens@precisioninsight.com
    Precision Insight     /    \ \ \     Steamboat Springs, Colorado
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

On Mon, 30 Aug 1999 21:39:21 -0600, Jens Owen
<jens@precisioninsight.com> said:

> Don't know if this would be any help to this discussion, be we have
> some writeups on the mechanisms we use for the DRI at
> http://www.precisioninsight.com/dr/ the most useful might be
> locking.html

Thanks.  Yes, this is exactly what I've been saying all along --- if you
want to make things go fast enough, you need cooperative locking.
Physically enforcing it in the VM wil never be able to keep up with the
pace.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

accel handling

[James Simmons]

Hi!

 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.
MM is beyond me. Trust me I tried to find a solution. Anyone have a idea
what needs to be done? Thank you.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

accel handling

[James Simmons]

Hi!

 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.
MM is beyond me. Trust me I tried to find a solution. Anyone have a idea
what needs to be done? Thank you.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[James Simmons]

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

I though so but I wanted to see if their was a acceptable trick to handle
this.

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

Any docs on this stuff. How would I go about do this ? I really want to do
this write. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

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

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

> Any docs on this stuff. How would I go about do this ? I really want to do
> this write. 

There are spinlock primitives in linux/asm/spinlock.h, and the
underlying atomic bit operations are in linux/asm/bitops.h.  man shmop
and man semop for information about SysV shared memory and semaphores.

--Stephen

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Marcus Sundberg]

Stephen C. Tweedie wrote:
>
> 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.

What I believe James is talking about here is allowing non-priviledged
processes to access graphics hardware where the graphics card, or even
the whole system, may enter an unrecoverable state if you try to access
the frame buffer while the accel engine is active. (Yes there really
exist such hardware...)

To achieve this you really must physicly prevent the process to access
the framebuffer while the accel engine is active. The question is what
the best way to do this is (and if that way is good enough to bother
doing it...) ?

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

On Mon, 30 Aug 1999 14:06:48 +0200, Marcus Sundberg
<erammsu@kieraypc01.p.y.ki.era.ericsson.se> said:

> What I believe James is talking about here is allowing non-priviledged
> processes to access graphics hardware where the graphics card, or even
> the whole system, may enter an unrecoverable state if you try to access
> the frame buffer while the accel engine is active. (Yes there really
> exist such hardware...)

I know that.  I know _why_ it is desirable to have hardware protection
of these memory regions.  I also know why it is expensive to provide
that protection in the VM, and why in the SMP threaded case that cost
becomes a prohibitive overhead.  That sucks, but that's life in the
crap-hardware PC world.

> To achieve this you really must physicly prevent the process to access
> the framebuffer while the accel engine is active. The question is what
> the best way to do this is (and if that way is good enough to bother
> doing it...) ?

The only way to do it is to flip page tables while the accel engine is
running.  You may want to restore it on demand by trapping the page
fault on the framebuffer and stalling until the accel lock is released.
This can be done, but it is really expensive: you are doing a whole pile
of messy VM operations every time you want to trigger the accel engine
(any idea how often you want to flip the protection, btw?)

So you are talking several system calls, SMP inter-processor interrupts
and piles of VM page twiddling every time you want to claim and release
the core engine.  Sorry, folks, but there's no way of avoiding the
conclusion that this is going to be expensive.  In the single-CPU or
single-thread case the cost can be kept under control, but it is not
going to be cheap.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[James Simmons]

> The only way to do it is to flip page tables while the accel engine is
> running.  You may want to restore it on demand by trapping the page
> fault on the framebuffer and stalling until the accel lock is released.
> This can be done, but it is really expensive: you are doing a whole pile
> of messy VM operations every time you want to trigger the accel engine
> (any idea how often you want to flip the protection, btw?)
>

The way the accel engine will work is that it will batch accel commands.
Then when full flush them to the accel engine. So we can batch a hugh
number of commands to avoid the expensive process of flipping page tables.
Of course the buffer is of variable size. The size determined by how many
accel commands you want to send to the engine to display a frame. So a
complex scene would be worth it.  
 
> So you are talking several system calls, SMP inter-processor interrupts
> and piles of VM page twiddling every time you want to claim and release
> the core engine.  Sorry, folks, but there's no way of avoiding the
> conclusion that this is going to be expensive.  In the single-CPU or
> single-thread case the cost can be kept under control, but it is not
> going to be cheap.

The secert is to do a as few times possible.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

On Mon, 30 Aug 1999 10:50:11 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> The way the accel engine will work is that it will batch accel commands.
> Then when full flush them to the accel engine. So we can batch a hugh
> number of commands to avoid the expensive process of flipping page tables.
> Of course the buffer is of variable size. The size determined by how many
> accel commands you want to send to the engine to display a frame. So a
> complex scene would be worth it.  

For graphics, latency is important.  You can't afford to arbitrarily
batch things up into things only getting sent every hundred msec or so.
Also, depending on what you are doing, you can be streaming things to
the accel engine _fast_: for 3D, for example, the DRI people talk about
sending a new command queue to an accelerator at the rate of a few
thousand per second.  For 2D animation you are probably talking about
at least hundreds per second, depending on how much is going on.  Much
less than that and the latency becomes visible.
 
> The secert is to do a as few times possible.

If that results in a performance drop, then it kind of defeats the idea
of having an accel engine.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[James Simmons]

> For graphics, latency is important.  You can't afford to arbitrarily
> batch things up into things only getting sent every hundred msec or so.
> Also, depending on what you are doing, you can be streaming things to
> the accel engine _fast_: for 3D, for example, the DRI people talk about
> sending a new command queue to an accelerator at the rate of a few
> thousand per second.  For 2D animation you are probably talking about
> at least hundreds per second, depending on how much is going on.  Much
> less than that and the latency becomes visible.

Then the question is how are DRI handling this. I'm assuming they don't
allow access to the framebuffer. Then it looks like the best solution not
allow any accels when you have /dev/fb mmapped. Then their still the
problem of fbcon drivers that use accels to do drawing operations. What if
the user is writing to the framebuffer device while a accel is being
processed in the kernel. It locks the machine hard. I know from personal
experience with the matrox framebuffer device. One in ten times of
starting X it locks my machine and I have to reboot. This problem needs to
be solved and its no longer a PC problem when this kind of hardware can
now run on SPARCs and PPC. Now having fbcon remove all accel code would be
really bad on performace for high end modes like 1600x1280x32. These modes
are going to become common place ove rthe next few years.   

> > The secert is to do a as few times possible.
> 
> If that results in a performance drop, then it kind of defeats the idea
> of having an accel engine. 

Right, you have to empty the accel queue at each frame refresh. Faster
than that would be pointless. Slower than that would be really bad.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

On Mon, 30 Aug 1999 13:51:14 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

> Then the question is how are DRI handling this. I'm assuming they don't
> allow access to the framebuffer. 

They have to allow framebuffer access, to support software fallback if
the hardware doesn't do complete open-GL in silicon.  For functions
which the hardware won't do, the software needs to be able to get its
own hands dirty, and it is the same user-space library which is doing
both the accelerated and the raw bits of the job.

> Then it looks like the best solution not allow any accels when you
> have /dev/fb mmapped. Then their still the problem of fbcon drivers
> that use accels to do drawing operations.

Exactly.

>  What if the user is writing to the framebuffer device while a accel
> is being processed in the kernel. It locks the machine hard. 

Then you need to trust any libs/binaries which you give framebuffer
access to.

> I know from personal experience with the matrox framebuffer
> device. One in ten times of starting X it locks my machine and I have
> to reboot. This problem needs to be solved and its no longer a PC
> problem when this kind of hardware can now run on SPARCs and PPC. 

it needs to be solved, yes.  In hardware.  Moan at your vendor. :)

> Right, you have to empty the accel queue at each frame refresh. Faster
> than that would be pointless. Slower than that would be really bad.

It depends on the speed of the queue.  If your video throughput is
bottlenecked on the accel queue, then you do want to be emptying it as
fast as possible to avoid idling the silicon.

--Stephen

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Vladimir Dergachev]

On Mon, 30 Aug 1999, Stephen C. Tweedie wrote:

> Hi,
> The only way to do it is to flip page tables while the accel engine is
> running.  You may want to restore it on demand by trapping the page
> fault on the framebuffer and stalling until the accel lock is released.
> This can be done, but it is really expensive: you are doing a whole pile
> of messy VM operations every time you want to trigger the accel engine
> (any idea how often you want to flip the protection, btw?)
> 
> So you are talking several system calls, SMP inter-processor interrupts
> and piles of VM page twiddling every time you want to claim and release
> the core engine.  Sorry, folks, but there's no way of avoiding the
> conclusion that this is going to be expensive.  In the single-CPU or
> single-thread case the cost can be kept under control, but it is not
> going to be cheap.
> 

What about forbidding concurrency for the processes that have mmapped
the framebuffer/accelerator ? Say assign all of them to one(or same) cpu
permanently. If someone really wants it's process to run on more than one
cpu (I don't think Linux does this currently) they had to do some extra
work anyway.

                           Vladimir Dergachev 

> --Stephen
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://humbolt.geo.uu.nl/Linux-MM/
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Marcus Sundberg]

Vladimir Dergachev wrote:
> 
> On Mon, 30 Aug 1999, Stephen C. Tweedie wrote:
> 
> > Hi,
> > The only way to do it is to flip page tables while the accel engine is
> > running.  You may want to restore it on demand by trapping the page
> > fault on the framebuffer and stalling until the accel lock is released.
> > This can be done, but it is really expensive: you are doing a whole pile
> > of messy VM operations every time you want to trigger the accel engine
> > (any idea how often you want to flip the protection, btw?)
[snip]
> What about forbidding concurrency for the processes that have mmapped
> the framebuffer/accelerator ? Say assign all of them to one(or same) cpu
> permanently.

Not an acceptable solution. You may have several threads clone()d off
after the framebuffer have been mapped, and they may not do anything
related to graphics.

But by only re-mapping the framebuffer on demand as Stephen said you
can avoid repeatedly un-mapping the framebuffer for processes/threads
that doesn't use it.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

On Tue, 31 Aug 1999 12:55:26 +0200, Marcus Sundberg
<erammsu@kieraypc01.p.y.ki.era.ericsson.se> said:

> But by only re-mapping the framebuffer on demand as Stephen said you
> can avoid repeatedly un-mapping the framebuffer for processes/threads
> that doesn't use it.

Yes.  The biggest problem is that the VM currently has no support for
demand-paging of an entire framebuffer region, and taking a separate
page fault to fault back the mapping of every page in the framebuffer
would be too slow.  As long as we can switch the entire framebuffer in
and out of the mapping rapidly, things aren't too bad.

Even on an SMP box with threads, the overhead is probably acceptable if
we are switching at no more than frame rate.  However, for low latency,
high throughput graphics, I'm guessing we'd be driving the accel engine
a lot faster than that, and we also have the problem that many graphics
operations will require fine interleaving of (and hence fast switching
between) accelerated and framebuffer access.  VM enforcement simply is
not fast enough for this.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[James Simmons]

> Hi,
> 
> On Tue, 31 Aug 1999 12:55:26 +0200, Marcus Sundberg
> <erammsu@kieraypc01.p.y.ki.era.ericsson.se> said:
> 
> > But by only re-mapping the framebuffer on demand as Stephen said you
> > can avoid repeatedly un-mapping the framebuffer for processes/threads
> > that doesn't use it.
> 
> Yes.  The biggest problem is that the VM currently has no support for
> demand-paging of an entire framebuffer region, and taking a separate
> page fault to fault back the mapping of every page in the framebuffer
> would be too slow.  As long as we can switch the entire framebuffer in
> and out of the mapping rapidly, things aren't too bad.
>

So if this is the problem could we write a special routine that optimizes
this. What if we gave the VM support for demand paging of an entire
framebuffer region.  

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

On Tue, 31 Aug 1999 13:10:46 -0400 (EDT), James Simmons
<jsimmons@edgeglobal.com> said:

>> Yes.  The biggest problem is that the VM currently has no support for
>> demand-paging of an entire framebuffer region, and taking a separate
>> page fault to fault back the mapping of every page in the framebuffer
>> would be too slow.  As long as we can switch the entire framebuffer in
>> and out of the mapping rapidly, things aren't too bad.
>> 

> So if this is the problem could we write a special routine that optimizes
> this. What if we gave the VM support for demand paging of an entire
> framebuffer region.  

You cut out the most important part of my email, which was that such
support would be prohibitively expensive for any graphics-intensive
applications.  It is only feasible if there is a very low rate of
switching between accel and framebuffer access.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[James Simmons]

> What I believe James is talking about here is allowing non-priviledged
> processes to access graphics hardware where the graphics card, or even
> the whole system, may enter an unrecoverable state if you try to access
> the frame buffer while the accel engine is active. (Yes there really
> exist such hardware...)
> 
> To achieve this you really must physicly prevent the process to access
> the framebuffer while the accel engine is active. The question is what
> the best way to do this is (and if that way is good enough to bother
> doing it...) ?

Marcus you are on this list too. Actually I have though about what he
said. I never though of it this way but you can think of the accel engine
as another "process" trying to use the framebuffer. Their still is the
question. How do you know when a mmap of the framebuffer is being
accessed? So I can lock the accel engine when needed.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Eric W. Biederman]

James Simmons <jsimmons@edgeglobal.com> writes:

> > What I believe James is talking about here is allowing non-priviledged
> > processes to access graphics hardware where the graphics card, or even
> > the whole system, may enter an unrecoverable state if you try to access
> > the frame buffer while the accel engine is active. (Yes there really
> > exist such hardware...)
> > 
> > To achieve this you really must physicly prevent the process to access
> > the framebuffer while the accel engine is active. The question is what
> > the best way to do this is (and if that way is good enough to bother
> > doing it...) ?
> 
> Marcus you are on this list too. Actually I have though about what he
> said. I never though of it this way but you can think of the accel engine
> as another "process" trying to use the framebuffer. Their still is the
> question. How do you know when a mmap of the framebuffer is being
> accessed? So I can lock the accel engine when needed.

Just a couple of thoughts.

A) Assuming we are doing intensive drawing whatever we are doing with
   the accellerator needs to happen about 30 times per second.  That
   begins the aproximate limit on humans seeing updates.

B) At 30hz we can do some slightly expensive things.
   To a comuputer there is all kinds of time in there.

C) We could simply put all processes that have the frame buffer
   mapped to sleep during the interval that the accel enginge runs.

D) We could keep a copy of the frame buffer (possibly in other video
   memory) and copy the ``frame buffer'' over, (with memcpy in the kernel, or with an 
   accel command).
   At 1600x1280x32 x30hz that is about 220 MB/s.  Is that a figure achieveable in the
   real world?

E) Nowhere does it make sense to simultaneously access the accelerator
   and frame buffer simultaneously. ( At least the same regions of the frame buffer).
   Because the end result on the screen would be unpredicatable.
   Therefore it whatever we use for locks ought to be reasonable.

F) It might be work bouncing this off of the ggi guys to see if they have
   satisfactorily solved this problem.  Last I looked the ggi list was linux-ggi@eskimo.com

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[James Simmons]

> C) We could simply put all processes that have the frame buffer
>    mapped to sleep during the interval that the accel enginge runs.

That it!!!! You gave me a idea. I just realize I have been thinking about
it all wrong. Its not looking at if the framebuffer is being accessed but
to keep track of all the processes that have mmap the framebuffer device.
When the accel engine is ready to go we put all the processes that have
/dev/fb mmapped to sleep no matter if its being access or not. One thing
that I would have to make sure that the same process thats being put to
sleep isn't also the one trying to use the accel engine.   

> F) It might be work bouncing this off of the ggi guys to see if they have
>    satisfactorily solved this problem.  Last I looked the ggi list was linux-ggi@eskimo.com

I'm one of those guys as well as a kernel developer.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Andreas Beck]

> > C) We could simply put all processes that have the frame buffer
> >    mapped to sleep during the interval that the accel enginge runs.

I am missing a little bit of context here, but I assume you are talking
about how to handle concurrent framebuffer and accelerator access.

I think there are two different cases for this problem:

1) If the access happens concurrently, the hardware will lock up. This is
unfortunately the case with some common boards like the S3 Virge.

In that situation mandatory locking of the two ressources is required
to keep the system stable. 

The only solution I see for that is unmapping the framebuffer for all
processes that have it mapped. I know that this is bad bad bad performance
wise, but I'm afraid we can't help it. I think it is a little more friendly
than to just halt all apps. They might just be doing innocent calculations
or something. It is early enough to halt them when they try to touch the
framebuffer, which will trigger a nopage exception, as it is unmapped.

Also note, that this is only a real issue on MP, as on single processor
systems, you are sure that no concurrent access is ongoing by just waiting
for the accel call to finish. depending on how quick that is expected, I'd
suggest to either busy wait on the accel call (for very quick ones) or to 
stop the applicatition and reschedule until the accel is done.

2) Concurrent access causes only "correctable" problems like a messed up
display.

In that case, I suggest to rely on a "advisory" locking scheme, that can be
implemented to be really quick using kernel-/usermode shared locks.

It requires that you "lock" the FB before accessing it, as well as the
accelerator. These two locks would be mutually exclusive, so accels are
blocked while FB is in use and vice versa. The advantage is, that you 
need no expensive map/unmap or other similar schemes. However it relies on
applications being benevolent and not holding locks for excessive amounts of
time or ignoring the locks.
As long as system stability is not affected (I.e. you can somehow still
kill off the malfunctioning program), I assume that to be acceptable, as it
isn't differnt from the situation on X today, where any client can seriously
mess up my display and limit my interaction potential with other apps
or the windowmanager by generating tons of windows right under the mouse
pointer or similar..

If you for some reason want a "lock override", as e.g. the X server might
want, if it has clients with DirectRendering style Fb access, this can be
done with kernel help, as the kernel can be asked to block everyone that
holds the FB lock. 

The accel lock is more tricky: _IF_ you want to allow userland accelerator
access for more than one process "simultaneously" (in the sense of processes
running timeshared, not necessarily SMP), you need to be able to save/restore 
the complete graphics engine state at scheduling time (or be able to 
influence scheduling).
The graphics engine has to be treated like sort of a coprocessor here.

This is often more tricky than it seems, as many cards have registers that
act differently on stuff like which registers have been _accessed_ before,
not necessarily what the complete dump of the regs is.

Unless you have a properly virtualizeable graphics board, I would not
recommend to have concurrent access to graphics engines. If the accel lock
is on, it is on. Tough luck. Fall back to software rendering or wait for the
lock to become free.
In that case doing the acceleration in some central entity (that can _track_
the card state) like a server process or a kernel driver is the better
solution.

> That it!!!! You gave me a idea. I just realize I have been thinking about
> it all wrong. Its not looking at if the framebuffer is being accessed but
> to keep track of all the processes that have mmap the framebuffer device.
> When the accel engine is ready to go we put all the processes that have
> /dev/fb mmapped to sleep no matter if its being access or not. 

That's kind of being rude to innocent processes, that might not even touch
the mmaped FB. I'd unmap and fault them to sleep, if they do access it.

> One thing that I would have to make sure that the same process thats being 
> put to sleep isn't also the one trying to use the accel engine.   

This is handled automatically by the scheme I describe above. Depending on
how you want to lay the stuff out exactly, it might be a good idea, to
_kill_ this process, if it tries to use accel and framebuffer concurrently.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: accel handling

[Stephen C. Tweedie]

Hi,

On 30 Aug 1999 13:51:41 -0500, ebiederm+eric@ccr.net (Eric W. Biederman)
said:

> A) Assuming we are doing intensive drawing whatever we are doing with
>    the accellerator needs to happen about 30 times per second.  That
>    begins the aproximate limit on humans seeing updates.

> B) At 30hz we can do some slightly expensive things.
>    To a comuputer there is all kinds of time in there.

Sure, *if* you can get away with activating the accel queue just once
per cycle.  Who gets woken up when accel is done, btw?  How do we
restore fb access?

> C) We could simply put all processes that have the frame buffer
>    mapped to sleep during the interval that the accel enginge runs.

Ouch.  Think about games --- performance is the most important thing for
them, and they want all the CPU they can get.  They most certainly do
NOT want to be stalled just because the framebuffer is out of bounds:
there may be other useful things they could be calculating in the mean
time.

> D) We could keep a copy of the frame buffer (possibly in other video
>    memory) and copy the ``frame buffer'' over, (with memcpy in the kernel, or with an 
>    accel command).
>    At 1600x1280x32 x30hz that is about 220 MB/s.  Is that a figure achieveable in the
>    real world?

Not even close.  At least, not without consuming 100% cpu and bus bandwidth.

> E) Nowhere does it make sense to simultaneously access the accelerator
>    and frame buffer simultaneously. ( At least the same regions of the frame buffer).
>    Because the end result on the screen would be unpredicatable.
>    Therefore it whatever we use for locks ought to be reasonable.

That's a user space issue.  If you have full framebuffer access and you
mess up the screen, it's your fault, no big deal.  If you crash the
machine, that's an entirely different matter.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/