On Tue, Jun 25, 2002 at 09:41:16PM +0100, Sergey V. Udaltsov wrote: > >> 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
As I said before I still have to investigate. I can't give more answers until I actually do it. (PS: reboot my machine to windows is not something I do often or even like to do..) >interesting... Well, about "back buffer" - what would be the penalty of >dismissing it? > No double buffering, i.e., you would see stuff getting drawed over the previous frame. If the fps are high, that might get unnoticed, but not otherwise. >> >> 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? This phenomenon was already discussed once here. It has to do with competition over the video memory bandwith between the GPU and the DAC. Jos� Fonseca ------------------------------------------------------- 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
