OK, I'm getting caught up on email and have read through this thread. Comments follow, and in subsequent messages...
José Fonseca wrote:
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.
I'm in favor of this. A while back I introduced code to do this with GLcontext, GLframebuffer, and GLvisual. The OSMesa driver uses containment to "derive" struct osmesa_context from GLcontext.
Extending this to texture objects and texture images would be a good follow-on.
In design pattern terms, the drivers will have to provide "factories" which generate texture object and image instances. The factory functions will have to be registered with core Mesa since core Mesa often has to take the initiative to allocate new objects.
I may start working in this direction soon.
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.
As Keith has said, this is the direction he started going back with Mesa 3.5. It kind of turns things inside-out conceptually, and people won't "get it" right away.
The idea is that the hardware driver runs the whole show; the driver treats core Mesa as a collection of subsystems (state tracking, s/w rasterization, s/w TCL, etc) which provide services to the driver.
Going with this approach, it appears that the notion of the driver registering callback functions with Mesa (as seen in dd.h) is kind of backward.
Unfortunately, we've currently got a bit of a mix of these different styles in Mesa right now. We also have a system of dirty bits which track state changes and indicate when derived state must be recomputed or set. One could consider taking that to the extreme and elimining most driver callbacks altogether.
[The reality is this stuff is complicated and the perfect solution has never been obvious. We just have to evolve things as best we can as we go along.]
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 }
Note that, according to the specific case, RadeonEnable may not even xist, or don't call _mesa_Enable at all. And no time would be wasted on doing unnecessary stuff (such as tables lookups, or maintaining irrelevant state). And this may be controled on run-time via glapi. The drawback here is that usually mesa verifies if the state changed before notifying the driver, and this would be lost here - I really don't know how much relevant this is.
I'll address this in another message.
3. Make the glapi get the current ctx pointer and pass it to the functions. If I understood correcly, the drivers will have a per-context dispatch table, which is on thread local storage (TLS). If so, this means that the glapi already knows the current context pointer, so it can pass it to the gl API entries, therefore using one less lookup to the TLS.
This would also make the C++ simpler, and the ctx could be seen as an abstract class, where the disptatch table were member functions. Of course that the C++ call conventions don't allow this be just like that, but from the C++ drivers point of view, it would be so. But this is not the more important.
Unfortunately, we can't change this without breaking the current libGL / driver ABI. I'm _really_ hesitant to go there.
Finally I would like to discuss in which CVS repository the C++ framework and these ideas would go. My preference would be to do it on a branch based on the embbeded branch on Mesa CVS. (This was also briefly discusses in the last meeting).
A side note: if/when these things hit the DRI/Mesa trunks, if nobody else wants to share it with, I take the resposability to update all existing Mesa/DRI drivers. In any case, the changes can be a little time consuming, but will be straightforward.
You're welcome to create a new branch in the Mesa CVS tree to do your experiments. Just clear it with me before you merge anything into the trunk! :-)
-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
