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

Reply via email to