> Strange... When the 3 * screen size is checked an error message is produced and DRI > is given as disabled in the X log. Sorry for misinformation. After detailed investigation, I found the complain. It just was not prefixed with [drm]:))) So I need 13440K:(((((
> Even yesterday Leif and I briefly discussed this on the IRC meeting and > unfortunately ther seem to be some limitations in Mach64 itself :((( Why can't you say something nice sometimes? > regarding this, i.e., as far as we know it's not possible to put none of > the front back and depth buffer on AGP. So unless we dismiss the back > buffer I don't see how this restrition will go away. (I don't know how > Windows copes with this neither - it's something I still have to check). Is there a way to check in with Windows drivers? It would be very interesting... Well, about "back buffer" - what would be the penalty of dismissing it? > >> Yes. Either start X with gdb or attach gdb after X starts but before > >> changing resolution from a remote terminal, e.g.: > >> Then reproduce the segfault, i.e., change the resolution in this case, > >> the gdb command line should reapper. Type 'bt' and post the result. > >OK. I will try. At the moment, I don't have network and second computer but I managed to find in X log - crash is caused by signal 11. And the situation when it appears a bit strange. I can safely switch VTs when I run just "X" from VT1. Even from login screen of gdm I can switch to VT1. But after I log in into gdm - after this point switching to VT1 causes signal 11. Well, tomorrow I'll try to use gdb remotely... About changing resolutions: well, I can do it in most cases. But when vmware changes the resolution (in full screen mode - AFAIK it does it using DGA, isn't it?) - X crashes the same way. > Yes, there are some situations, but they don't depend on the available > memory and/or screen resolution. So if is this what you were talking > about then the difference in fps come solely from less texture trashing. No, I mean they depend on using different GL effects (anti-aliasing, multi-texturing etc). So in some cases I have HW 3d (and it is reasonably fast) - but in some "bad" cases glclock switches to SW - and goes VERY slow. BTW, playing with different resolutions (Using Ctl-Alt-+/-) I found that fps in glxgears really depend on resolution. Not too much but still: 800x600 - 267 1024x768 - 259 1280x1024 - 251 Same size, 16bpp. A bit funny, isn't it? Regards, Sergey ------------------------------------------------------- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
