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
