We don't. But what else can one do ? We have to deal with it, and IMHO
the only possibility to deal with HW that is not inherently "safe", is
to wrap it with software that checks what you send to it and thus makes
it safe.
We can't safely give access to e.g. SCSI controllers from userspace, too.
A process going mad or a slight programming error might cause big trouble.
So what do we do in that case ? We put the driver in the kernel (where it
traditionally belongs), safely away from malicious or badly programmed
usermode code.
What is the difference to KGI ? Yes - we sacrifice some speed, because
we need a change of protection ring for safety. Anything other than that
is simply unsafe. Please show me how to do it _safely_ in another way,
if you think I am wrong.
As already said, I do not mind how this change in protection level occurs
(i.e. if it is a kernel driver like KGI or a server process like X).
The only sure thing is, that is has to be there.
And the penalty from a requested user->kernel transition is even lower than
for a reschedule to the X server needed when you want to update the display
on the X screen to the programs idea.
> > Surely performance could be improved by directly banging on the hardware,
> > but this would OTOH allow me to hang the system, too.
> could you give us a measure, what percentage of currently used Linux boxes
> is considered to have 'non-broken' video hardware?
Less than 0.1% maybe. This is exactly the reason, why I think a _safe_
interface is needed. If we all had nicely designed SGI graphics boards that
cleanly separate "safe" and "critical" register spaces, I wouldn't bother.
All would do the "natural" thing then and simply map the "safe" part and
leave the critical ones to some kernel driver or server process.
Unfortunately such separation doesn't exist in >99.9% of todays PC hardware.
Thus everything has to be considered "critical" and has thus to go through a
priviledged layer that makes sure noone messes up the system.
> the real problem is not the ioctl(). The problem is that we cant use
> neat features like retry-PCI or delayed sync.
WHAT ? Explain why we can't, please.
> Again, these two features alone have _doubled_ X's performance on my box.
Ahem ... while X can't use IRQ and DMA ... something that is present on most
current and probably all future videocards ...
> > - enforce blocking mode acceleration, i.e. accel calls only return when
> > they have done their job (in the cases where double-sided-access
> > hangs the card) or
> > - synchronize mmaped buffer and running accelerator using the ggiFlush()
> > call (when nothing really bad happens, if some jerk doesn't do it
> > right).
>
> some cards (Cirrus?) are known to hang if 'some jerk' accidentally mixes
> framebuffer access and accelerator usage.
You are reading what I write, are you ? Such cards simply fall into the
#1 category and accel commands simply block on them. So noone can access
the Fb until the accel command is done. For longer commands, we can also
unmap the framebuffer, which will cause the block when it is accessed.
Thus they keep running at full tilt as long as only accelerator is used,
and block on access to the FB until the accelerator is idle again.
This is exactly what is needed to have safe access to these cards.
> S3 Virge cards AFAIR corrupt the whole framebuffer.
So what ? If someone makes a programming error, he can corrupt his frame-
buffer anyway.
This is normal behaviour, and if nothing other than that happens, I'd say
this is acceptable for the extra speed method #2 brings.
> > And it is the hardware that is actually braindead/broken. KGI handles it
> > just right - it prevents that these misdesigns cause system instability.
> are you aware of the fact that these 'misdesigns' are actually running on
> the majority of today's desktops?
YES. This is why I take care of them. I already said above : If all HW were
built nicely, KGI wouldn't be needed so badly. It is the _bad_ HW, that
makes KGI really necessary.
> > I have _measured_ XGGI performance. It is exactly up to XFree86 except for
> > the accelerated parts, that are not implemented in XGGI.
> 'except'?? You are running an S3 card. 90% of the pixels moved in XFree86
> 3.3 are done by the accelerator. And the framebuffer access part, well,
> exactly the same thing happens in both cases (the linear framebuffer is
> mmap()-ed into user-space), so i cant see how it could be any different
> from 'exactly up to XFree86'.
So how can you say it is slow ? And I doubt that 90%. But as I said, this is
not a problem. Measurements show, that actually _using_ LibGGI's acceleration
brings quite exactly the speedup X has in these areas.
It isn't hard to enhance Xggi to actually use the acceleration LibGGI provides.
Just someone has to do it.
You might be very suited to this task. Would you like to ?
CU,Andy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> = === World-Wide-Web URL : http://sunserver1.rz.uni-duesseldorf.de/~becka === ======== GGI - The Right Thing To Do : http://synergy.foo.net/~ggi/ ========- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu