> I'm aware of the hardware context these cards possess:) Fork is the
> problem :( Think about the race conditions on SMP machines.
>
> What race condition? If the processes use the DRM/DRI locking as it's
> supposed to be used to interlock rendering pipeline access, there is
> no problem.
DRI is design for low end hardware. Using DRI with high end graphics cards
is like putting training wheels on a porche. Why dumb down good hardware?
Doing so will ensure you will not get maximum performace.
> For DGA, the X server begins using unaccelerated direct framebuffer
> rendering while DGA tasks exist, and the framebuffer is "thread safe"
> insofar as having multiple processes read/write the framebuffer in
> parallel. It is the framebuffer, _not_ the rendering pipeline
> registers that are given to tasks using DGA.
Its not the framebuffer memory itself. Can I not write a userland app that
opens /dev/fb and set the video mode to somthing else. Most low end pci
cards have two apertures. One for big endian and another for little endian.
In 8 bit mode the card will most like use the little endian aperture. So
if you have the X server open /dev/fb and sets the mode via
FBIOPUT_VSCREENINFO. It then calls FBIOGET_FSCREENINFO and uses that
data to mmap the framebuffer. Then I use my own fbdev program. It calls
FBIOPUT_VSCREENINFO to set it to a 16 bpp mode. This means the aperture
has changed its address this fix->smem_start is invalid. Thus the X
server will be writing to the wrong memory region.
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.
James Simmons [jsimmons@linux-fbdev.org] ____/|
fbdev/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:11 EST