On Thu, 2003-02-27 at 18:32, José Fonseca wrote: > On Thu, Feb 27, 2003 at 03:47:14PM -0800, Ian Romanick wrote: > > José Fonseca wrote: > > >Multiple inheritance and virtual inheritance is, IMHO, essential to > > >design reusable objects for the drivers. Without this and no templates, > > >there wouldn't be much difference between were we stand now. > > Correction: I was confusing virtual inheritance with virtual > methods in general... > > I was planning to use multiple inheritance, but this can be easily > avoided. Virtual inheritance only make sense with multiple inheritance > so it's not important. > > > The reason pure-virtual methods were removed is because the compiler has > > to emit code to check for NULL method pointers. I tend to agree with > > this rationalle. It's also easilly worked around in a way that doesn't > > require build-in compiler NULL-pointer checking. In think with more > > recentl compiler technology this may be less of an issue that it once was. > > Pure-virtual methods aren't removed in the EC++ standard. But those > NULL-pointer checking can be avoided then by simply definining a no-op > of those methods. > > In summary, we can follow a few EC++ guidelines to keep the genereated > code clean and efficient, but templates is out of question here. > The only way to avoid them would be by replacing templates by generic > functions with abstract arguments, and that would suck bigtime. > > José Fonseca
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: ' 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. 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'd be glad to share the full hierarchy and the finer derails offline if you wish. 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. Cheers, Mark -- Mark Mueller <[EMAIL PROTECTED]> ------------------------------------------------------- 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
