Messages in this thread | | | Date | Fri, 3 Sep 2004 20:54:31 -0400 | From | Alex Deucher <> | Subject | Re: New proposed DRM interface design |
| |
On Sat, 4 Sep 2004 01:12:16 +0100 (IST), Dave Airlie <airlied@linux.ie> wrote: > > Okay I've had some thoughts about the DRM interfaces and did some code > hacking (drmlib-0-0-1 branch on DRM CVS , very incomplete) > > Below is my proposal for an interface that does introduce a major new > binary interface (the biggest issue with a straight core/personality split > for DRI developers, we have enough binary interfaces in our lives)... > > Any comments are appreciated, the document is also available at: > http://dri.sourceforge.net/cgi-bin/moin.cgi/DRMRedesign > > Dave. > > This documents a proposed new design for the DRM internal kernel interfaces. > > The current DRM suffers from a number of issues with multiple drivers in > the same kernel (the mess that is the drm_stub.h and parts of drm_drv.h) > along with the DRM() macros show this up. This design tries to address > this issue without introducing any major new binary interface. > > I propose a 3 way code split- > DRM core > DRM library > DRM driver > > This is slightly along the lines of the fb where the core is fbmem + co, > the library is the cfb* object and the driver is the graphics chipset > specific. > > What I would like to do for the DRM is not as extreme as the fb approach. > I propose the following type split: > > DRM core - just the stub registration procedure and handling any > shared resources like the device major number, and perhaps parts of sysfs > and class code. This interface gets set in stone as quickly as possible > and is as minimal as can be, (Jon Smirls dyn-minor patch will help a fair > bit also). All the core does is allow DRMs to register and de-register in > a nice easy fashion and not interfere with each other. This drmcore.o can > either be linked into the kernel (ala the fb core) or a module, but in > theory it should only really be shipped with the kernel - (for compat > reasons the DRM tree will ship it for older systems). > > DRM library - this contains all the non-card specific code, AGP > interface, buffers interface, memory allocation, context handling etc. > This is mostly stuff that is in templated header files now moved into C > files along the lines of what I've done in the drmlib-0-0-1-branch. This > file gets linked into each drm module, if you build two drivers into the > kernel it gets shared automatically as far as I can see, if you build as > modules they both end up with the code, for the DRM the single card is the > primary case so I don't mind losing some resources for having different > cards in a machine. > > DRM driver - the current driver files converted to the new > interfaces, I don't mind retaining some of the templating work, I like the > fact that we don't have 20 implementations of the drm probe or PCI tables > or anything like that, so I think some small uses of DRM() may still be > acceptable from a maintenance point of view. >
Will this redesign allow for multiple 3d accelerated cards in the same machine? could I have say an AGP radeon and a PCI radeon or a AGP matrox and a PCI sis and have HW accel on :0 and :1. If not, I think it's something we should consider.
Alex - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |