James M Best wrote:
- DGA- Where can I find documentation on it? I have looked around, but
it is not easy to find. I am going to start tearing into the X/DGA
source to learn a bit more.
It is an extension (non-standard by definition), and I think only
XFree86 has it (the extension name is “XFree86-DGA”). Maybe Xig or
Metro-X has it too, but I’m quite sure the Solaris X server doesn’t have
it. XFree86 on Linux/sun4m doesn’t have it.
You can find the documentation on a Linux system with the XFree86 man
pages with “man XF86DGA”. Also, the <X11/extensions/xf86dga.h> header
file is the most up to date documentation (the man page is notoriously
out of date).
- Why can’t shared memory be in graphics memory? And why is direct
access to video memory a “root” thing?
Shared memory as used by the MIT-SHM extension (which I think is
available on Solaris) is obtained with the SysV shared memory calls
(shmget, shmat, etc), which doesn’t give you control over what memory is
shared, it works in a way slightly similar to malloc.
On most servers the video ram is linearly mapped into the
address space of the computer. Each process has memory access
restrictions… why can’t a portion of video memory be added to a
process’ access list? Security in this can be handled by the X server,
with standard X security. Why is this such a big deal? Also, if the X
client has access to the server they can already write and read the
entire screen… what is the stability flaw in letting them memory map
it directly? It should be stable and secure?
DGA uses the mmap syscall to map the video memory thru the /dev/mem
device file. This requires read/write access to that file, which is
usually a root privilege, for obvious reasons (ability to write all over
memory is not something to grant lightly). This is completely separate
from X authentication and cannot be integrated into it, as it is a lower
level security requirement.
Anyway, IMHO, giving a client process direct access to video memory
isn’t that useful. Letting the X server do the data moving itself is a
better idea, but for this to be satisfying enough, the X server has to
support many ways of moving that data (like alpha blending or colorkey
blitting).
In the worst case, the software implementation in the X server can be
just as good as one you wrote yourself (if you can write a better one,
fix the X server, this will help all applications!), and in the best
case, system->video blitting could be done with some fancy DMA bus
mastered transfer or with some AGP Fast Write thingy (don’t know much
about how this works), at a much better performance than you could ever
do by giving the client access to video memory.
There are a few ways things could be improved. For example, Unix domain
sockets like the one used for local X connections have the peculiar
ability of passing file descriptor across. I think the X server (which
has root privilege) could open /dev/mem and pass the file descriptor to
the client, which could then be used by the library to mmap the video
memory. I think.
Another mmap trick would be for the X server to use the /proc filesystem
to mmap the client memory instead of using SysV shm, which has a few
annoying limitations (maximum size, maximum total size, maximum number,
they can stay there after the application died). Never tried that, but
could work.
I understand that “the idea of X” is to be able to run it remotely, but
there are already so many extensions that allow special things to local
clients that these things just make sense.
I think a local-only extension is acceptable, and my idea for an
extension (which doesn’t include shared memory or direct graphic access
features) would still work over a network (much like accelerated OpenGL
with GLX can work over the network, and can even have good throughput if
display lists are extensively used, only more latency).
Also, adding X functions to hardware blit seem like a no brainier.
Almost every graphics card allows accelerated video->video blits, but
many more are starting to allow accelerated memory->video blits. It
would be great if there were an extension that allowed a simple call to
this kind of blit, so that clients could blit things from their address
space to the screen.
I think an extension that would provide the two following items would be
cool:
-
a few additionnal options to XCopyArea, like colorkey and alpha
blending (maybe others, what do you people think?). This would work with
any Drawable, like the current XCopyArea, with software emulation when
not supported by the hardware (as already provided by XAA).
-
a way to create Pixmaps that are in video memory and stay there, or
that would allow to increase the cache priority of existing Pixmaps
(allowing “real time” Pixmaps like those used by games to take
precedence over your window manager icons for example). Once created,
they would be just like regular Pixmaps (which also mean they would work
with the first item). This is similar to what XShmCreatePixmap already
do, but in video memory instead of shared memory.
What do you people think of this?
Note that nothing in this proposition requires the X client to be local
to the X server. To put stuff quickly into those “fast” pixmaps, you
would still need to use XShm the usual way.
There are all these extensions, and they are slowly getting "better"
depending on your needs. Why don’t we make one new extension with the
abilities of many of the others and say “Here, this is how it should be
done!” and start coding instead of complaining? I’m up for it, although
I doubt anyone would accept it. It seems many people here are stuck on
it being against the “whole idea of X”.
I have to finish up a contribution to Mozilla I am working on, then I
will dive into the XFree86 server code and get on the development
mailing list(s).
If anyone here IS interested in this, please let me know. I know there
are others making this kind of extension, but apparently they aren’t
doing it correctly or we would be using them today.
I am interested, but I want to make sure there isn’t an existing
extension that we could improve the implementation to do what we want
first.
I think it will be a mix of improvement and new extension(s). For
example, the X server should cache pixmaps in video memory, and maybe we
could have an extension to give priorities to pixmaps that would give
the application control over the caching (but it would work without the
extension).–
Pierre Phaneuf
http://ludusdesign.com/