[noveau] Nv03-06 driver source code
Dear Noveau developers, Some years ago, around 2000-2002 there was a guy in New Zealand, David, working on Nvidia drivers, see the message at the Utah-GLX mailing list archive from April 2002: http://sourceforge.net/mailarchive/forum.php?thread_id=612267forum_id=3646 hi I have started a project to build a NVRM witch will hopefully will give as the frist open source high performance dma nvidia driver first i have to build the NVRM this handles a lot of work to make the chip run and grates an unified interface to the hardware so you can have 2 or move clients torking to the hardware at the same time eg. a dvd player a X draw text and a opengl game . it also handles deferencs between the chips NV04 , NV05 , NV10 , NV20 and so on once i have done anuf of the NVRM working to support X and glx i will start on the X and glx clients my site for this project is http://homepages.ihug.co.nz/~lexos i will update as i go now its just the hard work :) Unfortunately the web page is no longer available and the person does not seem to work on nvidia drivers. Anyway, by the time I downloaded the source code and since there now exist a project for Nvidia 3d drivers, maybe parts of the source code can be of use for the Noveau developers. According to the code and some result files DMA and context switching seems to be functional. Also, some header files can be useful. Unfortunately the code is uncommented has no licence information (except for one nv03 header file), no README etc. Maybe the mailing list archives of utah-glx can be of use to find out more about this person if needed. Nevertheless, I can send the zip file with the sources to any of you who are interested. The file size is around 160kB, so it would probably not be accepted as an attachment to this mail. Best regards, -- Svante Signell [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [noveau] Nv03-06 driver source code
On Wed, 2007-01-24 at 21:41 +0100, Stephane Marchesin wrote: Svante Signell wrote: Dear Noveau developers, Some years ago, around 2000-2002 there was a guy in New Zealand, David, working on Nvidia drivers, see the message at the Utah-GLX mailing list archive from April 2002: http://sourceforge.net/mailarchive/forum.php?thread_id=612267forum_id=3646 ... Hello, Yes, I think we have it already (nvsrc.zip right ?). Thanks anyway ! Maybe it is the same stuff: My zip file is called Nv04KernelSrc-v0.0.0.zip The unpacked files are dated around year 2000. Svante Stephane - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #9032] Direct rendering applications hangs with tdfx-1.1.1, 1.2.0, 1.2.1, 1.2.2
Dear Alex, Thank you for the patch. It made the tdfx driver work again. Did you also announce version 1.2.3 package at http://lists.freedesktop.org/archives/xorg-announce/2006-November/ to be available at http://xorg.freedesktop.org/releases/individual/driver This would be very welcomed from all people having a txdfx card! Otherwise, since I'm running Debian I would submit a patch for the maintainers to make the driver work again (starting from 1.2.2) for Debian but not for other distribs. This would be suboptimal, the more upstream the better. Thanks, Svante Signell On Thu, 2006-11-16 at 00:19 +0100, Svante Signell wrote: On Wed, 2006-11-15 at 17:00 -0500, Alex Deucher wrote: On 11/15/06, Svante Signell [EMAIL PROTECTED] wrote: On Wed, 2006-11-15 at 15:02 -0500, Alex Deucher wrote: ... See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395044 for further information. Thanks, Sounds like a locking problem in the DDX. the locking stuff was cleaned up when AIGLX was merged and a lot of drivers broke (savage, mga, others?). See bug 6357 (savage) for reference. I suspect the fix should be pretty simple. I assume you mean the patch with id=7041, not 7035,7036. The savage patch had changes in savage_dri.c and savage_driver.h. The DRILock functions are called in both tdfx_accel.c and tdfx_driver.c as compared to savage_dri.c. Additionally TDFXDoBlockHandler and TDFXDoWakeupHandler are defined in tdfx_dri.c. Where to make the change? I thew together a quick and dirty untested patch: https://bugs.freedesktop.org/show_bug.cgi?id=9032 let me know if it works. Thanks a lot. It works with the patch! glxgears spins at 480 fps and other 3D applications do also work. Maybe you could release the updated driver as version 1.2.3 and also increment the TDFX_PATCHLEVEL to 3 in tdfx.h. (For 1.2.2 the patchlevel was not incremented, it is still reported as 1.2.1, and never announced). When the fixed driver has been released, I'll try to convince the Debian release managers to update the unstable package to this driver. Svante Alex - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Svante Signell [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #9032] Direct rendering applications hangs with tdfx-1.1.1, 1.2.0, 1.2.1, 1.2.2
On Wed, 2006-11-15 at 15:02 -0500, Alex Deucher wrote: ... See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395044 for further information. Thanks, Sounds like a locking problem in the DDX. the locking stuff was cleaned up when AIGLX was merged and a lot of drivers broke (savage, mga, others?). See bug 6357 (savage) for reference. I suspect the fix should be pretty simple. I assume you mean the patch with id=7041, not 7035,7036. The savage patch had changes in savage_dri.c and savage_driver.h. The DRILock functions are called in both tdfx_accel.c and tdfx_driver.c as compared to savage_dri.c. Additionally TDFXDoBlockHandler and TDFXDoWakeupHandler are defined in tdfx_dri.c. Where to make the change? Svante Alex - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #9032] Direct rendering applications hangs with tdfx-1.1.1, 1.2.0, 1.2.1, 1.2.2
On Wed, 2006-11-15 at 17:00 -0500, Alex Deucher wrote: On 11/15/06, Svante Signell [EMAIL PROTECTED] wrote: On Wed, 2006-11-15 at 15:02 -0500, Alex Deucher wrote: ... See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395044 for further information. Thanks, Sounds like a locking problem in the DDX. the locking stuff was cleaned up when AIGLX was merged and a lot of drivers broke (savage, mga, others?). See bug 6357 (savage) for reference. I suspect the fix should be pretty simple. I assume you mean the patch with id=7041, not 7035,7036. The savage patch had changes in savage_dri.c and savage_driver.h. The DRILock functions are called in both tdfx_accel.c and tdfx_driver.c as compared to savage_dri.c. Additionally TDFXDoBlockHandler and TDFXDoWakeupHandler are defined in tdfx_dri.c. Where to make the change? I thew together a quick and dirty untested patch: https://bugs.freedesktop.org/show_bug.cgi?id=9032 let me know if it works. Thanks a lot. It works with the patch! glxgears spins at 480 fps and other 3D applications do also work. Maybe you could release the updated driver as version 1.2.3 and also increment the TDFX_PATCHLEVEL to 3 in tdfx.h. (For 1.2.2 the patchlevel was not incremented, it is still reported as 1.2.1, and never announced). When the fixed driver has been released, I'll try to convince the Debian release managers to update the unstable package to this driver. Svante Alex - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: persistant problems with drm + mga
On Thu, 2006-01-05 at 00:27 +0100, Svante Signell wrote: On Wed, 2006-01-04 at 23:09 +, Dave Airlie wrote: Dave Airlie: Can we get those DRM changes pushed into 2.6.15 or is it too late for that ... Is it possible to make a patch to add to the DRM module for kernels 2.6.14 and 2.6.15 to solve the MGA problems until 2.6.16 is released? This could be usable for e.g. the Debian people to add this patch when building the stock kernels. Or is Option OldDmaInit true the only way out. Thanks for your feedback, I just tested that kernels 2.6.14 and 2.6.15-rc7 are OK with the OldDmaInit workaround. I wish I could help with the patch, but others are better on that. Maybe this should be direct between e.g. the Debian package manager and DRI devel, not via me. I'm just trying to help. Sorry if I'm intruding... -- Svante Signell [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: persistant problems with drm + mga
On Tue, 2006-01-03 at 23:51 +0100, Svante Signell wrote: On Tue, 2006-01-03 at 13:34 +, David Mulcahy wrote: Hello all I have been experiencing problems getting drm to work again with my matrox g4oo card. ... I have had this problem for some time now, both with xorg 6.9.0pre releases and 6.9.0 with kernels 2.6.14 and 2.6.15-rc4, ... Kernel 2.6.11 is OK with xorg 6.9.0, ... Setting OldDmaInit to true in xorg.conf solved the direct rendering problems, at least with kernel 2.6.15rc7. Have not tried 2.6.14 yet. Thanks, -- Svante Signell [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: persistant problems with drm + mga
-- Svante Signell [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mach64
Is anything happening on the Mach64 front for DRI/X.org? It would be nice to use the 3D capabilities, now that Debian has upgraded unstable to Xorg. -- Svante Signell [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Status of Mach64?
I'm following DRI devel the mailing lists and have not seen anything on the Mach64 driver lately, especially on the security issues. Any progress? Is Mach64 in Xorg-6.8.1? I'm running Debian with XFree86-4.3.0 and self compiled xlibmesa-dri xserver-xfree86 packages. Unless the switch to X.org includes a fully supported driver, I will not change before Debian unstable does. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Which DRI driver/card is usable for modern games?
I'm fully aware of the lack of documentation for recent graphics cards and the problems associated with that. Maybe the open source vs closed source problem is already a lost battle especially already. The situation seems to be much better for other HW such as audio cards, NICs, printers, etc needed by the kernel though, except maybe for WiFi cards. However, my original question remain: Which card is usable with DRI open source drivers for modern games? Also, is the S3TC issue resolved for the cards I mentioned before: Mach64, G400, Banshee and Radeon 9000 PRO. Since I'm replying to your mail Vladimir, how about the TV-out issue especially with the GATOS drivers and for XFree86/X.org in general. Are all these efforts in vain for GNU/Linux and other open source OSes. Only binary driver alternatives remains, or other OSes not to mention here.. On Thu, 2004-05-06 at 00:54, Vladimir Dergachev wrote: Is there any hope for open source drivers for high performance cards, taking into consideration the binary alternatives available for cards from ATI, Nvidia or Matrox (Parhelia), etc? One thing to keep in mind about this issue is that ATI and NVidia start working on their 3d drivers even before their cards are released yet. We are still asking for documentation for the next to latest generation of ATI cards (R300) (and, AFAIK, NVidia does not provide docs at all). So open source driver will always be late. However the question of how late depends a lot on how easy it is to program using current frameworks (i.e. Mesa, DRI, X11). best Vladimir Dergachev --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-7 cvs fails to build (solved)
Thanks fot your input. I have now built a new xserver and the drm kernel modules. glxgears runs at approx 160 fps for 1280x1024x16, with mmio and agp 2x. This seems a little slow, how much is speed improved by asynchronous or synchronous DMA? Which one is preferred? A note on the build process of the kernel modules. I had to do the following om my GNU/Debian unstable box to build the mach64.o: apt-get install kernel-source-2.4.25 (and unpack) ln -s /usr/src/kernel-source-2.4.25 /usr/src/linux (optional) cp /boot/config-2.4.25-1-686 /usr/src/linux/.config (stock kernel) cd /usr/src/linux make xconfig exit immediately = include/linux/version.h is created make dep cd /usr/CVS/dri-cvs/drm/linux make LINUXDIR=/usr/src/linux cd /usr/CVS/dri-cvs/drm/linux cp gamma.o i810.o i830.o mach64.o mga.o r128.o radeon.o savage.o sis.o tdfx.o via.o /lib/modules/2.4.25-1-686/kernel/drivers/char/drm/ depmod -a A much nicer approach would be to build the kernel modules with the aid of only the kernel-headers, not the kernel source, such as when building the alsa-modules, i2c-modules or the lm-sensors-modules. Using the kernel-headers one does not have to create the version.h file, it is already there. This requires a debian directory however, and more makefile support for the build than for a stock kernel. apt-get install kernel-headers-2.4.25-1-686 apt-get install i2c-source (and unpack) cd /usr/src/modules/i2c time fakeroot ./debian/rules KSRC=/usr/src/kernel-headers-2.4.25-1-686 KVERS=2.4.25-1-686 KDREV=2.4.25-1 kdist_image Thanks for your efforts. Hopefully, in due time, the security problem can be solved for the mach64 and savage drivers too :( On Tue, 2004-04-27 at 03:18, Alex Deucher wrote: --- Adam Jackson [EMAIL PROTECTED] wrote: On Monday 26 April 2004 17:59, Felix Khling wrote: The mach64 driver has moved to the trunk. Try building it there. The branch is broken for quite a while now. It won't be fixed. So it's been merged then? As in, I should go update the wiki so we don't get this complaint in the future? Already done. Alex - ajax __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64-0-0-7 cvs fails to build
Hello, I made a fresh checkout of the mach64-0-0-7 cvs branch together with the Mesa and drm modules according to the Building and ATIMach64 web pages. However the build fails. The tail of world.log is as follows: ... ln -s /usr/CVS/dri-cvs/Mesa/src/mesa/main/accum.h accum.h make[5]: *** No rule to make target `/usr/CVS/dri-cvs/Mesa/src/mesa/main/arbparse.c', needed by `arbparse.c'. Stop. make[5]: Leaving directory `/usr/CVS/dri-cvs/xc/xc/lib/GL/mesa/main' .. Warnings in the world.log are: Compiler is gcc (GCC) 3.3.3 (Debian 20040401) make[2]: Entering directory `/usr/CVS/dri-cvs/xc/xc/config/imake' gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -I../../include -I../../exports/include/X11 -I../.. -I../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DCPP_PROGRAM=\cpp\ -DHAS_MERGE_CONSTANTS=`if gcc -m32 -fmerge-constants -xc /dev/null -S -o /dev/null 2 /dev/null 1 /dev/null; then echo 1; else echo 0; fi` -c -o imake.o imake.c imake.c:972: warning: string length `1094' is greater than the length `509' ISO C89 compilers are required to support ../config/cf/linux.cf:97: warning: InstallAppDefFiles is not defined (several entries) Imakefile:35: warning: BuildXIElib is not defined Imakefile:39: warning: BuildPexLib is not defined Imakefile:18: warning: KDriveXServer is not defined --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ProSavage KM133: no direct rendering?
On Wed, 2004-04-07 at 01:08, Svante Signell wrote: On Wed, 2004-04-07 at 00:53, Felix Kühling wrote: ... I suspect there was a configuration change on the snapshot build machine that made the build fail after April 1. I just committed a workaround to the snapshot build scripts. Unofficial up-to-date snapshots are available from http://freedesktop.org/~fxkuehl/snapshots/ until the next nightly build. No guarantee that they work. Thanks, I'll make a new try with this version. Now the module loading works but the X error is there as expected: (2D is working, however not at 24 bits and 1280x1024. Same as before.) LIBGL_DEBUG=verbose glxinfo: libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (XFree86-DRI) Minor opcode of failed request: 5 () Value in failed request: 0x48 Serial number of failed request: 26 Current serial number in output stream: 26 name of display: :0.0 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ProSavage KM133: no direct rendering?
Additional info, this shows up in the XFree86.0.log file: (II) SAVAGE(0): [drm] Could not create dummy context On Wed, 2004-04-07 at 08:07, Svante Signell wrote: On Wed, 2004-04-07 at 01:08, Svante Signell wrote: On Wed, 2004-04-07 at 00:53, Felix Kühling wrote: ... I suspect there was a configuration change on the snapshot build machine that made the build fail after April 1. I just committed a workaround to the snapshot build scripts. Unofficial up-to-date snapshots are available from http://freedesktop.org/~fxkuehl/snapshots/ until the next nightly build. No guarantee that they work. Thanks, I'll make a new try with this version. Now the module loading works but the X error is there as expected: (2D is working, however not at 24 bits and 1280x1024. Same as before.) LIBGL_DEBUG=verbose glxinfo: libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (XFree86-DRI) Minor opcode of failed request: 5 () Value in failed request: 0x48 Serial number of failed request: 26 Current serial number in output stream: 26 name of display: :0.0 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ProSavage KM133: no direct rendering?
Hello, I installed and built the latest savage snapshot savage-20040401-linux.i386.tar.bz2 from www.freedesktop.org/~dri/snapshots together with the extras/XFree86.bz2 dated 29-Sep-2003. XFree86 packages installed are Debian/testing 4.3.0-7. The XV stuff seem to work OK at 16 bits, but at 24 bits the screen is showing random colors, probably due to card memory problems. I know this is 2D related, but nevertheless, according to the webpage 2D is new too since an updated XFree86 server is needed. The 3D is reported to work in XFree86.0.log but not in glxinfo. XFree86.0.log: XFree86 Version 4.3.99.12 (DRI trunk) Release Date: 10 September 2003 X Protocol Version 11, Revision 0, Release 6.6 [...] (II) SAVAGE(0): Direct rendering enabled (**) SAVAGE(0): XvMC is enabled (==) RandR enabled [...] glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 [...] OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.3 Mesa 4.0.4) [...} (more info on request) The only problems found is from the kernel logs: [...] [drm] Initialized savage 1.0.0 20011023 on minor 0: ProSavage KM133 mtrr: no more MTRRs available mtrr: base(0xf200) is not aligned on a size(0x500) boundary mtrr: base(0xf057e000) is not aligned on a size(0xa8) boundary [...] Unfortunately the Debian packages, which I installed from freedesktop.org/~daenzer/debian/dri-trunk-sid and built first are outdated. They are from 28-feb-2004, with no savage modules. To prepare for building the kernel module savage.o I had to install the kernel source, copy the System.map-2.4.25-1-k7 file from the kernel-image-2.4.25-k7 to /usr/src/kernel-source-2.4.25/.config. In order to make the savage module compile I had to add LINUXDIR=/usr/src/kernel-source-2.4.25 to the install script. (Debian-specific) A much nicer way to build the kernel module for debian systems, without the need for make-kpkg: This method works with alsa, i2c and lm-sensors and uses the kernel-headers instead of kernel-source: fakeroot ./debian/rules KSRC=/usr/src/kernel-headers-2.4.25-1-k7 KVERS=2.4.25-1-k7 KDREV=2.4.25-1 kdist_image but this will probably require a modification of the debian/*. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ProSavage KM133: no direct rendering?
On Tue, 2004-04-06 at 12:36, Felix Kühling wrote: The kernel messages look harmless. Since XFree86.0.log reports DRI enabled the problem is either due to a wrong libGL or a broken 3D driver. Or maybe the 3D driver doesn't have permission to access the kernel driver. Could you run LIBGL_DEBUG=verbose glxinfo The output should tell what's wrong. If there is a message about a missing symbol try a newer snapshot. There were some problems with missing symbols that were fixed recently. Regards, Felix Thanks, the problem is a missing symbol: libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (/usr/X11R6/lib/modules/dri/savage_dri.so: undefined symbol: _x86_Vertex1fv_end) libGL error: unable to find driver: savage_dri.so Are there any plans to support snapshots built later than April 1 (and Debian packages)? The latest I have found on http://www.freedesktop.org/~dri/snapshots/ has the libGL.so.1.2 with the missing symbol. I currently don't have time to compile from source. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ProSavage KM133: no direct rendering?
On Wed, 2004-04-07 at 00:53, Felix Kühling wrote: ... I suspect there was a configuration change on the snapshot build machine that made the build fail after April 1. I just committed a workaround to the snapshot build scripts. Unofficial up-to-date snapshots are available from http://freedesktop.org/~fxkuehl/snapshots/ until the next nightly build. No guarantee that they work. Thanks, I'll make a new try with this version. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 resource problems
Sorry for continuing this thread but I think there are some open issues: 1. There is a memory leak (or something similar) in the mach64 driver since consecutive calls to the Xv driver fails . (With a call to a GL application in between) 2. Does the lack of feedback indicate that the issue is closed (i.e. bug free or not interesting or resolved)? (I know the funding is non-existing for mach64 , I really appreciate the efforts from Leif D. 3. There is some texmem stuff going on in the main path, is this affecting the mach65-0.0.5 branch? This mail is specifically addressed to Leif D. who has been _very_ responsive (and interested) so far :-) Maybe I should buy a new graphics card, such as Radeon 9000 (or an Nvidia one, god forgive) instead of bothering with old cards?? (even if they work properly) Svante Svante Signell writes: Leif Delgass writes: On Thu, 28 Nov 2002, Svante Signell wrote: Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. Actually, those allocations only apply when a GL context is running. That's why the message was changed from Using to Will use -- no memory is allocated when that message is logged. When the X server actually allocates that memory for the DRI back and depth buffers (when changing from no GL contexts to one or more GL contexts -- not including the X server's context), you should see Largest offscreen area available: ... At startup of the X server: (II) ATI(0): Largest offscreen area available: 1280 x 2252 (II) ATI(0): Will use 511 kB of offscreen memory for XAA (II) ATI(0): Will use back buffer at offset 0x2ff800 (II) ATI(0): Will use depth buffer at offset 0x57f800 Later in the log file: (II) ATI(0): Largest offscreen area available: 1280 x 2252 ... You can check /proc/dri/0/clients to see the pids of all the DRI clients (there will always be at least one for the X server). Note however that when I run KDE, I get a few clients listed for some processes that are linked to libGL even though they haven't created a full-fledged context and don't cause the X server to allocate any memory for 3D. Only one client remains after exiting from the xsceensaver demo. cat /proc/dri/0/clients a dev piduid magic ioctls y 0 1904 0 06292494 BTW: I'm running gnome and sawfish. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 2a) Exit the atlantis demo, with xscreensaver running in the background. 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) --- 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] Mach64 resource problems
Leif Delgass writes: On Thu, 28 Nov 2002, Svante Signell wrote: Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. Actually, those allocations only apply when a GL context is running. That's why the message was changed from Using to Will use -- no memory is allocated when that message is logged. When the X server actually allocates that memory for the DRI back and depth buffers (when changing from no GL contexts to one or more GL contexts -- not including the X server's context), you should see Largest offscreen area available: ... At startup of the X server: (II) ATI(0): Largest offscreen area available: 1280 x 2252 (II) ATI(0): Will use 511 kB of offscreen memory for XAA (II) ATI(0): Will use back buffer at offset 0x2ff800 (II) ATI(0): Will use depth buffer at offset 0x57f800 Later in the log file: (II) ATI(0): Largest offscreen area available: 1280 x 2252 appear again at the end of the X log. Also when that happens, the XVideo memory (in use for the current frame) is freed. If the remaining offscreen memory after the DRI allocations (511 kB in this case) is not enough for subsequent video frame allocations, then you'll see the BadAlloc, which would cause mplayer to crash. Since the driver uses double-buffering for XVideo by default, this is _not_ enough for DVD and I'm pretty sure it's not enough for the video size you had the problem with in your first email (though I'd have to check the calculations for that video format). So if you have both a GL app and an XVideo app running at the same time, the XVideo app's allocations will fail unless the video size is fairly small. This is not very graceful, but it's expected with the current code and doesn't indicate a memory leak. However, if you run mplayer, exit mplayer, run a GL app, exit the GL app, and then run mplayer again, you shouldn't have a problem. If that's what's really happening, that's a bug. Yes, this is what I did. I did exit from the atlantis demo but still with xscreensaven running in the background. Also, stopping the xscreensaver daemon does not change anything. In addition, after failure to allocate off-screen memory I can still view small size video applications in mplayer but not large size ones. So the concusion would be that it's a bug, either in the mach64 driver or somewhere else, eg. xscreensaver? You can check /proc/dri/0/clients to see the pids of all the DRI clients (there will always be at least one for the X server). Note however that when I run KDE, I get a few clients listed for some processes that are linked to libGL even though they haven't created a full-fledged context and don't cause the X server to allocate any memory for 3D. Only one client remains after exiting from the xsceensaver demo. cat /proc/dri/0/clients a dev piduid magic ioctls y 0 1904 0 06292494 BTW: I'm running gnome2 and sawfish. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 2a) Exit the atlantis demo, with xscreensaver running in the background. 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) In the sequence above, do you close the atlantis demo between step 2 and 3? I can reproduce this if I leave atlantis open and then start an xvideo app (I tested with xine), or if I leave xine running and then start atlantis. This is the scenario I described above. But if atlantis/xscreensaver is not running after step 2 (check /proc/dri/0/clients to make sure), then #3 shouldn't fail. See above. At any rate, the upshot is that you won't be able to have 3D accel and XVideo past a certain video size at the same time with 1280x1024 (with the current shared buffer scheme for DRI). Even if we can make the failure more graceful, we'll either have to revert to software GL or reduce the maximum XvImage size (though we could probably make it so any running apps would continue to work as expected). I don't expect to have them active at the same time, running them one at a time is OK for me. --- 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] Mach64 resource problems
Leif Delgass writes: On Wed, 27 Nov 2002, Svante Signell wrote: Leif Delgass writes: Have you tried a lower resolution? Not yet. Try restarting X with 1024x768@16bpp for a while and see if you still have the same problem. I have now tested at 1024x768, and everything works OK, but I think there is memory not returned to the card in the 3D driver, see below. If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. What is meant with offscreen memory, main memory + card memory or smth else? free: total used free sharedbuffers cached Mem:127660 123760 3900 0 9104 44884 -/+ buffers/cache: 69772 57888 Swap: 130748 84172 46576 Offscreen memory refers to the on-card memory left over after the framebuffer allocation(s). When there are no GL contexts, the framebuffer memory is equal to display width x display height x bytes per pixel (2 for 16-bit). With GL contexts running, there is an additional back buffer (same size as the 2D front framebuffer) plus a depth buffer which is width x height x 2 (depth buffer is always 16-bit). The remaining offscreen memory is used for XAA and XVideo buffers. You can get a BadAlloc when there is not enough offscreen memory left. Doing the calculations one gets: 8Meg - 3x(1280x1024)= 8388608 - 7864320 = 524288 bytes = 512 kbytes which is close to what the log file reports: (II) ATI(0): Will use 511 kB of offscreen memory for XAA It seems that the 3D driver already has allocated the frame buffer, back buffer and depth buffer memory at startup, right. Obviously the remaining 512k of memory is sufficient for the XV driver when no 3D applications has been activated. Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? xscreensaver is running, so some 3D applications are possibly run when it activates. The box is usually on all day. I can now reproduce the error for 1280x1024: 1. Run mplayer using the XV driver: Everything is OK 2. Run a 3D application, such as the atlantis demo in xscreensaver 3. Run mplayer using the XV driver again: Error state occurs X11 error: BadAlloc (insufficient resources for operation) Running the xscreensaver demo again works, no problem. Conclusion: Memory available for XAA and XV before running the 3D application is not returned when the application exits!! Maybe this in not possible to do for this card without leaving X and reentering, but it is _very_ annoying. I don't really like to run the desktop at 1024x768. I will robably use another X display for 3D applications or for viewing movie clips. The best alternative though, would be if you can find a solution in the mach64 driver. Thanks for your help, Svante The current code allocates and frees 3D offscreen mem when transitioning from no GL contexts to one or more and on transitioning from one or more GL contexts to none. It's possible that there's a leak happening on the transitions. Also could you send your complete X log after reproducing the problem? Attached please find the XFree86.0.log at 1280x1024 and a diff to when the screen size is 1024x768 XFree86.0.log.1280x1024 Description: Binary data XFree86.0.log.diff Description: Binary data
Re: [Dri-devel] Mach64 resource problems
Leif Delgass writes: Have you tried a lower resolution? Not yet. If it's some sort of memory leak, I'd expect that you'd run into it eventually even at a lower resolution. If it doesn't happen at lower resolutions, maybe you really just don't have enough offscreen memory at 1280x1024. What is meant with offscreen memory, main memory + card memory or smth else? free: total used free sharedbuffers cached Mem:127660 123760 3900 0 9104 44884 -/+ buffers/cache: 69772 57888 Swap: 130748 84172 46576 Also, did you run any GL apps before starting mplayer or between attempts (or during attempts)? xscreensaver is running, so some 3D applications are possibly run when it activates. The box is usually on all day. The current code allocates and frees 3D offscreen mem when transitioning from no GL contexts to one or more and on transitioning from one or more GL contexts to none. It's possible that there's a leak happening on the transitions. Also could you send your complete X log after reproducing the problem? Do you mean the XFree86.0.log or an strace log? See also below. --Leif Can you please describe how memory (both card and main memory) is allocated and released for 2D and 3D applications: What puzzles me is that if I start with a fresh X everything is OK, but after the problem occurs I have to exit X to be able to run the application again. It is not sufficient to terminate the application to get back to the same state as as when starting anew. Possible causes of the resource shortage can be: 1. The applications do not return memory when exiting. 2. X cannot reclaim the memory when the appications exit. 3. There is a memory leak somewhere. 4. Something else?? Thanks, Svante Selected parts of XFree86.0.log and strace mplayer -vo sdl file.avi below. XFree86.0.log (II) LoadModule: vbe (II) Reloading /usr/X11R6/lib/modules/libvbe.a (II) ATI(0): VESA BIOS detected (II) ATI(0): VESA VBE Version 2.0 (II) ATI(0): VESA VBE Total Mem: 8192 kB (II) ATI(0): VESA VBE OEM: ATI MACH64 (II) ATI(0): VESA VBE OEM Software Rev: 1.0 (II) ATI(0): VESA VBE OEM Vendor: ATI Technologies Inc. (II) ATI(0): VESA VBE OEM Product: MACH64LP (II) ATI(0): VESA VBE OEM Product Rev: 01.00 (II) ATI(0): VESA VBE DDC supported (II) ATI(0): VESA VBE DDC Level 2 (II) ATI(0): VESA VBE DDC transfer in appr. 2 sec. (II) ATI(0): VESA VBE DDC read successfully (II) ATI(0): Manufacturer: NOK Model: 1b0 Serial#: 33583 (II) ATI(0): Year: 1998 Week: 9 (II) ATI(0): EDID Version: 1.2 ... (--) ATI(0): ATI 3D Rage LT Pro graphics controller detected. (--) ATI(0): Chip type 4C42 LB, version 4, foundry UMC, class 0, revision 0x03 . (--) ATI(0): AGP bus interface detected; block I/O base is 0xD000. (--) ATI(0): ATI Mach64 adapter detected. (!!) ATI(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (--) ATI(0): Internal RAMDAC (subtype 1) detected. (==) ATI(0): RGB weight 565 (==) ATI(0): Default visual is TrueColor (==) ATI(0): Using gamma correction (1.0, 1.0, 1.0) (II) ATI(0): Using Mach64 accelerator CRTC. (**) ATI(0): Using CRT interface and disabling digital flat panel. (II) ATI(0): Storing hardware cursor image at 0xE47FFC00. (II) ATI(0): Using 8 MB linear aperture at 0xE400. (!!) ATI(0): Virtual resolutions will be limited to 8191 kB due to linear aperture size and/or placement of hardware cursor image area. (II) ATI(0): Using Block 0 MMIO aperture at 0xE6000400. (II) ATI(0): Using Block 1 MMIO aperture at 0xE600. (==) ATI(0): Write-combining range (0xe400,0x80) (II) ATI(0): MMIO write caching enabled. (--) ATI(0): 8192 kB of SGRAM (1:1) detected (using 8191 kB). (WW) ATI(0): Cannot shadow an accelerated frame buffer. (--) ATI(0): Internal programmable clock generator detected. (--) ATI(0): Reference clock 29.500 MHz. ... (II) ATI(0): [drm] created mach64 driver at busid PCI:1:0:0 (II) ATI(0): [drm] added 8192 byte SAREA at 0xc8958000 (II) ATI(0): [drm] mapped SAREA 0xc8958000 to 0x40013000 (II) ATI(0): [drm] framebuffer handle = 0xe400 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [drm] Will request asynchronous DMA mode (**) ATI(0): [agp] Using AGP 2x Mode (==) ATI(0): [agp] Using 8 MB AGP aperture (II) ATI(0): [agp] Mode 0x1f000203 [AGP 0x8086/0x7190; Card 0x1002/0x4c42] (II) ATI(0): [agp] 8192 kB allocated with handle 0xc915c000 (==) ATI(0): [agp] Using 2 MB for DMA buffers (II) ATI(0): [agp] Using 6 MB for AGP textures (II) ATI(0): [agp] vertex buffers handle = 0xe000 (II) ATI(0): [agp] Vertex buffers mapped at 0x40b0c000 (II) ATI(0): [agp] AGP texture region handle = 0xe020 (II) ATI(0): [agp] AGP Texture region mapped at 0x40d0c000 (II) ATI(0): [drm] register handle = 0xe600 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xe6000400 (II) ATI(0): Memory
[Dri-devel] Mach64 resource problems
Hello, I have problems with the latest mach64 branch from dri-cvs. After a successful view of an .avi clip next time the card memory does not seem to be available, i.e. the card is left in a bad state? The only way to rerun the application is to exit X and restart. The example given below is with a 2D application: mplayer, but other applications behave similarly. I think the problem is with the mach64 driver for X, and this is developed in the DRI project, right? The X server is built from DRI-CVS two days ago with the XV patches added from Leif Delgass homepage. cat /var/log/XFree86.0.log: XFree86 Version 4.2.0 (DRI mach64 branch) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 ... The graphics card is an ATI 3D Rage LT with 8 Meg onboard memory. Desktop size is 1280x1024 An example of output is when running mplayer with the SDL driver: VO: [sdl] 624x352 = 624x352 Planar YV12 SDL: Using driver: x11 X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 142 (XVideo) Minor opcode of failed request: 19 () Serial number of failed request: 21 Current serial number in output stream: 22 and with the XV driver: VO: [xv] 624x352 = 624x352 Planar YV12 X11 error: BadAlloc (insufficient resources for operation) MPlayer interrupted by signal 6 in module: flip_page - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/bugreports.html and follow instructions there. We can't and won't help unless you provide these informations when reporting a possible bug. Xlib: unexpected async reply (sequence 0x54)! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] tribes2 and DRI/G400?
Hi, Is there a known bug in the mga driver resulting in tribes2 switching between SW and HW rendering on my G400 DH? All games patches seem to be similar, latest one installed is #23669. Any options to set to run fully in HW? If not, is compiling from DRI CVS solving the problems? Other games, such as q3a, ut, descent3 demo, rune demo, sof demo etc work OK. Installed: Debian/GNU unstable, kernel-2.4.7 (with DRI-patches to mga.o v 3.0), XFree86-4.1.0-6 and xlibmesa3-4.1.0-6. Please cc: to me, since I'm not subscribed to the list. Thanks, Svante ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
