José Fonseca wrote:
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.
First, be aware that glEnable is one of the simplest functions in Mesa - it doesn't serve as a good representation of the big picture.
Keith mentioned error checking. In the case of glEnable, all we have to do is check that we're not inside glBegin/glEnd and record an error if the enum parameter is invalid. Pretty simple.
Other state-change functions are far more complicated. For example, the gl[Copy]Tex[Sub]Image() functions require LOTS of error checking. The texture_error_check() function alone is more than 270 lines long!
The nice thing about the current system is that by time the driver's Enable or TexParameter, or TexImage command is called we've already error-checked all the parameters and calling context. I'm pretty sure that we don't want to deal with GL error checking in all the drivers.
You might consider writing helper functions that just do error checking for all the GL functions. But that would be a _lot_ of functions. And in some instances it's difficult to isolate all the error checking at the beginning of a GL function (thus you may need error_check_foo_part1(), error_check_foo_part2(), etc.)
There'd be a lot of code duplication too. When testing for GL_INVALID_ENUM, for example, you'd effectively have to do the "switch (enumParam)" twice - once to error check, a second time to set state.
> Continuing with the Enable() example, it would be nice to duplicating > avoid the 'switch' on the enum in both RadeonEnable and _mesa_Enable.
The idea of implementing glEnable() with a hash table and having a bunch of little enum-specific enable/disable functions is interesting but I'm not sure it's the right solution.
Would glEnable be the only function that used that mechanism? That would make it a bit of an odd-ball. I'd rather see a consistant interface for all state-change functions. What we have now is pretty good in that regard.
Consider _mesa_TexParameterfv() or similar functions if you persue this path.
Note: I'm not trying to discourage you. I think it's great that you're taking a critical look at this stuff.
-Brian
------------------------------------------------------- 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
