Hi Mark, On Sun, Mar 02, 2003 at 02:12:20PM -0700, Mark Mueller wrote: > Hello José, > You've missed all of the good snow in Steamboat :). I'm plunking down my > $0.02 for this week on this thread:
Ah! Skiing... :) > ' not to sure where to join in, but I'll start with some background. > Some years ago I successfully architected and implemented a complete C++ > based driver solution (including 2d, a portion of 3d, initialization, > and all other Win2000 kernel mode functionality) for E&S's REALimage > based simFUSION PC simulators. One major thrust behind this was because > the configuration options for the family of hardware products were > dynamic, extensive, and included all reasonable combinations of the > following: > > . Different types and amount of video RAM > . RAMDACs from various vendors > . Various versions and interleaves of multi-sample 2d/3d rendering chips > . Vast variations on firmware and video post processing algorithms > . A small family of DMA/PCI/AGP devices > . Hardware bugs unique to any number of configurations > > Relative to my expectations the C++ based architecture worked > brilliantly. As the system powers up the low level driver queries the > hardware/system configuration and instantiates the appropriate objects. > C++ didn't bring anything to the table that couldn't be accomplished > with #define, but it was certainly a much better facility for the > architecture I wished to achieve - and the final product did not have a > single #define outside of reused code. > > Now, from my POV the two biggest architectural wins were a readable and > easy to use software representation of the plethora of convoluted > hardware registers, and a significant compartmentalizing/modularizing of > functionality. Testimony to this was the fact that college grad new > hires would invariably be making code contributions within the first > week on the job. > > In all honesty C++ played only a partial role in this achievement - > something much bigger had transpired. So, IMHO it is important for you > as an architect to avoid the practice of thinking "C++ has this > capability, I should find a way to use it in DRI". Instead adjust your > perspective to a conceptual level that C++ embodies, perhaps by defining > atomic functional units and hierarchies of the graphics functionality in > various dimensions. For example you have both 2d and 3d rendering and > state in software and hardware; you have initialization, steady state > running, and idle; and, you have kernel low level, kernel operation > level, and user level. > > Try letting the lines between X, Mesa, DRI, and DRM as well as C++ > features fade for a while. When I architected simFUSION I started by > roughly architecting a hardware register level, then I added an > "operations" level on top of that which encompassed the core operations > on the hardware registers. The hardware and operations levels then grew > and subdivided into devices, like DMA, RMADAC, PCI, etc. .... Eventually > you will find that most of the bigger pieces, like Mesa, X, and DRI > begin to fall into place. The discrepancies are your opportunity to > improve the design of the graphics pipe as a whole. Thanks for sharing your experience. Perhaps my previous comment gave the impression that I was guiding my analysis by the features of the C++ language. I assure you that it isn't the case - that was just an attempt to an objective avaliation whether a C++ subset such as EC++ could be used. > The above is my own experience, and YMWV. For me the conditions were > ideal because I had complete autonomy, I set and kept my own schedule, > and I also participated in the hardware design. I'm constrained by the external interfaces. The 3D driver will have to speak to Mesa/libGL, the 2D driver and the DRM. So the external interfaces are actually defined - all I can do with them is give an OOP wrapper which is more intuitive. This leaves us with everything in the middle ground. Since it will have to support such a range of different hardware, the approach I'm taking is to supply a good set of building blocks. The driver will provide the glue for a subset of those building blocks. It's like Linus described in a previous post with the kernel filesystem helper functions, but here we won't have helper functions, but helper objects instead, which the drivers can use or extend. > I'd be glad to share the > full hierarchy and the finer derails offline if you wish. I'd appreciate to see the hierarchy. I'm sure that there are some concepts that can be taken, and it will be good education too. > Finally, you will want to proceed with caution. Your analysis of the > architectural change is worthwhile but, very few veteran low level > software developers welcome the sight of C++. Adoption is remote and > will heavily depend on clearly demonstrated advantages and improvements > over existing methods. This is significant undertaking that shouldn't be > rushed. Thanks for the feedback. Regards, José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
