From: Philip B. <ph...@bo...> - 2003-05-11 06:22:33
|
On Sun, May 11, 2003 at 07:52:24AM +0300, Levent Yavas wrote: > putting mesa and hw code into libGL.so may speed up things a bit, for > direct rendering case. maybe seperate libGL's, one for direct only one > for indirect only rendering? just like libMesaVoodooGL on 3dfx hardware. Actually, Mesa is being positioned for more direct hardware rendering, potentially bypassing X, even. Some cards allegedly are supported by mesa in this manner already. They have special tagged source branches that reportedly can handle direct rendering to some ATI cards, I believe. tag "embedded-1-branch" or some such. To those people that this sounds interesting, I suggest you join the mesa-dev mailing list, and "encourage" people to not bias it so that it only works with the DRI kernel driver. The reason being that the DRI kernel driver is really irritating to port. It is way overly complex, if all you want is something that lets a user with full register access, use hardware accelerated rendering. DRI has too much card-specific kernel-level required hooks. I dont know of one supported card that has "fallback" modes like utah-glx has, if AGP or DMA or IOCTL_DRM_SPECIAL_CALL is not available Unfortunately, I guess asking for "no bias" may be a little too late, as they may be pulling in stuff from DRI directly into the tree. So either requesting extra code be added, or possibly even writing the fallback code yourself, may be the best course of action. > but for one really needs for speed, putting hardware drivers onto glide > api is the best. Funny, I would say it would be best to put hardware drivers into the OpenGL api ;-) Remember, what we're doing with utah-glx is technically GLX, not straight OpenGL. Mesa provides the OpenGL part, and we just provide implementations for portions of that. Doing pure OpenGL is somewhat easier, once you have the registers and videoram mapped. |