Subject: Re: radeon driver design (was Re: generic virtual consoles)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 12/28/2005 15:24:39
der Mouse wrote:
>>My understanding with the kernel/user boundary is that there are two
>>reasons for it being slow: 1) data copy across the boundary, and 2)
>>the context switch is expensive largely due to the rescheduling of
>>processes.
>>
>>
>
>Also, I understand that on some CPUs, merely taking the syscall trap
>(regardless of data copy and scheduling overhead) can be expensive.
>I've never done measurements, so I don't know how true this actually is
>on various CPUs, but it certainly seems plausible. Switching
>protection rings can involve massive cache pushing and reloading, all
>sorts of instruction pipeline bubbles, etc, etc....
>
>
Hmmm.... good point. But again, if we can minimize the the times that
we perform this switch, then hopefully it won't be too bad.
I'm not a graphics guru by any stretch of the imagination, but certainly
I believe that other OS' (Windows, BeOS) use a kernel-based graphics
architecture, and somehow they make it work reasonably efficiently. So
it must be possible, at least.
>Perhaps we need to invent some alternative form of syscall trap? Maybe
>a magic address that's never mapped, with the kernel foo done inside
>the page fault handler? Page faults are usually relatively cheap as
>far as the hardware is concerned....
>
>
Perhaps, but it sounds kind of ugly. Again, I need to think about this
a bit more. Initially I'll probably just use a memory mapped request
queue and some ioctls to "kick" the driver when needed.
>
>
>>As I said, this is future work. Right now I just want to get the
>>linear framebuffer working, which won't have these problems.
>>
>>
>
>Right. I've been considering doing something vaguely similar myself,
>but so far it hasn't got past the "pipe dream" stage; I'm definitely
>going to be watching your progress, since you will almost certainly get
>something working sooner than I will.
>
>
Oh no, I'm not sure I really want an audience just yet. :-)
Anyway, I'll have to see what happens when I get there. My immediate
need is fairly modest, as I need basic framebuffer support with some
simple acceleration e.g. for hardware cursor support and maybe some blit
support. (Fills and copys would be nice, too.) My performance needs
themselves are modest, as well.
-- Garrett
>/~\ The ASCII der Mouse
>\ / Ribbon Campaign
> X Against HTML mouse@rodents.montreal.qc.ca
>/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>
>
--
Garrett D'Amore http://www.tadpolecomputer.com/
Sr. Staff Engineer Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc. Phone: (951) 325-2134