As I've been writing the Mesa C++ wrappers I've come across some dificulties posed by the way the interfaces are exported. As I progressed I started to realize I was loosing too much time and effort trying to fight the system, and the system in this case - Mesa - needs not to be fought, but adapted to the new needs. Note that the changes I propose aren't just to facilitate the C++ wrappers, they would give a more consistent and efficient interface for C drivers, and are very well in sync with other ongoing efforts on DRI (namely Keith Whitwell's vtxfmt and Ian Romanick's texmem).
1. In the last IRC meeting (relevant part of the log attached) I already focused on one of the aspects in Mesa's driver interfaces which wasn't very convenient: the use of private structure pointers as a mechanism for data inheritance. My proposal is to use structure compositing instead of private pointers. This has the benefits of: - reduced memory allocation overhead and less referencing - more consistency between the base and inherited structures (no more things like driver private texture data having a seperate life from Mesa's texture. - in C++ we can describe inherited classes from mesa substrucutres as easily as subclassing. This means that: - For every overloadable structure in Mesa, there is a function which takes a pointer to such structure and initializes it. - the driver is always the one who allocates the memory (as it's the only one who knows the full base+inhrited structure size), and has to call Mesa to initialize the data strutruture. For many structures, Mesa already has one of the above things. The biggest exception (and biggest advantage) is the texture structure. This is also the way that Ian has organized the texture structure in texmem branch, so it will fit nicely there.
2. On user space, the current drivers are structured (with some exceptions not relevent now) as follows:
Client application
| |
v v
glapi GLX
| |
v v
Mesa DRI
| |
v v
DRI_Driver
|
v
Hardware
And the driver has to fill a Mesa callback function table. But, as Keith
recently said here, there is interest in having the drivers to deal
with the glapi dispatch table directly, in other words:
Client application | | v v glapi GLX : | | : | v : | DRI : | | : v v : DRI_Driver : ^ | : | | v v v Mesa Hardware
That is, instead of Mesa acting as the middle man, it should act more as a library. This specificaly means that, instead of (phony names):
userapp.c: glEnable(GL_TEXTURE);
mesa.c: _mesa_Enable(enum) { // Do its thing here if(ctx->Driver.Enable) ctx->Driver.Enable(ctx, enum); }
driver.c: RadeonEnable(ctx, enum) { // Do its thing here }
It would be:
userapp.c: glEnable(GL_TEXTURE);
driver.c: RadeonEnable(enum) { // Do its thing here _mesa_Enable(ctx, enum) // ... or here }
mesa.c: _mesa_Enable(enum) { // Do its thing here }
This was the initial idea for the mesa 3.5 rework (which resulted in things like the swrast,tnl,etc. modules). I didn't go this far as I felt the 3.5 structure was enough to bite off in a single chunk...
Anyway, the slight trouble you get with this is error checking. Who does it? How does RadeonEnable check if _mesa_Enable succeeded? Also, error checking is tied in with the general structure of the function a lot of the time. Anyway, the code in api_validate.c is a fragment of my original thoughts on this, but won't work so well where error checking can't be easily seperated from the rest of the functionality.
Continuing with the Enable() example, it would be nice to duplicating avoid the 'switch' on the enum in both RadeonEnable and _mesa_Enable.
Keith
------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
