Hi Christoph,
> > > through a memory-"window", which is stored in physical RAM.
> > Huh ? How does the card access that ? using Busmaster-DMA ?
> Yes.
O.K. - I see. It's a good thing actually, provided that the "protocol"
talked on that RAM page is secure. It allows to have completely asynchronous
Accelerator operation without CPU load.
> > In that case it gets very tricky, because, you will need kernel help
> > to get the physical address of the window and moreover on 64 bit
> > architectures, you need a way to allocate memory in the range that
> > is available for Busmaster-DMA.
> In other words: This can _never_ be target-independent, right?
No. It is very dependant on the Operating system, because no standard ways
exist to allocate physical memory. On Linux I would either use a kernelspace
driver (best way IMHO) or you would have to do something like:
malloc(enough, including slack for alignment)
mlock(that)
use /proc/self/maps to locate the physical address (which is tricky by
itself)
tell the card, where the physical address of the DMA buffer is
Hack away.
> So, then access handling to physical RAM must always implemented in
> the target.
IMHO such stuff should go into a KGI driver. It is a horrible hack to do it
in userspace. Basically you should be able to ask the driver to get and lock
the memory for you and then mmap() it from somewhere in the /dev/kgi*
device. That's clean and nice.
> Uhmm... When you buy a new graphic card, aren't you wondered why it
> requires a certain amount of system RAM ?
I usually consider that to be the same bullshit as on any application
software. They always say "PII-300 or better as minimum" or something.
It will run on a 486/33 usually, though it might be pretty slow.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
