Re: [Dri-devel] Ann: nightly snapshots resumed
Hi all They are only bleeding-edge snapshots because the DRI cvs HEAD no longer can produce binary compatible snapshots. All new snapshots require to download and install XFree86-4.2.99.2 server from http://dri.sourceforge.net/snapshots/extras/ . The 'install.sh' script attempts to determine your XFree version but this may still be buggy. Please report any problems with that. OK, just took it. First, the script really determines the version - but allows to proceed. I think it should break unconditionally at this point. Also, X server from ../extras just does not work. It break with signal 11.:( Same thing happens after installing dri drivers - this just makes no difference. I use plain XFree from RH8.0 (sure, everything is gcc 3.2-built). Any simple explanations? Regards, Sergey --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: nightly snapshots resumed
I'll have to fix this, probably by using a seperate install.sh for mach64, or by specifing the necessary XFree86 version on the package describing file. Great. But why X server from 2.99.1 is not compatible with mach64?? I though I should not break things at least. Why does it? Anyway, I'll try mac64 driver with old XFree and report. Actually, about a week ago I tried mach64 snapshots on my new RH80 and noticed some instability - it crashed at some random points (not too frequently but still annoying). Unfortunately I could not notice any pattern in these crashes. Anyway, I will take the new snapshot and try. -- Sergey --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] stable branch created
This will be the site for the first stable binary snapshot, and will target XFree86 4.2.x installations. A couple of easy questions: 1. Which version of gcc will be used? 2. Will these snapshots have mach64 dri? 3. Will these snapshots have gatos xv/tvout merged (question to Leif)? Sorry, I could not get the answers from this mailing list (probably you discussed them on IRC meetings). Regards, Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] celestia and multitexture
anyhow i found that it still crashs when one goes to saturn or any other ringed planet, from searching the forums on celestia i found that it seems to be due to multitexture problems in dri or mesa BTW, I can confirm. Even with old (gcc296) binaries I have the same problem with Saturn and others... Sergey --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver feature table
New columns for gamma, ffb, mach64, virge, sis and trident. Great work! Looks really impressive (and makes me feel really proud that my chip is not the worst one:). A couple of easy questions: is it true that Mach64 feature list is final (sure I do not mean fallback). Also, 3 features are marked as SW - is it good to expose them? It's actually not my question (someone already asked here before). Probably we could make exposition of non-HW-supported features optional (through XF86Config param)? Really, why inform application about things which are going to be slow? Or SW implementation of ARB/EXT_texture_env_* is fast? Regards, Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] snapshots
We also haven't recived feedback regarding non-radeon cards. I would be happy to give some feedback on mach64 - but I am using Leif's spanshots now (2.96-built AFAIK) - just because they give me xvideo. Leif, are you still using 2.96 or moving to 3.x? Regards, Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] snapshots
I haven't tried the snapshots and I haven't heard from anyone using the vanilla snapshots without my patches yet, so I'm not sure if there are any problems there. Well, at least I can confirm that in my mostly 3.1-based system (at least the kernel and XFree are 3.1-built) your 2.96-based snapshots do work without any hassle. So probably 3.x snapshots would not be that bad for 2.96 folks?... Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snapshots now being built with gcc 3.2
Hi Jose I've updated my workstation to the RedHat Linux 7.3.94 beta, which has gcc 3.2. So now forward the snapshots will be built with this version. AFAIK this shouldn't pose any problem to the users since the key issue is that the kernel modules are compiled with the same version of gcc that compiled the kernel, and that still holds true. Is it your workstation which is used to built snapshots? I thought it was SF machnery... The Mach64 development on my side is still on hold. Besides the hassle of returning from vacations, and have a lot of stuff to do, my laptop's hard drive is busted so I've been working at the univeristy were I don't have any Mach64 card near me. Hopefully I should receive a new drive shortly. Sad. Really expected fast mach progress after your return. With security resolved and gatos merged (thanks to Leif again) it could go into XFree86 HEAD... Anyway, glad to hear from you again Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XVideo code merged from XFree86 CVS
That merge only applied to Radeons, and was merged to the DRI trunk, so it doesn't affect the mach64 branch. XFree86 CVS still doesn't have XVideo support for mach64. Thanks, I see now. I just do not understand why Vladimir does not merge XVideo/mach64 into XFree86 CVS. Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
You could compile a static server, and debug it that way. I've found that to be much more reliable. Well, at the moment all I have is snapshot binaries. I'm afraid I cannot afford (actually, my HDD) to build the whole DRI tree:( OK. I will try to get stack trace one more time - next week. Cheers, Sergey --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SIGSEGV on VT switch
I've tried to use remote debugging and got the backtrace of the SIGSEVG: Program received signal SIGSEGV, Segmentation fault. 0x0841e74e in ?? () (gdb) bt #0 0x0841e74e in ?? () #1 0x083fbca7 in ?? () #2 0x083198bb in ?? () #3 0x080b7e05 in ProcCopyArea () #4 0x080b58d7 in Dispatch () #5 0x080c808d in main () #6 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 Is it useful in any way? I'm afraid binary snapshots are stripped so I did not expect too much info:( Would be grateful for any clarifications/further directions Regards, Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
The problem is that stock gdb doesn't know about XFree86 modules. There are patched versions of gdb for that, but even so you can get more information by calling the LoaderPrintSymbol function for each of the addresses before a '??', i.e. at the gdb prompt: call LoaderPrintSymbol(0x0841e74e) Really? I tried one more time. First of all, the stack trace is different this time (which is funny itself) and this LoaderPrintSymbol does not help much: ** (gdb) continue Continuing. Program received signal SIGUSR1, User defined signal 1. 0x420e198e in select () from /lib/i686/libc.so.6 (gdb) bt #0 0x420e198e in select () from /lib/i686/libc.so.6 #1 0x in ?? () #2 0x080b574a in Dispatch () #3 0x080c808d in main () #4 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0841efee in ?? () (gdb) bt #0 0x0841efee in ?? () #1 0x083fc3ef in ?? () #2 0x08593603 in ?? () #3 0x080fddd3 in ShmRegisterFbFuncs () #4 0x080fedab in ShmRegisterFbFuncs () #5 0x080b58d7 in Dispatch () #6 0x080c808d in main () #7 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) call LoaderPrintSymbol(0x08593603) $1 = 1 (gdb) call LoaderPrintSymbol(0x083fc3ef) $2 = 1 (gdb) call LoaderPrintSymbol(0x083fc3ef) $3 = 1 (gdb) call LoaderPrintSymbol(0x0841efee) $4 = 1 (gdb) cont Continuing. I dont't think this is more informative. Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
The output went into the /var/log/XFree86.0.log (or to the console where you started the X server), not to the GDB screen. Yes!!! What I got: 0x841eb84 ATIMach64SetDPMSMode+46a Module /usr/X11R6/lib/modules/drivers/atimisc_drv.o Section .text 0x83fa220 XAA+21cf Module /usr/X11R6/lib/modules/libxaa.a:xaaFallback.o Section .text 0x8593558 XAACopyArea+ab Module /usr/X11R6/lib/modules/libxaa.a:xaaCpyArea.o Section .text So the problem seems to be in ATIMach64SetDPMSMode! What about DPMS things in DRI branch? Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Capturing debugging info without networking
Good boys! Can anyone invent the way to do the same thing with gdb? So on X crash one could get backtrace without remote debugging... Cheers, Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 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
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
I just tried to run my X in 1280x1024/24bpp (before it was 16bpp) and lost DRM! I got it back only in 800x600/24. Now when we have AGP textures working - what are the restrictions on resolutions/color depth? Still no answer..:( Could please anyone tell me why I cannot get 1280x1024/24bpp with AGP texturing? Is this fundamental restriction or just temporary problem? Should this [3 * screen size] be in video memory or total AGP memory would suffice? Also, I noticed X server crashes while changing the resolution (as well as switching to another VTs). Is there a way to track this in order to help fixing? Also, I found another nice GL testing app - glclock. It looks really gorgeous. And it shows a lot of cases where Mach64 still uses SW rendering - the difference in fps is really impressive:) Regards, Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
Is there anything reported on /var/log/XFree86.0.log or /var/log/messages? Nothing. In XFree86.0.log there is no word about DRI! I presume it is because of this 3*screen size restriction. Should this [3 * screen size] be in video memory or total AGP memory would suffice? The 3 * screen size restrition refers always on the video memory. And will it always be the same? 1280x1024/24bpp is ... a bit more than my humble 8M:( 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. I didn't followed you. What do you mean with SW rendering and which two situations do the difference in fps refer? I mean indirect (software) rendering. Mach64 uses it in some situations, doesn't it? So one can really feel the difference... 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
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
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
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
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..) Looking forward... 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. :) This phenomenon was already discussed once here. It has to do with competition over the video memory bandwith between the GPU and the DAC. I thought so. Thanks for comments, 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
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
8 MB AGP 1280 x 1024 @16bpp, 1024 x 768 @24bpp That's what I have now. 1280x1024 16bpp. And able to run OpenGL apps perfectly. Note that an 8MB PCI card could get 1280x1024@16, but there would only be ~191kB left over for textures, which isn't likely to be useable. Well, but I even run counter-strike in this resolution! Or do I miss something? Well, it's desktop resolution - cstrike runs in 1024x768 window. Does this matter? If anyone is able to run a GL app in Windows at a higher resolution than those listed, please post the maximum resolutions you can use. Make sure you are looking at the actual resolution used by the app, not the desktop resolution. OK. I will do my best to check this. 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
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
Vid. mem Card type Max. 3D resolutions
- ---
4 MB Any 800 x 600 @16bpp, 640 x 480 @24bpp
6 MB PCI 1024 x 768 @16bpp, 800 x 600 @24bpp
6 MB AGP 1152 x 864 @16bpp, 800 x 600 @24bpp
8 MB PCI 1152 x 864 @16bpp, 800 x 600 @24bpp
8 MB AGP 1280 x 1024 @16bpp, 1024 x 768 @24bpp
Also, one more question (I already asked it some while ago but hopefully
the answer has changed):
Is this the desktop resolution on X startup or on GL program startup? So
if I start X in 1280x768x16bpp and then run glapp in 800x600 - will it
leave more video memory for textures?
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
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
That's what I have now. 1280x1024 16bpp. And able to run OpenGL apps perfectly. I assume you're referring to Window here, right? I don't think the current cvs will enable DRI at this resolution yet. Well, I run it with DRI/Linux+XFree4.2.0. My screen resolution is 1280x1024 16bpp: Subsection Display Depth 16 Modes 1280x1024 1024x768 800x600 And I do have DRI working for me. Surprise?:) Do you have an AGP card? With an AGP card, you have plenty of space for Yes I do have AGP 2x in my laptop Mobility. textures in AGP, so 1280x1024 should be useable with 8M of card memory. But not in 24bpp:( Are you saying that in Windows you can have a 1280x1024 desktop, but cstrike will only run at a max of 1024x768? That would be possible on a PCI-only card with dynamic buffer allocation. In LINUX I have 1280x1024 desktop and run cstrike in 1024x768 (using wine from Transgaming, sure). 16bpp, naturally. 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
[Dri-devel] Mach64 with AGP: still some restrictions on resolution/depth?
Hi all I just tried to run my X in 1280x1024/24bpp (before it was 16bpp) and lost DRM! I got it back only in 800x600/24. Now when we have AGP textures working - what are the restrictions on resolutions/color depth? Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] merge with Gatos
Hi all I recently asked the question about merging Mach64 DRI with Gatos project - and got no answer. So, now I am trying to use xine - and found that mach64 dri snapshots do not properly support XVideo extension (at least in YUV overlay area). So could please anyone tell me what are perspectives of this merge? I realize it is the lowest priority issue but I hope it is not that difficult - now when 2D acceleration is already somehow enabled in DRI driver... Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] gcc 3.1: finally OK but VT still problematic
Hi all Finally, I've got my kernel built with gcc 3.1 (actually, my problems were in some mystical gcc296 in some compat package). And - wow - mach64 0-0-4 branch works for me! Great thanks to everyone. Even 2D seems to be OK these days. The only problem I noticed is VT switching. When I switch to the first VT, my X crashes. What could this be? Any way to track? Great thanks to all of you folks. Sergey Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: atimisc_drv.o relies on drm
: Well, I built kernel 2.4.18-0.26 (from RH Rawhide SRPM) and got much trouble. The worst of it that my vmware does not work any more:( The vm* modules are built OK but I get OOPS loading them. Well, but even drm does not work any better. I rebuilt mach64.o again and still get those Permission denied messages. Any clues? Regards, Sergey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DRM: Permission denied: even for root?
mach64_state.c:682: warning: concatenation of string literals with __FUNCTION__ is deprecated. This feature will be removed in future Yes. I noticed this doo But it's only warnings. I think so. (II) ATI(0): [drm] loaded kernel module for mach64 driver (II) ATI(0): [drm] drmSetBusid failed (6, PCI:1:0:0), Permission denied (EE) ATI(0): [dri] DRIScreenInit Failed Exactly what I have. So we assume it's gcc:((( Is it possible to do something here. I would not like to downgrade to gcc 2.96 (to much pain) but still would like to use binary snapshots. Is it a big job to make drm directory buildable by gcc3? I could try to do it myself - just tell me where to put debug statements... So I have the same permission problem and it only occurs with gcc 3. :(( Does this mean gcc 3 sucks?:) Actually, transition from 2.96 to 3.1 was not easy - had to rebuild all c++ progs... Sergey, does your X-server lock up, too? No. I did not notice this. Just no DRM... Regards, Sergey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Log of today's IRC
Jens Please not that Jose is talking about the Mach64 driver specifically, on this bullet item. Thanks I realize this - this is exactly what I am interested in.:) Sergey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DRM: Permission denied: even for root?
Again and again I take snapshots, again Permission denied even for root. What could this be? Can it be related to gcc 3.1 I use to build the kernel module in the snapshot? Really strange situation to me... Regards, Sergey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Log of today's IRC
Hi I believe it's not clear - as it isn't evident for myself either. I think that evolution will be: Thanks for all these explanations. At least this text can be interpreted as a kind of roadmap. - the _fastest_ implementation possible will be achieved in the very near future, after the DMA is fully functional. I think this is certain. I am really glad here. That's exactly what I asked yesterday:) Regards, Sergey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 DRM: Permission denied: even for root?
Hi all Just took the latest (27.05) drm binary snapshot for Mach64. And cannot get DRI working any more. In XFree86.0.log I see: drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) ATI(0): [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied (EE) ATI(0): [dri] DRIScreenInit Failed Even if I start just X from root shell! How is it possible? What's wrong with my configuration? It seems DRM security reached the highest possible level:) Cheers, Sergey ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach64 DMA, blits, AGP textures
Hi all So, I took the first snapshot with textures - and ready to say something good. Well, DRI now works even in 1280x1024 - great thanks to Leif and others. At least I don't have to modify XF86Config every time... 1. glxinfo - OK, usual report. 2 glxgears does not show me any real difference in the speed (something around 280). Sometimes I see a bad thing: Couldn't alloc placeholder sz 1 ofs 2 Memory heap 0x80723e8: Offset:, Size:0001, U. Offset:0001, Size:00010200, .. End of memory blocks In dmesg: [drm:mach64_dma_dispatch_vertex] *ERROR* mach64_dma_dispatch_vertex: empty placeholder list in DMAADVANCE() 3. celestia _always_ crashes - same type of error messages (same in dmesg). 4. counter-strike runs. Though 1024x768 - does not run:( Hope my error messages will help. Cheers, Sergey ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] little fix for install.sh
Sergey, sorry for replying only now. For some time I was planning to apply That's OK. Everyone understands that actual work on the driver has incomparable higher priority. The problem is that the existence of those dri-old files are the only proof that anything was installed before. If we default to delete files when there is no backup then someone mistakenly trying to restore with no previous installation (or, e.g., accidental second restore) will delete all the drivers, and I think that this can be far more annoying than having a dummy mach64.o floating around. I see the point. My only concern is that when I do restore - I actually do not change my XF86Config in the DRI section. So I am a bit afraid that XFree would try to use the module (without other parts of the snapshot). If you tell me it's not a danger - I am ready to forget about all this stuff. Cheers, Sergey PS Hope you won't forget to announce AGP-mapping-enabled binaries - I am eager to hand my laptop. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] little fix for install.sh
Hi all I know, this is going to sound stupid in the list discussing textures, mappings etc.. but I found another little buggy in the install.sh script (in mach64 binary snapshots). This script moves existing binary objects (for example, mach64.o) into dri-old prefix and restores them back when asked. But if mach64.o had not not exist before the installation - it just ignores this fact and does not remove the installed one. So Jose, could you please fix this? Just check existence (if [ -f ) of $.../dri-old.$FILE - and rm -f $.../$FILE. Cheers, Sergey PS It's not easy but sometimes interesting to follow the Texture management threads. Also, the feeling that you are ... well, one step, from AGP mapping in Mach64... - it's really exciting!:) ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
fixing this :) Anyway, you should not expect 2D + 3D acceleration too soon. OK. At least - thanks for explanation. problems right now (especially on the mach64 branch :). :)) I see. It makes sense. I solved both the resolution and 2d acceleration problems for me by having two X servers installed, one with 2d acceleration and high resolution and one with 3d acceleration and low resolution. When I want to test DRI I start the 3d server as display :1 on vt8. I don't even have to exit my 2D session for that. :) Well, but current binary snapshots do not allow me to do this, don't they? I would love to be able to do this too. It is a bit annoying to restart X session each time I want to play... Regards, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. I really don't know but... Well, it works now (snapshot 0502). No OOPS detected. In my syslog I see: May 2 20:31:23 localhost kernel: [drm] Creating pci pool May 2 20:31:23 localhost kernel: [drm] Allocating descriptor table memory May 2 20:31:23 localhost kernel: [drm] descriptor table: cpu addr: 0xc08a4000, bus addr: 0x008a4000 May 2 20:31:23 localhost kernel: [drm] Starting DMA test... May 2 20:31:23 localhost kernel: [drm] starting DMA transfer... May 2 20:31:23 localhost kernel: [drm] waiting for idle... May 2 20:31:23 localhost kernel: [drm] waiting for idle...done May 2 20:31:23 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode Does it mean DMA works for me? AFAIK it does. BTW, does synchronous mean there will be asynchronous somewhere?:) About FPS - they are still lower than in good old user-mode MMIO... (241 vs 286 in 0-0-3). But DMA is already enabled - does this mean I will never get anything better? Well, glxgears works OK. So does Counter-Strike. As usual, in texture-intensive apps (celestia) we are waiting for GART... Anyway, thanks for fast fix. Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Yes, that's the goal. Synchronous DMA means that we wait for the card to idle after submitting each DMA pass, rather than going on to do other things and polling or handling interrupts to check for completion of the DMA transfer. Synchronous operation isn't meant to be fast, it's just a first step in testing that we are submitting the DMA pass correctly. That's exactly what I thought. Good, I am not that dumb... Probably eventually I'll grow smart enough to join the team:) Any estimations on speedup we'll get in glxgears? Sure. Let us know if you experience a lockup again. There will be some big changes coming in the drm in 0-0-4 soon, so it's likely to be a bit unstable for a while. COOL. My laptop is eager to be crashed by new snapshots. Just announce GART or asynchronous DMA - and it is yours. BTW, it was mentioned it was easy to enable 2D acceleration back. Is it true? Can it be done in snapshots (by checking this illustrious pATI-directRenderingEnabled). So people could use snapshot drivers in everyday life - without restarting X... Also, just one question - if I set in XF86Config Modes 1280x1024 800x600 - could I have DRI enabled in 800x600 (switching by Alt+Gr-) - though I don't have enough video RAM for 1280x1024? Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Do you use some framebuffer device? To the best of my knowledge - no. You can start to give us the last lines of /var/log/messages, as I think that there should be a kernel oops in there. The XFree86.log may be interesting too. YESS! There is OOPS. See attached. Cheers, Sergey May 1 20:50:56 localhost kernel: [drm] Creating pci pool May 1 20:50:56 localhost kernel: [drm] Allocating descriptor table memory May 1 20:50:56 localhost kernel: [drm] descriptor table: cpu addr: 0xc0318000, bus addr: 0x00318000 May 1 20:50:56 localhost kernel: [drm] Starting DMA test... May 1 20:50:56 localhost kernel: [drm] starting DMA transfer... May 1 20:50:56 localhost kernel: [drm] waiting for idle... May 1 20:50:56 localhost kernel: [drm] waiting for idle...done May 1 20:50:56 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode May 1 20:51:02 localhost kernel: [drm] freeing descriptor table from pci pool May 1 20:51:02 localhost kernel: Unable to handle kernel paging request at virtual address 5a5a5a5a May 1 20:51:02 localhost kernel: printing eip: May 1 20:51:02 localhost kernel: c01aec39 May 1 20:51:02 localhost kernel: *pde = May 1 20:51:02 localhost kernel: Oops: May 1 20:51:02 localhost kernel: CPU:0 May 1 20:51:02 localhost kernel: EIP:0010:[pool_find_page+25/128]Not tainted May 1 20:51:02 localhost kernel: EIP:0010:[c01aec39]Not tainted May 1 20:51:02 localhost kernel: EFLAGS: 00013096 May 1 20:51:02 localhost kernel: EIP is at pool_find_page [kernel] 0x19 May 1 20:51:02 localhost kernel: eax: 5a5a5a5a ebx: 5a5a5a5a ecx: 5a5a5a5a edx: d0c48000 May 1 20:51:02 localhost kernel: esi: 5a5a5a5a edi: 5a5a5a5a ebp: 5a5a5a5a esp: d0b23e84 May 1 20:51:02 localhost kernel: ds: 0018 es: 0018 ss: 0018 May 1 20:51:02 localhost kernel: Process X (pid: 1383, stackpage=d0b23000) May 1 20:51:02 localhost kernel: Stack: c0321a84 0001 3296 5a5a5a5a 5a5a5a5a 5a5a5a5a cde3d000 c01aecbf May 1 20:51:02 localhost kernel:5a5a5a5a 5a5a5a5a 5a5a5a5a 0001 d0bd8bcc cde3d000 d0b23f48 cde3d000 May 1 20:51:02 localhost kernel:d2987cb6 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a d298d720 006c 0002 May 1 20:51:02 localhost kernel: Call Trace: [pci_pool_free+31/240] pci_pool_free [kernel] 0x1f May 1 20:51:02 localhost kernel: Call Trace: [c01aecbf] pci_pool_free [kernel] 0x1f May 1 20:51:02 localhost kernel: [mach64:mach64_do_cleanup_dma+154/196] mach64_do_cleanup_dma [mach64] 0x9a May 1 20:51:02 localhost kernel: [d2987cb6] mach64_do_cleanup_dma [mach64] 0x9a May 1 20:51:02 localhost kernel: [mach64:__insmod_mach64_S.rodata_L304+17424/26288] __insmod_mach64_S.rodata_L304 [mach64] 0x4410 May 1 20:51:02 localhost kernel: [d298d720] __insmod_mach64_S.rodata_L304 [mach64] 0x4410 May 1 20:51:02 localhost kernel: [mach64:mach64_dma_init+173/196] mach64_dma_init [mach64] 0xad May 1 20:51:02 localhost kernel: [d2987d8d] mach64_dma_init [mach64] 0xad May 1 20:51:02 localhost kernel: [mach64:mach64_ioctl+239/256] mach64_ioctl [mach64] 0xef May 1 20:51:02 localhost kernel: [d2982d97] mach64_ioctl [mach64] 0xef May 1 20:51:02 localhost kernel: [sys_ioctl+535/560] sys_ioctl [kernel] 0x217 May 1 20:51:02 localhost kernel: [c0143907] sys_ioctl [kernel] 0x217 May 1 20:51:02 localhost kernel: [system_call+51/56] system_call [kernel] 0x33 May 1 20:51:02 localhost kernel: [c0106ecb] system_call [kernel] 0x33 May 1 20:51:02 localhost kernel: May 1 20:51:02 localhost kernel: May 1 20:51:02 localhost kernel: Code: 8b 00 8b 54 24 20 eb 39 8b 04 24 89 c2 89 44 24 04 8b 72 10
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. OK, thanks. So it will be a part of today's build, won't it? I will take and test it tomorrow... Report will follow... Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How much video memory isneeded?
From this moment the mach64 binary snapshots in http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the 0-0-4 branch. Thanks. Just tried. Well, it seems 0-0-4 has long way to go:) First, I just run install.sh and restarted X. I got segmentation fault on glxinfo - after displaying most (or all?) of the info in xterm. Then glxgears just did not want to start - some drmMach64Clean... (sorry, I forget to write it down) returned -22. What could this be? Well, then I wanted to stop X and switched to vconsole 1 - and the whole display froze (but not the whole system!) - so I managed to reboot correctly. After this point, I managed to run X and even run glxgears and glxinfo without problems (though glxgears gives 268fps vs 286 in 0-0-3 - anyway, better than 191 in Mesa). Anyway, X is still unable to shut down gracefully - at killall X in xterm I get frozen screen (though Ctl-Alt-Del works as if I were in console). In XFree86.0.log DRM is reported on (glxinfo has same idea). Well, later I will play more... BTW, is there any way to check whether DMA is on or off? Can I see it in /proc/dma? Thanks for your efforts, Lazy tester Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
It seems that the mach64 kernel moduled wasn't replaced from memory, causing a kernel oops. Usually you need to run install.sh without X running (I usually do init 3). Well, at least with 0-0-3 I managed to do in without stopping X. Just install.sh and restarting X was enough. OK, if you tell 0-0-4 _requires_ me to stop X before installing... There shouldn't be much difference since DMA is off. (DMA at this time even slows things more) I am aware of it. So I do not expect too much:) better than 191 in Mesa). Anyway, X is still unable to shut down gracefully - at killall X in xterm I get frozen screen (though Ctl-Alt-Del works as if I were in console). mmm.. I don't see what it could be. Is there any way I can help do find the reason? As said, there could be some problems with the install.sh not replacing everything properly. That's the more likely. Again, how can I debug this? No. There isn't any yet. But we can arrange to something be printed on the system log when the DMA is enabled on runtime. That would be nice. Also, Leif offered to turn DMA on if bus mastering is detected. Is it possible to do it in today/tommorow snapshots? Just to test... Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
In the previous 0-0-3 branch we almost never messed with the DRM, so it
was binary compatible between all snapshots. Now is exactly the opposite.
Nevertheless you shouldn't need to stop X if you're running your distro X.
You need only if you are running X from a mach64 branch, because in this
situation the kernel module is being used and the install.sh script will
surely fail to remove it from memory.
I run ATI.2 drivers from GATOS. AFAIK this should not cause problems,
should it?
Please check that the mach64.o in the kernel, the mach64_dri.so and the
ati_{drv,misc}.o files in your system were indeed updated by install.sh
script. (They path should popup if you run locate with their name).
OK. I will do and report.
Putting the check will take a little more than that (I have a paper
submission deadline in 1 June and I'm barely starting to do the research I
proposed to do in that paper, so I'm a great deal of pressure to get
Best luck with this.
results ASAP), but I can put the DMA by default so that the interested
ones can try. In the worst case, they can always use the
mach64-0-0-3-branch.
For me it's OK. I'm just afraid I'm not the only tester in town:)
PS: Don't remove the working mach64-0-0-3 snapshot that you may have, as
they will eventually get deleted from the DRI website.
Thanks for warning. BTW, probably it would make sense to move them to
separate directory - so people would know where to look more-less
stable:) drivers... Also, even after purging, the latest 0-0-3
snapshot would be nice to leave on FTP. Just in case... 1.5M is not very
large volume...
Cheers,
Sergey
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
Hi I cleaned up all modules and run 0-0-4 from clean state - still same lockup on X termination. Actully, I get the lockup not in termination but in attempts to switch to any textual console.:( The reason is that I've changed the dripkg/install scripts sometime, and I Could you please give me a tip - which lines exactly you changed last days... Regards, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64: How much video memory is needed?
Actually, Leif is right. DRI really works on 1024x768 but... very slow (thanks to PIO?). My Rage Mobility cannot run Counter-Strike properly (the game is unplayable in this mode). In 800x600 it is quite OK. Sure, I mean good old branch 0-0-3... Waiting for 0-0-4 binary snapshots, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64: How much video memory is needed?
I'm now trying mach64-0-0-4-branch with Rage Mobility-M PCI (LR). The compiled X server does not work in a setting more than 800x600 16bpp. How much video memory is needed to use Mach64 DRI in general? I bet you have 8M video RAM! So do I. Today, Mach64 DRI driver does not use GART so it cannot use system memory and we are restricted by the amount of video memory. The team first is going to enable DMA, then - GART (at least I was told so some time ago). So just wait and see... Waiting for 0-0-4 binary snapshots, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Helping on Mach64, was: New cards (GPU's) from oldcard makers? DRI support?
At this moment I'm trying to debug to make things work barely before I'll make a new branch: mach64-0-0-4-branch. But tommorrow I'll create it Wow! So would you mind giving a shout here when something testable appears on FTP? So finally, did I get it right about this new branch?: 1. A lot of code is moved into DRM module 2. No real DMA yet. 3. DMA emulation is slow. How do you think - will 0-0-4 finally be really slower than 0-0-3? Also, will 0-0-4 someday have DMA - or there will be 0-0-5 for it? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa MMX blend code finished
I've finally ( hopefully) finished the rewrite of Mesa's MMX blend code. Is it already in binary snapshots? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weekly IRC
Just FYI, the weekly IRC mtg will start in ~30 minutes. That's 5pm Eastern time now that we're on daylight savings time in the US. ... Any logs available for the public? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa software blending
But the OpenGL spec says that the fog color is calculated on a _pixel_ basis and not on a _vertex_ basis. Indeed the result is different, especially in long polygons that span from the front way to the back. Does 4 do pixel-based fog? Mach64 is able to do the fog properly, i.e., on a pixel basis, but _not_ Why? I know - it's only ATI who can answer this question...:) when alpha blending since it uses the path on chip. So the problem is only what to do when both fog and alpha blending are enabled. Are there many apps using this effects together? The solution of using these depending of the contents of a env var is a compromise so that gamers achieve a better gameplay sacrifying a little the visual quality and the OpenGL conformance. Actually, end users in 80% (or 99%?) do not specially care about conformance. The visual quality really matters. There are other situations as this one. Leif checked on Unreal and there is one (also when alpha blending) that happens and according with his experiments reverting to software leads to a severe performance hit. It was predictable, wasn't it? And any predictions about _visual_ difference between these two methods? Will users see the difference easily? Say, if you get 10* speedup with 5% worse quality (I do not really know how to measure it though:) - almost nobody will really use SW mode. Cool! And the default version will be HW-based non-conformant, won't it? This is very subjective, but if we assume that DRI aims to be OpenGL conformant, I vote for sw-based conformant... :)) I see your point. Again real life vs standards:). It's time for new poll on dri.sourceforge.net:) BTW, I can seriously recommend 3ddesktop as a test tool. It supports several effects (blending, textures, etc. with on/off switching) so its behavior could give a lot of hints to the developers. I'll check it. Thanks a lot. I'm not lobbying it. I just like it - and would like it to work properly on Mach64 - today I have a lot of problems with it - which I don't have in pure SW mode. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa software blending
Does 4 do pixel-based fog? yep. So in some cases it is much slower than 3, isn't it? It's because they are quite similar operations so they use the same chip logic. In fact you have a bit to choose wether you want alpha or fog. It's was design option. So they did not want to have two instances of the same logic on a single chip to implement this rare combination, wont they? Don't know, but a transparent window in a foggy level is not a situation very hard to happen... I see. In this case the visual difference can be very big... Sad. Shame to ATI!:) Thanks for all these clarifications. They're really interesting matters for me. Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] Re: [Dri-devel] Mesa software blending
After all these interesting and informative discussions, everyone has forgotten the start of the thread:) Basically, there should one answer to the question whether and how blending+fog can be implemented . Possible variants: 1. Yes, it can be done with hardware acceleration. DRI team knows how. 2. No, it cannot be done. DRI team knows why. 3. Possibly yes but actually no. ATI knows but DRI will never know (NDA issues) 4. Possibly yes but now DRI team does not know exactly how... Which answer is the correct one? After this question is answered, we (users/testers) could get the idea whether we'll finally have HW implementation or DRI will use indirect rendering here. Actually, here is the point where CPU power does not really matter. What really matters is possible/impossible and know/don't know (sure, add want/don't want:) BTW, just tested mach64 driver with 3ddesktop. _Really_ fast but there is a lot of artefacts and incorrect rendering. Probably, it's buggy app (version 0.1.2:) but not necessarily. Could anyone please try and comment an experience? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa software blending
He!He!.. you missed!! It's a mix of variant 1 and 2..! :) Cool. At least 1+2 is the answer (call it 5). Thanks. As Leif previously said is his reply, it can be done in hardware by messing the colors of the vertex to incorporate the fog (as software Mesa used to do in 3.x) but it's non-conformant to the OpenGL spec. What's the difference in Mesa 4? Is it better? Can it be done in HW? Will this non-conformance cause visible problems on display? So the solution found is to do it either like this or by software depending of the value of a environment var. Cool! And the default version will be HW-based non-conformant, won't it? As you can guess implementing this is not a high priority. I see. Well, CPU power does matter if the user is inclined to choose the conformant way and do software fallback. If it's just one envvar - this solution will satisfy any user (except for one who want GeForce performance for the price of Mach64:). The fact that the mach64 driver needs several software fallbacks to be really OpenGL conformant is one of the reasons for my interest in improving the Mesa sw rendering. (Which I must correct you, was the _real_ start of the thread :) You're right. I missed the start. And quality SW rendering is still very important issue. BTW, I can seriously recommend 3ddesktop as a test tool. It supports several effects (blending, textures, etc. with on/off switching) so its behavior could give a lot of hints to the developers. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64 binary snapshots: little bug in install.sh
Hi all I think it if for Jose. One little bug in the install.sh. It runs ldconfig even if /usr/X11R6/lib is in ld.so.conf. So probably ldconfig should be put together with adding /usr/X11R6/lib to ld.so.conf (i.e. inside if statement). Not really a bug, just annoying thing (to wait for ldconfig to complete). Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Mach64 texture fix
I found that calls to TexParameter were not setting the texture wrapping and texture filter in some cases (where the driver private texture object struct had not already been allocated). This is now fixed and solves the following bugs: Well done! It seems armagetron is really fixed. Sergey PS Just played my first Counter-Strike lunch-time match without rebooting to WinME! No problems noticed at all (800x600). BTW, under WinME/Win2000 people play in Software mode so it's only me who uses 3D acceleration:). There were some problems with sounds - but it's wrong mailing list...:) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 notex,tiny vertex formats
I've commited code to enable notex and tiny vertex formats for mach64. Cool! I've got the first playable version of Counter-strike(WINE, GL mode, 640x480, screen res 800x600). Great cudos! Though I have to admit there are some problems. 1. After closing glxgears, there were some pieces of the gl window remaining on the screen. These pieces could be easily erased by moving other windows. Also there are artefacts after tunnel and fog. 2. gltron really flies. But at the end of the game I encountered some bad effects. In most cases, it is video subsystem hang. Once, I was able just to kill the server (Alt-Bksp), another time the whole system hung:(( 3. I am not 100% sure but it seems some textures in armagetron are either lost or rendered incorrectly. I took the latest snapshot (today, 20pm) Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 Tuxracer doesn't work
Quake II: perfect Wow! What is your resolution? What are fps? How much memory does your card have? Half-Life in 640x480 (under Wine though) is really unplayable for me...:( Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch multitexture fix
I just downloaded it and was getting good fps. Check ~/.ArmageTronrc and make sure the GL_RENDERER line says Mesa DRI Mach64 Maybe your SDL library isn't using the right libGL? Strange, I have different situation. Yes, armagatron does use the right opengl library. What is your card? What are your fps with/without DRI? Cheers, Sergey PING_CHARITY 0 MAX_IN_RATE 4 MAX_OUT_RATE 4 SERVER_NAME FINISH_TYPE 2 GAME_TYPE 1 AUTO_AIS 1 NUM_AIS 19 MOVIEPACK 1 ZTRICK 0 MOUSE_GRAB 0 WRAP_MENU 0 SPARKS 1 TEXTURES_HI 1 PREDICT_OBJECTS 1 LAG_O_METER 1 INFINITY_PLANE 0 SKY_WOBBLE 1 LOWER_SKY 1 UPPER_SKY 1 DITHER 1 HIGH_RIM 1 FLOOR_DETAIL 1 FLOOR_MIRROR 1 SHOW_FPS 1 TEXT_OUT 1 SMOOTH_SHADING 1 ALPHA_BLEND 0 PERSP_CORRECT 1 POLY_ANITALIAS -1 LINE_ANITALIAS 1 MESSAGE_OF_DAY_4 MESSAGE_OF_DAY_3 MESSAGE_OF_DAY_2 MESSAGE_OF_DAY_1 The server admin was too lazy to set a message of the day... ARMAGETRON_VERSION 0.1.4.9 GL_VENDOR Gareth Hughes GL_RENDERER Mesa DRI Mach64 20020227 [Rage Pro] x86/MMX/SSE GL_VERSION 1.2 Mesa 4.0.2 GL_EXTENSIONS GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_convolution GL_EXT_compiled_vertex_array GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_object GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_MESA_window_pos GL_NV_texgen_reflection GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_pixel_texture GL_SGIS_texture_edge_clamp TEXTURE_MODE_3 9984 TEXTURE_MODE_2 9984 TEXTURE_MODE_1 9728 TEXTURE_MODE_0 9728 COLOR_R_4 15 COLOR_G_4 15 COLOR_B_4 3 CAMWOBBLE_4 0 AUTO_INCAM_4 0 SPECTATOR_MODE_4 0 INSTANT_CHAT_STRING_4_1 LOL! INSTANT_CHAT_STRING_4_2 :-) INSTANT_CHAT_STRING_4_3 :-( INSTANT_CHAT_STRING_4_4 Well done! INSTANT_CHAT_STRING_4_5 Almost got you... INSTANT_CHAT_STRING_4_6 Hehe! INSTANT_CHAT_STRING_4_7 Got one! INSTANT_CHAT_STRING_4_8 INSTANT_CHAT_STRING_4_9 INSTANT_CHAT_STRING_4_10 INSTANT_CHAT_STRING_4_11 INSTANT_CHAT_STRING_4_12 ALLOW_CAM_4_0 1 ALLOW_CAM_4_1 1 ALLOW_CAM_4_2 1 ALLOW_CAM_4_3 1 ALLOW_CAM_4_4 1 START_FOV_4 90 START_CAM_4 3 CAMCENTER_4 1 PLAYER_4 Player 4 COLOR_R_3 3 COLOR_G_3 3 COLOR_B_3 15 CAMWOBBLE_3 0 AUTO_INCAM_3 0 SPECTATOR_MODE_3 0 INSTANT_CHAT_STRING_3_1 LOL! INSTANT_CHAT_STRING_3_2 :-) INSTANT_CHAT_STRING_3_3 :-( INSTANT_CHAT_STRING_3_4 Well done! INSTANT_CHAT_STRING_3_5 Almost got you... INSTANT_CHAT_STRING_3_6 Hehe! INSTANT_CHAT_STRING_3_7 Got one! INSTANT_CHAT_STRING_3_8 INSTANT_CHAT_STRING_3_9 INSTANT_CHAT_STRING_3_10 INSTANT_CHAT_STRING_3_11 INSTANT_CHAT_STRING_3_12 ALLOW_CAM_3_0 1 ALLOW_CAM_3_1 1 ALLOW_CAM_3_2 1 ALLOW_CAM_3_3 1 ALLOW_CAM_3_4 1 START_FOV_3 90 START_CAM_3 3 CAMCENTER_3 1 PLAYER_3 Player 3 COLOR_R_2 3 COLOR_G_2 15 COLOR_B_2 3 CAMWOBBLE_2 0 AUTO_INCAM_2 0 SPECTATOR_MODE_2 0 INSTANT_CHAT_STRING_2_1 LOL! INSTANT_CHAT_STRING_2_2 :-) INSTANT_CHAT_STRING_2_3 :-( INSTANT_CHAT_STRING_2_4 Well done! INSTANT_CHAT_STRING_2_5 Almost got you... INSTANT_CHAT_STRING_2_6 Hehe! INSTANT_CHAT_STRING_2_7 Got one! INSTANT_CHAT_STRING_2_8 INSTANT_CHAT_STRING_2_9 INSTANT_CHAT_STRING_2_10 INSTANT_CHAT_STRING_2_11 INSTANT_CHAT_STRING_2_12 ALLOW_CAM_2_0 1 ALLOW_CAM_2_1 1 ALLOW_CAM_2_2 1 ALLOW_CAM_2_3 1 ALLOW_CAM_2_4 1 START_FOV_2 90
Re: [Dri-devel] mach64-0-0-3-branch multitexture fix
Little test report about the latest builds: In a word: cooler than ever. The snapshot runs and installs without any problems. I run it on 8M Rage Mobility in 800x600. About the apps: 1. glxinfo - OK. Standard report. 2. glxgears - 283fps. OK. No problems. 3. celestia - as usual, not enough texture memory, so most of the planets are just grey balls. Waiting for AGP mapping... 4. gltron - OK. No problems. Stable 21-22 fps - playable. 5. counter-strike - WOW!!! First time in my life it runs in wine in opengl mode, shows not only pistol - but the full environment. Still VERY (unacceptable) slow. Hopefully after DMA introduction it will get better... 6. Various GL screensavers - OK. No problems. Thanks for all those wonderful things... Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch multitexture fix
One more app... 7. armagetron. Works OK but ... with the same or worse fps (comparing to GATOS 2D-accelerated driver)! How can this be? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do work! Was: do not work...
But now that you touched on the subject, why don't you help on the development as well!? Well, I'd be glad but there are some problems. Unfortunately I am already involved in 2 projects (my own GSwitchIt and SQL/jEdit) so I simply has no time for anything else (well, I do not count my family:). Also, I has no background in 3D development, so the learning curve for me would be too long. I am trying to do my best in testing but I am afraid for foreseeble future it is the only way I can afford. Though, at some point hopefully I'll be happy to join the team. BTW, is there a way to get the wonderful DRI devel FAQ as a single document (in PDF or - better - in HTML format)? I'd like to have it in my Visor but I could not find it:( Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Announce] New mach64 snapshot
Please check the new package. Nothing really new, except that the things you noticed (should) have been fixed. I've run the installation uninstalltion process fine. I didn't have time to really start X because it's pretty late here (as you can see by the build time). Just tried. The installation was really smooth. But running was bad enough. The screen got blank and I have to reboot the system remotely:((( In the XFree86.0.log: (II) ATI(0): [drm] installed DRM signal handler (II) ATI(0): [DRI] installation complete Symbol drmMach64CleanupDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64InitDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! Fatal server error: Caught signal 4. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] Symbol drmMach64InitDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! Symbol drmMach64CleanupDMA from module /usr/X11R6/lib/modules/drivers/atimisc_drv.o is unresolved! FatalError re-entered, aborting Caught signal 11. Server aborting Any ideas? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do work! Was: do not work...
The latest snapshot, http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/mach64-20020314-1601-i386-Linux.tar.bz2 works. I've checked it myself. I checked it too. No installation problems noticed. Everything went smoothly. glxgears works on 248fps. The problem was libdrm.a which is not as device independent as thought. :( Well, anyway it is not as big as libGL. It has some interface functions which in the case of mach64 are new and not available in the XFree86 4.x releases. What's good is that now we know it - so next releases will be more smooth. I also noticed that the snapshots of mach64-0-0-3-branch don't work on Xfree86 4.1.0, since the 2D driver ABI changed between the releases. I suppose it's the same for all driver snapshots taken from the trunk, althought that was not my previous impression. What about compatibility with 4.0 (or even 3.3)? I guess for brave testers like me even compatibility with 4.2 is enough... Sergey, please test once more. If everything is okay, I'll start uploading the mach64 snapshots to the DRI website as well. (And put a README describing the current limitations of mach64) I'd say I have no objections:) It is very cool when someone asks me permission to upload something (especially - something I did not develop:) Regards, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Announce] New mach64 snapshot
I'm hammering my head against the wall at this moment!! You're completely right, all those files should be let alone! :P :) Please keep your head in cool dry place. We really need it. Luckily, the libs that came with your X 4.x should be just fine - less stuff for download. That's better! From what Frank said in the beggining there will be no AGP texturing, In the beginning - will it be tomorrow, next week or next 3 months? Just estimations - when we'll get our lovely binary snapshots.. only DMA, i.e., you'll experience a general speedup in preformance (number of triangles per second), but you'll still be limited to the memory your card have, so applications that make heavy use of textures (i.e. games) will have most of the same problems if high-res textures or high screen-resolutions are used. I see. And how long do you (or Frank) think it will take to do AGP texturing? I realize it is much easier to ask question when? than hack the real code, so don't bother too much answering me:) Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
Well.. this can take a few days since I have to get some time to mess with these scripts. Sorry. Take your time. Stabilizing things after 0-0-3 branching has definitely much higher priority. It is not a big problem to rebuild these objects. But - just to make it easier - could you please make i810_dma.c and i830_dma.c compilable (they give error messages about some wait identifiers - so I just have to comment out these lines). Is it a result of not complete merging or what? Does the X log says Direct Rendering Enabled or Direct Rendering Disabled? (II) ATI(0): [drm] installed DRM signal handler (II) ATI(0): [DRI] installation complete (II) ATI(0): [drm] Added 128 16384 byte DMA buffers (II) ATI(0): [drm] Mapped 128 DMA buffers at 0x40c18000 (II) ATI(0): Direct rendering enabled If it does says it's enabled then the problem is related with libGL.so somehow. If it doesn't then it's related to the kernel module / X. I am pretty confident it is libGL. But the version used by glxinfo is /usr/X11R6/lib/libGL.so.1.2 Any ideas? Regards, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
make -f Makefile.linux mach64.o Thanks. I did not know. I just did make I just noticed the error about dynamic loading: libGL cannot load /usr/X11R6-DRI/lib/modules/dri/mach64_dri.so. I think it is the error in your build scripts. They should use X11R6 directory instead, arent' they? After I created the link from X11R6 to X11R6-DRI - everything is fine (more or less, to the current state of the driver). Thanks for the help. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64 binaries: do not work
Hi all There are problems with the bleeding edge binaries: 1. First of all, the kernel module cannot be loaded because of some unresolved symbols. And even when I do rm *.o, make, the resulting mach64.o has some unresolved symbols (on depmod)! I do not know how it is possible. insmod -f manages to load this bad module, but I do not know how... 2. Well, I run updated X but glxinfo shows there is no DR - and the driver is usual mesa:( Ldd informs me about correct libGL and libGLU used for glxinfo. Any ideas? In X log, I do not see any errors reportes - it seems DRI is loaded as necessary Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
The .o shouldn't be packaged, or even built. I'll have to check why this is happening. Well, hope the next version will be free of these wrong object files. Could you please past the output of insmod to see what are the failed symbols? Well, now it is OK. Sorry for disturbing on this issue. For some reason, it took the old version of mach64.o (bundled with tarball). Now I really rebuilt it - and still no success in point 2. The module loaded without problems. 2. Well, I run updated X but glxinfo shows there is no DR - and the driver is usual mesa:( Ldd informs me about correct libGL and libGLU used for glxinfo. Any ideas? In X log, I do not see any errors reports - it seems DRI is loaded as necessary So, still same situation... No DR, just Indirect Mesa. Can it be the problem of XFree 4.2.0 based on old Mesa? Well, first let's try to figure out the first problem as this second one could be a side effect. No, it is not... Any other ideas? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 work
I haven't started working on these, so if you choose one of these to work there there wouldn't be chance of we repeating same work. I'll keep updating all other mach64_* files until their are in sync with Mesa 4.x and then start on the file of these that you don't choose or help in any other way. Is this ok with you? Just hope, after all these wonderful texture-related changes, you wont forget to update (and notify us testers) binary snapshots:) Cheers, Sergey PS Thank for new slim tarballs. Less then 2 megs - it is cool! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Bleeding-edge Was: Mach64 work
Automated binary snapshots of the mach64-0-0-3-branch built in every 4 hours from now on are available on http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/ . Great! Be aware though that at this moment this won't be of much use unless you also want to help debugging the segfaults. Thanks for the warning. Just please give a shout when it is testable, OK? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
hmmm.. the only way I see to make everyone happy (I'm already seeing Sergey complaining about the size of the download! ;-) is to make two sets :)) I do not like to complain as much as you can think:). But GATOS binary snapshots drivers are only 190K! Even if dri will be 5 times larger - it will still be OK. At least for me. of drivers: - one with everything included, including debugging info - another with stripped binaries and without the libraries that do not interfere with the direct rendering (i.e., libGLcore and libGLX) Just one question: which, if any, of these sets is going it be compatible with XFree 4.2.0? Or Mesa 4.0-compatibility makes this impossible? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64: some programs
Hi all Tried to run the Mach64 dri-enabled driver and ... 1. Openuniverse and celestia - still no textures. I've heard some talks about DMA, thought it is already working. Is not it? I know, without DMA my 8M is not enough for 1280x1024... 2. Counter-strike/wine in OpenGL mode. I see only my pistol - no environment at all:) Also in console, a lot of messages: mach64UploadTexImages: ran into bound texture What does this mean? Is it bad or good? Is it fixable? 3. About the fog. Really, the problem is not in the fog. The fog demo works OK. 4. About signal 11. It seems the problem was about vt. Everything is OK if I run programs from xterm. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
Hi all Once again, I managed to came through the waters and fires of the updating and building process. Again, got DRM working with my humble Mobility (at least with glxgears/tunnel). There are 2 minor questions: 1. After all these discussions in IRC, I realized that fog in Mach64 is not ready yet. Is it? So the fact I cannot see fog in the tunnel - it is OK for a moment, isn't it? 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Anyway, Jos's effort for packaging is still in very high demand among me, my system, and openuniverse:) Hope others are interested too. Thanks for support to this idea. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
That's because tunnel tries to use alpha blending _and_ fog, which isn't possible on mach64 (we're looking into a workaround though). If you OK. For a moment, I just will remember this fact. 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Hmmm, I haven't seen that. Post the logs and we can take a look. OK. With my pleasure. Actually, almost all the stuff in this file is from the initialization. Till the line Open APM successful. Actions: 1. In vt1, I do /usr/X11R6-DRI/bin/X 2. In vt2, I do DISPLAY=:0.0 glxinfo.. 3. Switch to vt4. The whole system crashes but glxinfo returns some sensible data. If I use glxgears instead, it runs till I stop it (by Ctl-C in vt2) and X terminates with the same signal 11. Does it have something to do with vt management? Cheers, Sergey This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.1.99.1 (DRI mach64 branch) / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 20 August 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Build Operating System: Linux 2.4.17-0.12 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Tue Feb 19 23:39:31 2002 (==) Using config file: /etc/X11/XF86Config Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor gw (**) | |--Device gw (**) |--Input Device Mouse1 (**) |--Input Device USBMouse (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbKeymap en_ru_de (**) XKB: keymap: en_ru_de (overrides other XKB settings) (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7000 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6-DRI/lib/modules,/usr/X11R6-DRI/lib/modules/multimedia (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6-DRI/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6-DRI/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card 107b,9300 rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 03 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 03 class 06,80,00 hdr 00 (II) PCI: 00:08:0: chip 125d,1978 card 107b,9300 rev 10 class 04,01,00 hdr 00 (II) PCI: 00:0b:0: chip 11c1,0448 card 1668,2000 rev 01 class 07,80,00 hdr 00 (II) PCI: 00:0c:0: chip 104c,ac40 card 4000, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:0c:1: chip 104c,ac40 card 4800, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:0c:2: chip 104c,8011 card 107b,9300 rev 00 class 0c,00,10 hdr 80 (II) PCI: 01:00:0: chip 1002,4c4d card 107b,9300 rev 64 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6-DRI/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6-DRI/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable
Re: [Dri-devel] gl extensions on/off
I think the point is (but I could be wrong) whether this is user-configurable without recoding/recompiling anything, and it seems the answer is no. That's bad. Definitely this is not high-priority issue, but it would be nice to have ability to enable/disable extensions without recompiling apps/drivers/etc. Well written apps should be able to determine which extensions are available (shouldn't them?) so it could be interesting to play with apps using different subsets of extensions. Anyway, thanks to everybody for comments. Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
Any info (or references to documents in XFree tree) would be highly appreciated... Finally, I managed to get and build (and even run) mach64 branch. Thanks to everyone who helped me. Now I use not Jose's binaries but the ones built on my own system. Nothing has changed (what a surprize!:) on my desktop: - 3D works faster than usual - No fog in the tunnel demoapp. - Textures have major problems (for example, on celestia) - 2D works rather slow (comparing to ATI drivers by V. Dergachev) :((( But I noticed the tree is not updating for weeks (the last file is dated 28.10). It seems, the development stopped again... :) :( Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] gl extensions on/off
Sure, an app can always elect whether or not it uses particular extensions. Maybe I'm missing your point. An app? Probably. But some particular (very nice, BTW) apps still very dumb in terms of configuration so I'd like to have ability to turn extensions on/off myself, without modifying the app code (as a user). Anyway, this RFE has priority 0.0001 (where 1.0 is Normal). Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] gl extensions on/off
Why force any application to implement some more or less wide set of external shell varibles to query while the same is much easier to maintain if its part of a gatekeeper library? Exactly! That's what I meant! Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver
mkdir /usr/X11R6-DRI lndir /usr/X11R6 /usr/X11R6-DRI It's already done, thanks to binaries you gave me:) Setting the ProjectRoot in /usr/X11R6-DRI isn't even necessary since is the default already. Really? In which file? site.def contains ProjectRoot /usr/X11R6 but host.def contains /usr/X11R6-DRI. Which one is really used? If you have RedHat 7.x you also have to add the patch that is attached because of a problem in the gcc-2.96 code optimization leading to modules that can't be loaded by the X server. Thanks. Unfortunatly the only reference is the DRI Compilation Guide which has not been updated recently to include this. Someone really should do that because there has been a lot of people trying to test the cvs tree (especially the mach64 branch). Probably I'll be able to write little 10 lines HOWTO and post it here. When I finish the process...:) Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] gl extensions on/off
Hi all Is it possible to turn on/off some particular GL extenstions in Mach64 driver? Is mesa.conf in any help here? I would like to play with texture-related extensions (probable, turning GL_ARB_multitextures off would solve my problems in celestia?) Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] First experience with binary shapshot: part 3,success
3. There are serious problems with textures - in most (all?) apps they are not loaded. Is it me or server or ...? BTW - I found the matter of problem. I have 8M video RAM. And use resolution 1280x1024 (I have LCD so lower resolutions look bad). Even in 16bpp, all buffers take almost 8M - so only 192K remains for textures (actually, on 32bpp the server does not start at all). When I experimentally changed resolution to 800x600 (giving ~5M video RAM for textures) - some textures appeared (but not all - for example, half-life and celestia are still not working). So my question is - will at some point driver use system RAM for buffers and/or textures etc? I thought AGP technology can help here. Correct me if I am wrong. Cheers, Sergey PS BTW, dpms seems to be working too - my laptop was able to suspend and resume correctly. Just in case someone is interested... ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] First experience with binary shapshot
Hi all Thanks to Jose, I got some binary stuff to test: lib/modules/2.4.9-13/kernel/drivers/char/drm/mach64.o usr/X11R6/lib/modules/drivers/ati_drv.o usr/X11R6/lib/modules/drivers/atimisc_drv.o usr/X11R6/lib/modules/drivers/r128_drv.o usr/X11R6/lib/modules/drivers/radeon_drv.o But I did not have much success: 1. The kernel module loaded perfectly. No complains. 2. The driver uses ABI v 5 but XFree 4.1.0 gives ABI version 4. First problem. I had to use -ignoreABI switch. Probably, all subsequent issues causes by this option. 3. A lot of unresolved symbols. Complains about DRILock and DRIUnlock, also drmMach64InitDMA, drm*, DRI*... Did I forgot something to do/download? Probably, I also need X11R6/lib/modules/dri? Or something else? Or should I givup and not test with XFree 4.1.0 (waiting for 4.2.0)? Any comments are more than welcome. Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] First experience with binary shapshot
Probably, I also need X11R6/lib/modules/dri? Yes. driver - dri - kernel module OpenGL - dri - kernel module Jose, please... Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] First experience with binary shapshot
Sergey, it seems that you'll have to download the complete X server or wait... OK. Anyway /usr/X11R6/bin/XFree86 is not that big. Or there are some other files I forgot. Also, could you please add /usr/X11R6/lib/modules/dri/*? I am sure - in the end we'll find the minimal list of binaries necessary for dri/mach64:) Thanks. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] First experience with binary shapshot: part 2
Hi all Finally, I took the stripped binaries (7M). Thanks to Jose again. What's the result? Nothing good. The server starts, but no dri. Actially some gl-related modules have got some problems on load: (II) Loading sub module GLcore (II) LoadModule: GLcore (II) Loading /usr/X11R6-DRI/lib/modules/extensions/libGLcore.a No symbols found in this module Failed to load debug_xform.o (EE) Failed to load /usr/X11R6-DRI/lib/modules/extensions/libGLcore.a (II) UnloadModule: GLcore (II) UnloadModule: glx (II) Unloading /usr/X11R6-DRI/lib/modules/extensions/libglx.a (EE) Failed to load module glx (a required submodule could not be loaded, -1073744008) So later atimisc_drv.o and others have a lot of troubles (errors) resolving gl-related symbols... I checked several times - ldconfig cache does not contain old Xfree/GL stuff. Any ideas/comments? I know I must look pretty dumb... Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
Hi all It seems people are actively testing mach64 branch. So I have a couple of questions: 1. Could anyone please periodically make binary snapshots including only X server, necessary libs and little (~10 lines) readme? 2. Is mach64 driver binary compatible with XFree 4.1.0 or does it depend on some 4.2 APIs? Unfortunately I cannot afford take the whole XFree branch and build it on my machine, but I would really like to play in testing dri/mach64. Thanks a lot, Sergey V. Udaltsov ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
As far as I know this is not so simple as a X server and libs. You also have the kernel modules... and those are tied to the kernel version configuration you have. AFAIR there is a way to build kernel modules without precise kernel version dependance (correct me if I am wrong) - as long as all external symbols as resolved, the module will be loaded. If the problem you have is hard disk space (you need about 500 Mb) you could try to build on a remote machine disk, mounted via samba or nfs. :) If I only had this machine:) There are only 2 machines in the company with Linux: my laptop and server. Nobody is going to let me build something on the server (and it does make sense:). If the problem is slow/expensive internet connection I think that I it would be no problem if I hosted a bzipped tarball of the mach64 branch snapshot. In sources? :( I am not sure it will help me (see above). BTW, what would be the size of the archive (because traffic is an issue for me)? So, the question is: whether there is a way to build kernel modules for generic 2.4.x? Will this cause trouble? Also, my second question is still remaining: will the server and libs be compatible with XFree 4.1.0 from RH7.2 distro? Regards, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
