RE: [Dri-devel] Memory management of AGP and VRAM

[Egbert E. <ei...@pd...>]

Sottek, Matthew J writes:
 > 
 > I for one have been waiting to see much of the graphics driver moved to
 > the kernel as well. From a vendor perspective there is quite a lot to be
 > gained.
 > 
 > 1) If the mode setting can be removed from the X server then we can
 > leverage that module for whatever graphics system is required. Some
 > times we need an X server, some times we need something more like a
 > framebuffer. Putting this in one place is a must.

Moving mode setting from the Xsever does not necessarily mean it has
to go into the kernel.

 > 
 > 2) Providing one place for rendering code would be nice too. We cannot
 > assume that X is the way to go for all customers. If there were a place
 > to put the device dependent rendering code (kernel module or low level
 > library) then we could write X servers or custom graphics interfaces to
 > use that library.

People seem to advocate to utilize OpenGL for 2D rendering on modern
chipsets. It remains to be seem how feasable this alternative is.
However a solution for this already exists.
If we are talking about 3D rendering a solution for this already
in the making with standalone MESA. 
For 2D rendering X has a rather smart infrastructure to map X drawing
requests onto those 2D primitives that are commonly provided by chipsets.
The driver part there is rather lightweight as most of the work is
done by this abstraction layer.
It would be great if this interface could be kept for chipsets that
need 2D acceleration.

 > 
 > 3) Some times you can just do the job easier or better from kernel
 > space.
 > Trapping interrupts instead of polling can save huge amounts of CPU
 > cycles for some usage scenarios. Power management is easier. Sometimes
 > the hardware needs some special memory considerations etc. No need to
 > really harp on any of the details, it is just nice to have the full
 > power of the OS when/if you need it. 
 > 
 > I think the best way to make everyone happy is to try to achieve two
 > things.

I would argue that as little as possible should go into the kernel.
There is no question that the resource handling for buses, DMA and
irq needs to live within the kernel. The same is true for code that
uses DMA. 
However chipset probing/display device probing and mode setting isn't
required to live in kernel space. Portability and system stability 
arguments speak against it. In fact only Apple MAC users seem to
advocate this idea to be able to an initial video mode on their
systems.

 > 
 > 1) A small, device-independent, API that can be used to set modes and
 > do some very simple rendering. I would suggest get, set, put, copy.

Do you suggest to accelerate these and put the acceleration for them into
the kernel? This would mean a longer path from user space. Since the
these operations typically don't deal with huge areas this may mean a 
signifficant performance penalty.

 > That would allow the kernel to render consoles or oopsen regardless of
 > the mode (debugging the kernel on top of your X session?), and allow
 > for any API of the month to make use of some very basic functionality.
 > Mode setting should just be small as well, leave all the one-off
 > features for extensions. No need to clutter an API with features that
 > are rare.
 > Although the fbdev is already available, I wouldn't suggest that it is a
 > great platform to build on. The mode setting API is really not very good
 > and it does not have modern concepts of twin, clone etc. I think a
 > clean slate design that didn't try to accomplish everything in device
 > independent manner could be a much more attractive target.

Experience has shown that there is almost no way to desing an API so
generic that it can effectively deal with new features that come along
in the future in an effective way.
Soon after XFree86 4 came out graphics cards with what you call twin view 
became available. We had to kludge around to make this work in XFree86.
It was difficult but it was possible because the 4.x driver design was
such that the driver was the controlling instance of everything - well,
almost everything. All the pieces where this was not entirely true -
and the number of heads per chipset was an example here - proved to
be nightmares. 
Therefore the mode setting API should provide a minimal set of standard
features a set of optional features (which may evolve over time) and
allow a chipset specific API that may - over time - move into the 
optional features.

 > 
 > 2) A mechanism to make all the device dependent extensions your heart
 > desires. Then the X servers, opengl libs, etc can just have a DD
 > component to access the hardware specific API. The more things you
 > try to have a device independent API for, the more problems you will
 > have trying to get agreement. Leave the API's to themselves. We should
 > be trying to create a driver model, not a new graphics API. Ogl, X11,
 > DirectFB, etc should be out of scope.
 > 

Right. My experience has certainly shown that almost no assumption we 
have made in the past remained valid over time. The best thing one can
do is to allow for device dependent functionalities, which can - once
we understand them better and find a common base among different drivers
be merged to optional standard features. This will require device 
dependent code in every application that wants to make use of these
features but it allows for much more rapid deployment of new drivers.



	Egbert.