Ever since I read Brian Paul post, saying that if he was starting today he probably would chose the C++ language to write Mesa ( http://sourceforge.net/mailarchive/message.php?msg_id=3594551 ), that I've been thinking to myself how to implement a DRI driver in C++ and what advantages would that bring. Recently I had the opportunity to study Radeon driver in detail - when comparing with the Mach64 a lot of things were done differently, but many of the concepts were the same, and quite a few of Keith stuff could and should be made useful for other drivers.
Ever since then I've kind of been obsessed with these thoughts so I've decided that get my hands dirty. You can take a look to the preliminary Doxygen generated documentation in http://jrfonseca.dyndns.org/projects/dri/cpp/html/ and the source of the documentation in the parent directory. Note that the code is not compilable - it only exists for me to draft the interfaces and get the automated documentation, so don't ask me how to compile it! How are things structured: - a set of DRI classes which a DRI driver should inherit and fulfill [mostly complete, see dri.[ch]xx and DRI namespace], independent of Mesa - a Mesa driver C++ wrapper [nothing written yet], which should be independent of Mesa - a generic DRI Mesa driver, which inherits from DRI and Mesa, and with several classes for stuff like: - automated state management - vertex formats (for hardware vertex handling) - vertex buffer construction (and DMA dispatch) - ... and more to come. A driver inherits from the generic driver, completing or overriding the missing bits, and uses the generic objects, also completing or overriding the missing bits, telling things such as: - how to interpolate two vertices - how to lay out hardware vertices in a vertex buffer - how to get/emit DMA buffers. - when is a piece of state active, and how to emit it if it's dirty - ... A few words about "To C++ or not C++, that's the question"... - The DRI drivers and mesa *already* are, to certain point, object-oriented. The difference is that so far there has been no help of the language, so they are not OOP to the full extent. - binary compatibility is not an issue here. The DRI driver is self contained in respect with linking: it only exports two C functions, and most the communication with the outside world is through message passing. Using C++ will not alter in any way this. - no existing or future driver will be forced to use this - templates with the C preprocessor are a pain, and it's very easy debug/maintain that code. With C++ everything is type enforced and much cleaner. - I expect this will lower down the number of lines necessary to write a new 3D driver to less than half. The best part will be that the other half will be shared by all drivers, making possible to bugfix/enhance several drivers at the same time. This will allow: - all developers [if they so choose] to be much more familiar with each other drivers - anyone can do higher-level enhancements without worrying so much about how to do it in all driver. I'm pretty much convinced this is the way to go, and I intend to maintain and use this framework for my future driver work, even if I'm alone on this, as I believe the time I invest on it will be gained in the number and quality of drivers I can write. Comments/suggestions/flames welcome. 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: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
