From: Daryll S. <da...@va...> - 2000-08-02 15:01:41
|
On Wed, Aug 02, 2000 at 06:24:23AM +0100, Andrew James Richardson wrote: > As I understand it glide DRI in being thought about as a future project > that is having the glide API not just the OpenGL API working over DRI. I was > wondering what your thoughts were on the problem of name mangling using a > glide2ogl wrapper, viz, > > Client -> Glide -> OpenGL -> GLX -> Glide(DRI) -> hw > > using --wrap to the linker and buggering around with the glide3x source code > I could get something working but I'd not like to update it over new > releases of glide. Am I missing something obvious that everyone knows about > binutils but me? The problem seems to be (as I'm sure you know) that an > object file name is only used as a mechanism to locate symbols in object > files, once my client has loaded glide2x (with all the dummy stuff in there) > then it does not go looking for glide3x.so (DRI) and load that and evern if > it did how would it tell the difference between the one it's suposed to call > and the one it's not. I think you may have misunderstood what we're talking about when we say Glide over the DRI. Let me see if I can explain. Right now the picture looks like this: Client -> OpenGL/GLX -> Glide as HAL (DRI) -> hw In this layout the Glide(DRI) is really a hardware abstraction layer. The only API exposed it OpenGL and Glide(DRI) only works with OpenGL. It isn't useful by itself. There are a few Glide only games. 3dfx would like to see those work. So the current solution, shown above, doesn't work since the Glide API isn't available. Instead we need: Client -> Glide as API (DRI) -> hw Right now Mesa does a bunch of the DRI work, and then hands that data down to Glide. Also Mesa does all the locking of the hardware. If we're going to remove Mesa, then Glide now has to do the DRI work, and we have to do something about the locking. The solution is actually a bit more complicated. Glide wants to use all the memory as well. We don't want the X server to draw at all. Glide will turn off drawing in the X server and grab the lock and never let it go. That way no other 3D client can start up and the X server can still process keyboard events and such for you. When the Glide app goes away we just force a big refresh event for the whole screen. I hope that explains it. We're really not trying to encourage people to use the Glide API, it is just to allow those existing games to run. We really want people to use OpenGL directly. Another interesting project that a few people have discussed is removing Glide from the picture at all. Just let Mesa send the actual commands to the hardware. That's the way most of our drivers were written. It would simplify the install process (you don't need Glide separately) and it might improve performance a bit, and since we're only doing this for one type of hardware (Voodoo3+) Glide isn't doing that much as a hardware abstraction layer. It's some work. There's about 50 calls from Glide we use and those aren't simple, but it might be a good project for a few people to tackle. - |Daryll |