On Sat, Mar 22, 2003 at 10:38:12AM -0700, Brian Paul wrote: > > OK, I'm getting caught up on email and have read through this thread. > Comments follow, and in subsequent messages... > > José Fonseca wrote: > ... > > 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.
Hmm... hence the existence _mesa_init_{context,framebuffer,visual}. That's what I use now in the C++ wrappers too. > 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. Exactly. One of such factories (for textures) will be ctx->driver.CreateTexture, which isn't used now. > I may start working in this direction soon. Great. > > ... > > 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. That's what I'm considering, but there will always have to be a few callbacks: - the factories you mentioned above - a few hardware abstractions for software TCL/rasterization (most noticeably, triangle primitives and framebuffer access) > [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.] I know, but the mere fact that we all appear to be in sync makes me more confident that we must be on the rigth track. > > ... > > >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. I understand. This isn't very important (the points above were ordered by decreasing importance, and simultaneously in the order I plan to tackle them) and it isn't still very clear if it would yield any significant advantages for the C++ framework. I would like to avoid having a redirection call, but it seems almost impossible (except perhaps with some voodoo assembly and some luck with the C++ ABI). Anyway, an extra redirection call is nothing compared with a well structured C++ driver framework, so I'll leave this concern to a later time. > You're welcome to create a new branch in the Mesa CVS tree to do your > experiments. Thanks. > Just clear it with me before you merge anything into the > trunk! :-) Of course! ;-) José Fonseca ------------------------------------------------------- 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