> Yes I like mmap to a large degree. In fact one of the things that has
> always excited me was the idea of using kio buffers to manage graphics
> hardware like the disk layer does. Think about the speed improvements
> since we wouldn't be going threw the VM layer. Basically we have raw
> IO instead of for disk for graphcis hardware. Plus we get the bounus of
> not worrying about inheritance issues. IRIX doesn't allow the graphics
so true! when vesa2 came out, with linear framebuffers and everything, i
was estatic. no more bank switching etc. I would assume similar things
for disk access, as well as perhaps sound buffers and nic buffers, but i
have yet to deal directly with them at the hardware level (discovered
linux first).
> the graphics hardware. Locally we could use enhanced version of mmap, read
> and write.
"enhanced version of mmap, read and write." :^)
unless read and write become special compiler macro type things, i still
fail to see how any amount of enhancing done to read/write will approach
buffer[offset]. best case, you could write in blocks or 65536b or more,
and simply flag it's length and have read/write internally to the
buffer[offset] (similar to memmov), but when you only modify a single
pixel/byte, read/write would at least double the execution time.
despite this, much of the graphics world at least seems to be moving to
hardware accleration, so instead of reading/writing a lot of data, you
only read/write 'instructions' to the card. this is still useless when
you _want_ to use fb as is (for some efect that can't be/isn't implimented
in hardware). even this is combated by the new programmable gfx cards,
which makes fb effects done by the cpu seem even more obsolete. but this
would severely limit the older machines that have either no hardware
acceleration or no drivers to run the hardware. (or, the user is aganst
using hardware that uses only closed source drivers)
compared to the above, it would be fairly trivial to add an
if(mmap_failed)
{
read/write to buffer
}
else
{
use mmap'd buffer
}
to any kind of program that would need it, which makes the elimination of
mmap seem counterproductive when network transparency is not needed.
chris
--- moc.lexiptfos@thgirwc ---
|
