From: David D. <da...@tu...> - 2002-03-28 21:56:40
|
On Thu, Mar 28, 2002 at 02:28:26PM -0700, Jens Owen wrote: >David, Alan, Jeff and Kevin, > >I understand you would prefer a class of modules that are both HW >specific and OS specific. Currently, the number of OS's supporting the >DRM is 2; and the number of OS's the IHV's care about is 1 (linux x86 to >be specific). So, there is no short term problem with persuing your >model of having an extra module for each HW and OS combination. No, I'd prefer that the HW and OS specifics be separated as cleanly and completely as possible. I've just had some uncertainties about how the solutions proposed so far achieve that. >It is the long term I'm concerned about. If XFree86 aspires to have >good 3D support for more than just one or two OS's, then an extra module >for each HW and OS combination becomes a problem. Agreed. >The drmCommand approach allows OS specifics and HW specifics to be >seperated and follows the excellent principle set by the 2D DDX driver. >I have completely removed the Linux specifics from the drmCommand >interface. Attached is my latest patch against the tcl-0-0-branch. >Please let me know if you see any OS portability limitations in this >current interface. If you see any portability limitations that can't be >fixed, I'll fall back and implement the 300+ combined HW and OS specific >sub module approach. This assumes that using OS-independent tokens (like those below), and any associated data structures, can be accepted by a HW-independent layer (drmCOMMAND) and executed correctly. I guess that if the HW-independent component is just a mechanism for passing them transparently through to the kernel component (or equivalent), then that is workable providing all different OS implementations of the kernel component (for given HW) can accept the same set of tokens and data structures. What hadn't been clear to me is whether that's possible/feasible. I guess the HW dependencies in the current DRM library would be pushed up into the video driver (and possibly down into the kernel module). >+/* Driver specific DRM command indices >+ * NOTE: these are not OS specific, but they are driver specific >+ */ >+#define DRM_RADEON_CP_INIT 0x00 >+#define DRM_RADEON_CP_START 0x01 >+#define DRM_RADEON_CP_STOP 0x02 >+#define DRM_RADEON_CP_RESET 0x03 >+#define DRM_RADEON_CP_IDLE 0x04 >+#define DRM_RADEON_RESET 0x05 >+#define DRM_RADEON_FULLSCREEN 0x06 >+#define DRM_RADEON_SWAP 0x07 >+#define DRM_RADEON_CLEAR 0x08 >+#define DRM_RADEON_VERTEX 0x09 >+#define DRM_RADEON_INDICES 0x0a >+#define DRM_RADEON_STIPPLE 0x0c >+#define DRM_RADEON_INDIRECT 0x0d >+#define DRM_RADEON_TEXTURE 0x0e >+#define DRM_RADEON_VERTEX2 0x0f David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com |