Philip Brown wrote:
> Ah. That helps for understanding of that bit.
> Is lnx_agp.c written by the xfree team, or the dri team?
It was written by XFree86 president David Dawes.
> > ... If we used
> > /dev/agpgart then the client would have to open two devices,
> > authenticate to both of them, and make half a dozen calls to agpgart,
> > then only care about the DRM device.
> The CLIENT? Isn't the X _server_ the one doing the opening of the
> AGP hardware?
The Xserver is the one doing the initialization. However every client
side driver that uses agp has to mmap an agp region or two.
> And why is it so horrible to keep the two drivers open, if it drastically
> reduces code complexity?
It will add complexity. Take my word for it.
> As you say, it opens the AGP stuff, then forgets about it. So keeping it
> separate should not increase code complexity compared to unifying it.
You now need to authenticate via two seperate mechanisms. You have to
ask the Xserver for permission to access the agp device. Then you have
to do the same for the drm. Both of these authentications are complex
involving a good hunk of code. This also means that the end user has to
worry about configuring permissions for two devices correctly instead of
just one. Anything that makes it harder for the user to use direct
rendering is bad in my opinion. Its already hard enough.
Plus the DRM kernel module usually has to know intimate details about
agp. Sometimes it has to destroy mappings on the fly for security
reasons (under the i810 for example). The above method is not flexible
enough to do what we need to get done.
> Unification of code into a single module, is not always good.
> Especially if it is a future goal of xfree to support using AGP, without
> neccessarily using DRM.
Why would this be a problem? Granted its two interfaces to worry about,
but they are very similar. If your using agp memory in a ddx module
that supports the DRI, you use the drm calls if direct rendering is
initialized. If your using agp memory without direct rendering enabled
you use the XFree functions. Its not that complex.
> > Also to answer a previous question about not using XFree calls for
> > memory mapping, you have to understand that under most OS'es (probably
> > solaris as well), XFree's functions will only work for root privileged
> > processes. The whole point of the DRI is to allow processes that can
> > connect to the Xserver to do some form of direct to hardware rendering.
> > If we limited ourselves to using XFree's functionality, we would not be
> > able to do this. We don't want everyone to be root.
> How so, specifically for [device] memory mapping?
> The local client hands the local server a shared memory chunk, and says
> "Please map this to hardware for me".
> Or contrariwise, the local client asks the local server "Give me a chunk of
> memory that is mapped to the hardware.
> The X server then complies.
What do you mean here? Do you mean that the Xserver should have the
ability to change the page tables of each client so that they would have
a mapping to the hardware? Sounds horribly complex. I don't know of
any OS which can do this from a user-space. Are you sure solaris can do
this? I'm fairly confident that Linux can not.
(However we could make a kernel driver to do this, but thats alot of
work for no real gain, plus it adds ALOT of complexity to the kernel.
You have to remember that every process running under Linux has its own
individual page tables. This could also be something that could easily
hurt stability, since a bug in the mapping code could now corrupt
another processes page tables.)
> The X server runs as root. It has "direct" access to the hardware.
> The client runs as a regular user. It has proxy access to the hardware
> through the X server.
> What's the problem with that?
Do you mean proxy as in indirect access to the hardware? Or do you mean
proxy as in the Xserver will map the hardware for you?
If you mean indirect, your missing the point. The WHOLE point of the
DRI is to remove latency and overhead from talking to the graphics
device. The acronym DRI stands for Direct Rendering Infrastructure.
Handling this is a secure manner is a difficult problem. If we didn't
care about performance, sure indirect is the way to go (it's alot
simpler problem to solve.) Under certain circumstances we are going to
be sending enormous amounts of data to the hardware (typically hundreds
of MB/s.) Do you really propose that we add a level of indirection to
that much streaming data?
If you do not mean indirect access, but indirect mapping then see the
above comment about how memory mapping works under other OS'es.