Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
On Tuesday 25 June 2002 19:53, Nicolas Aspert wrote: Slava Polyakov wrote: I'm not sure where to find the testgart util (I am indeed running it on an i815B). Could you send me the tarball or give me a url to it? http://ltswww.epfl.ch/~aspert/patches/testgart.c or http://dri.sourceforge.net/res/testgart.c Some numbers for the AMD 760 MPX chipset. MSI K7D-Master-L (MS-6501) v1.0, BIOS 1.3 Dual Athlon MP 1900+ 512 MB DDR266-SDRAM CL2 dmesg: [-] Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected AMD 760MP chipset agpgart: AGP aperture is 64M @ 0xe800 memory : c24e0680 memory : c24e06c0 [-] SunWave1 Entwicklung/Kernel# ./testgart version: 0.99 bridge id: 0x700c1022 agp_mode: 0xf000203 aper_base: 0xe800 aper_size: 64 pg_total: 112384 pg_system: 112384 pg_used: 0 entry.key : 0 entry.key : 1 Allocated 8 megs of GART memory MemoryBenchmark: 1372 mb/s MemoryBenchmark: 1407 mb/s MemoryBenchmark: 1434 mb/s Average speed: 1404 mb/s Testing data integrity (1st pass): passed on first pass. Testing data integrity (2nd pass): passed on second pass. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] --- 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] Re: Compilation
On Monday 24 June 2002 13:09, Alexander Stohr wrote: Or you are try out the current closed source drivers for X11 and the ATI FireGL 8700/8800 - they do run on the BUILT BY ATI Radeon 8500 boards as well. The board indicates this compatibility by a PCI Subvendor ID of 0x1002 or ATI. Hello Alexander! No change to get this going on your partner boards? Even with flashed BIOS? I can get may hands on a 8500LE on top of my dual Athlon 1900+ MP/XP for testing. Thanks, Dieter [-] drivers for my ati radeon 8500 but they wont compile... Here are the messages i get: There are no Radeon 8500 DRI drivers. Not until October-December this year anyway (Q4/2002). You'll have to wait until then. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] --- 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] Re: agpgart, nFORCE (Al Tobey)
On Thursday 01 January 1970 00:59, Smitty wrote: Hallo Dieter It's just a guess on the agp gart; the IDE and sound both are clones of the AMD chip, so why not the gart?. The big whiz-bang feature of the nFORCE chipset is the crossbar memory controller that supposedly doubles the bandwidth of DDR (double double data rate). Why would they bother creating the rest from scratch? Nevertheless, being a graphics chip company, nVidia might very well decide to create their own GART. Because Sound IDE are normally South Bridge stuff, so if they are in an AMD chipset board, they would be in the SB, and the Memory controller, AGP, would be in the NB. Unless nVidia / AMD tells you that it is the same, don't hold your breath. Alan Cox and someone on LKM had something going. Watchout for -ac kernel changelogs and nFORCE there. Have you thried with agp_try_unsupported=1? modules.conf: [-] alias char-major-10-175 agpgart alias char-major-10-240 agpgarti810 [-] # agpgart is i386 only right now pre-install mga /sbin/modprobe -k agpgart pre-install r128 /sbin/modprobe -k agpgart pre-install radeon /sbin/modprobe -k agpgart options agpgart agp_try_unsupported=1 [-] Dankie Dieter Danke ;-) But I dont have an nForce, I have and Irongate (756/ 758). AMD 750 (751/756) Irongate C3-6 (=C5 with working bypass) ;-) I was replying to Al Tobey. Sorry. Dieter --- 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] radeon drivers (tcl vs. non-tcl)
On Saturday 22 June 2002 16:15, Jens Owen wrote: Zilvinas, Thanks for posting this data. It's nice to see confirmation of how things were intended to work. I'll second that. May I ask if Zilvinas could repeat with 60Hz? I know that this is a bad number but the RAMDAC clock has some influence. Most official benchmarks (Win) are made @60 Hz... Second: My dual Athlon MP 1900+ (MSI K7D Master-L, AMD 760MPX) with 512MB DDR-SDRAM (1 GB is comming soon) is up and running. I can get my hands on a Radeon 8500 and maybe a 7500, tomorrow or Monday. I'll do some viewperf-6.1.2 numbers on my V5 5500 @24 bit tonight. Mesa/demos ./gloss 596 frames in 5.006 seconds = 119.057 FPS -- cylinder 764 frames in 5.003 seconds = 152.708 FPS 760 frames in 5.006 seconds = 151.818 FPS 758 frames in 5.001 seconds = 151.57 FPS 483 frames in 5.004 seconds = 96.5228 FPS 420 frames in 5.003 seconds = 83.9496 FPS 420 frames in 5 seconds = 84 FPS 421 frames in 5.008 seconds = 84.0655 FPS -- teapot ipers is running @20-22 fps (~580.000 Poly/sec) Desktop resolution is 1280x1024@24 as always ;-) We need the Mesa (p)thread stuff badly 'cause all numbers are from single theard/process mode (the second CPU was all the time 100% idle). Cheers, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] --- 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] radeon cvs problem
On Saturday 22 June 2002 21:41, Keith Whitwell wrote: [EMAIL PROTECTED] wrote: If you're running XFree86 4.1, No, I'm running 4.2. Yesterday I bit the bullet and downloaded the entire source tree (quite an adventure down a phone line ...) and built from source. All worked fine this time, so there perhaps some problem with the binary packages on SF? Perhaps there's a dependence on an X11R6 module not included in the binary package? Anyhow, so now I have the radeon cvs built and working correctly, everything's wonderful (thanks to all the developers!) apart from an assertion failure I get repeatedly with our 3D ultrasound application (http://svr-www.eng.cam.ac.k/~rwp/stradx). It happens whenever I open a new window and make the new context current: radeon_vtxfmt.c:1039: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. It doesn't happen with _every_ context switch, just with a particular pair of windows in the application - but it is repeatable with these two windows. The problem goes away with RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1, and doesn't appear with any other GL implementation we've tried (including mga dri). I'd be happy to test patches if anyone's interested in this one This is interesting. The code to cope with multiple contexts there hasn't had a huge amount of testing. If I download your code, how can I exercise this problem? What about the cxbug.c test posted here, lately? With the tdfx driver I get this with mode #5: Mesa/demos ./cxbug 5 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 10 (X_GLXCopyContext) Serial number of failed request: 37 Current serial number in output stream: 38 Manywin show bad textures with s = 2 Mesa/xdemos ./wincopy glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() [snip] -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] cxbug.c.bz2 Description: BZip2 compressed data
Re: [Dri-devel] Re: tuxkart, and bug reports..
On Thursday 13 June 2002 17:17, Alan Hourihane wrote: On Thu, Jun 13, 2002 at 04:03:05PM +0100, Keith Whitwell wrote: Alan Hourihane wrote: On Wed, Jun 12, 2002 at 11:13:40PM +0200, Dieter Nützel wrote: On Wednesday 12 June 2002 20:53, Alan Hourihane wrote: [-] We really need to clean up the stuff on SF now. Probably about 90% don't even apply now, or should at least be re-tested. Yes, let's start with that. There are even several bugs for which the sender asked for closing but never happend... Maybe we can change the maintenance so that the original poster can close it himself? What would be great, is if someone assigned the bugs to relevant developers. Once someone is assigned to the bug report, they get emails whenever it's updated. But that someone needs to know who to charge with that bug report. Someone who would standup to maintain it would be GREAT! But even so it makes fixing bugs *slower* -- there's extra accounting work to do. I never use the sf website except to add new developers CVS access... I really think the mailing list is the best place for bug discussions. It gives new developers a chance to dive in, for instance. Understood, but there's a lot of users out there that don't want to receive emails from dri-devel. They just want to submit a bug, walk away, then get some response back to say it's fixed, or someone's working on it, or it won't be fixed etc. But with the SF bug tracking system we are currently sending bug reports, patches etc to the dri-patches mailing list. Maybe we should re-route them to dri-devel to get more feedback. The problem we're facing is that there's no formal process to assigning the bug report, so no-one else knows whether someone could be working on it or not, thus duplicating effort. Development is ideally what we all want to be doing, but there's a few admin type tasks we really do have to bear - and that's the uphill struggle. So as I'm currently not having developers CVS access I'll offer to help, here. But be patient with me if I sometimes assign the wrong developer to the right bug...;-) Due to the fact that I haven't read dri-patches for some time I'm not sure if all bug reports have reached the mailing list. Is it working? -Dieter BTW I'm not loving SF bug tracking, too. http://bugs.kde.org/wizard/index.php is much more advanced. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: tuxkart, and bug reports..
On Thursday 13 June 2002 19:01, Alan Hourihane wrote: On Thu, Jun 13, 2002 at 05:52:59PM +0100, José Fonseca wrote: On 2002.06.13 17:19 Alan Hourihane wrote: ... If Dieter is volunteering to go through it - then power to him... Alan, it's not as simple as that. Although it's very kind of him to volunteer, we all must get to a consensus before taking actions. Do you really think that that consensus exists? Then I ask again who [of the developers] compromises here that will indeed give answer to the bugs posted there? No - I don't think a consensus exists, and you probably won't get it. The people who want it, need to be willing to maintain it, and the people who don't - don't. But those people who are willing, need to maintain for those that don't too. If that's an unworkable situation, then we should close the bug tracking on sourceforge and force users to submit emails to dri-devel. That's something I can certainly agree with Keith on. Me too. -Dieter ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk: tdfx, textures are all blue and mostly invisible
On Tuesday 04 June 2002 14:32, Michel Dänzer wrote: On Tue, 2002-06-04 at 06:12, Dieter Nützel wrote: I checked out the latest trunk update and found that the textures are broken, now. They are mostly invisible and blue. Maybe I have some compiler/optimization problems because I'm testing some better gcc flags for the Athlon. -O -mcpu=i686 -march=i686 -fno-gcse -fno-regmove -fomit-frame-pointer -mpreferred-stack-boundary=2 All stuff is working and fast except of the textures (the only thing that changed in the tree apart from the Radeon stuff). Should be fixed now (tested r128 on the Athlon box at work, it was also broken by my last changes), the problem was that __BIG_ENDIAN is also defined on little endian. I'm not sure if this fix will build on all Mesa platforms though, maybe we'll have to introduce something like Xarch.h. OK, thank's Michel. Back to normal. -Dieter ___ 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] Re: tdfx: mesa-4-0-branch parsec texture corruption and VTK clipping
Am Donnerstag, 20. Dezember 2001 18:10 schrieben Sie: Dieter Nützel wrote: Am Dienstag, 18. Dezember 2001 10:29 schrieben Sie: Dieter Nützel wrote: Hello Keith, I have rechecked parsec build 0196/0197 and VTK Hanoi (the clipping problem). Both reported problems still exists. In Parsec all the the cockpit, menu and spaceship textures are missing and with VTK's Hanoi I see the clipping error (image available). In VTK's medical2 and medical3 the two black lines bug is fixed. The trunk tdfx driver do not show the parsec and Hanoi things. Dieter, I'll look at the vtk problem today or tomorrow. As always, good work! The VTK Hanoi probem (btw not only with that demo app) is fixed with the latest CVS update. I've taken it today (Mesa-4.0.1). The parsec bug will have to wait as I'm on a modem can't pull down 81meg in any reasonable time. Poor boy ;-) Actually Brian sent me it on a cd, and this should be fixed now too. Good to hear. Yes, it is fixed. Nice grafiks for a free ware product, I think. Now, I will have a look on the Glide3 3Now! texture bug, again. Have you read my numbers? Even my Xig OpenGL report? Thank you very much for all your work and Merry Christmas! -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-0-branch/tdfx --- Optimization
Am Donnerstag, 6. Dezember 2001 13:50 schrieb Keith Whitwell: Dieter Nützel wrote: Oh, I've forgotten to send you a little screenshot. It shows some texture/clipping errors, too. I don't have this, and I haven't been able to see anything similar in other programs. Can you retest? Q3A 1.30 (final) is running at the same speed as with the trunk. But some texture problems? The Intro screen and all Cinematics are playing but do not show up. Fixed. Yes. I get 30 fps with in fullscreen, now. Hope, we get S3TC sometime... ...maybe with SLI... --- 60 fps were GREAT... System here: 1 GHz Athlon II SlotA (0,18µm, mmx fxsr syscall mmxext 3dnowext 3dnow) MSI MS-6167 Rev 1.0B (AMD Irongate C4 without bypass) 640 MB PC100-2-2-2 SDRAM AHA-2940 UW IBM UW/U160 disks Voodoo5 5500 AGP PARSEC V0.99 build 0196 is running but some texture are missing (on the space ships and some of the cockpit environment. Again, I don't have this - can you retest? Not, tried with PARSEC V0.99 build 0196 (shipped with SuSE 7.3) and 0197 update from November. Trunk worked with 0196. Now I see a slowdown with ipers, gloss (teapot mode) and with VTK's Simple Sphere Benchmark V 2.1/2.3 (yes, V 2.1 is faster, it use a bigger sphere per default). trunk 3-5 4-0 --- -- gears (fps) 770 766 770 ipers (fps) 15-16 not tested 11-12 :-( texture disabled, no fog, but I see no difference if I swith fog on or off 80.000-100.000 fewer Poly/sec 1 fps faster gloss (fps) 57 not tested 50 teapot 2 frames/s faster, now sph V 2.1 167015001580 sph V 2.3 137012501340 kpolys/s little faster, too 1613 kpolys/s VTK/Local vtk sphere-bench.tcl-2.1 [1] 18330 VTK/Local * XMesaCloseFullScreen * [1]Fertigvtk sphere-bench.tcl-2.1 graphics/examplesTcl vtk TestLargeTextures.tcl Mesa implementation error: tdfx driver: extreme texmem fragmentation Please report to the DRI bug database at dri.sourceforge.net tdfxTMAllocTexMem returned NULL! unit=0 size=16777216 Is there a texture rendering slowdown? These don't seem too bad except for ipers, which is probably a Mesa issue. I'll look at these after the merge to the trunk. Some more polys, now (30.000). ** Now it is time for optimization. Let's start with fixing the remaining Glide3 texture bug when 3DNow! is enabled. When ever I try to compile a Glide3 lib with debug enabled it sigfault. Can I reach Daryll anywhere? Any advice? Mesa/demos texdown GL_VENDOR = VA Linux Systems, Inc. GL_VERSION = 1.2 Mesa 4.0.1 GL_RENDERER = Mesa DRI 20010624 Voodoo4 x86/MMX/3DNow! Speicherschutzverletzung (core dumped) [-] Reading symbols from /usr/X11R6/lib/libXxf86dga.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86dga.so.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.1 #0 0x466adac6 in _trisetup_3DNow_win_nocull_valid () from /usr/lib/libglide3.so (gdb) bt #0 0x466adac6 in _trisetup_3DNow_win_nocull_valid () from /usr/lib/libglide3.so #1 0x0003 in ?? () Error accessing memory address 0x3: No such process. (gdb) info registers eax0x466adac0 1181407936 ecx0x0 0 edx0x40 64 ebx0x468f5060 1183797344 esp0xbfffeb68 0xbfffeb68 ebp0x3 0x3 esi0x468f5020 1183797280 edi0x40 64 eip0x466adac6 0x466adac6 eflags 0x210202 2163202 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x2b 43 gs 0x2b 43 fctrl 0x7f 127 fstat 0x0 0 ftag 0x0 0 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop0x0 0 xmm0 0x xmm1 0x xmm2 0x xmm3 0x xmm4 0x xmm5 0x xmm6 0x xmm7 0x mxcsr 0x1f80 8064 ** Second: You can not build Glide3 with 3DNow! acceleration the normal way: ./chores.3dfx --clean --generate --configure=--enable-amd3d --build 'cause something in the build system (configuration) is broken. If you do it this way you will get a much bigger lib in which one token is undefined. SunWave1cd
Re: [Dri-devel] mesa-4-0-branch: only one compilation error left
Am Donnerstag, 29. November 2001 09:42 schrieb Alan Hourihane: That's because you need to use the mesa_4_0_branch check out from mesa3d too, and not the trunk code. You call the Mesa CVS (4.1) which I use, the trunk? So I have to checkout the Mesa 4.0/4.0.1 branch? Thanks, Dieter Alan. On Thu, Nov 29, 2001 at 04:26:37AM +0100, Dieter Nützel wrote: Hello Keith, I've checked out a clean mesa-4-0-branch, again and get at least only one compilation error. It is in the glX code. Thanks, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-0-branch: only one compilation error left
Am Donnerstag, 29. November 2001 16:40 schrieb Alan Hourihane: On Thu, Nov 29, 2001 at 04:31:30PM +0100, Dieter Nützel wrote: Am Donnerstag, 29. November 2001 09:42 schrieb Alan Hourihane: That's because you need to use the mesa_4_0_branch check out from mesa3d too, and not the trunk code. You call the Mesa CVS (4.1) which I use, the trunk? So I have to checkout the Mesa 4.0/4.0.1 branch? Correct. Hip, hip, hurray. I have the DRI mesa-4-0-branch finally running on my Voodoo5 5500 AGP. UT (436) is running as smooth as with the trunk. Q3A 1.30 (final) is running at the same speed as with the trunk. But some texture problems? The Intro screen and all Cinematics are playing but do not show up. PARSEC V0.99 build 0196 is running but some texture are missing (on the space ships and some of the cockpit environment. Now I see a slowdown with ipers, gloss (teapot mode) and with VTK's Simple Sphere Benchmark V 2.1/2.3 (yes, V 2.1 is faster, it use a bigger sphere per default). trunk 3-5 4-0 - gears (fps) 770 766 770 ipers (fps) 15-16 not tested 11-12 :-( texture disabled, no fog, but I see no difference if I swith fog on or off 80.000-100.000 fewer Poly/sec gloss (fps) 57 not tested 50 teapot sph V 2.1 167015001580 sph V 2.3 137012501340 kpolys/s Is there a texture rendering slowdown? VTK/Local vtk sphere-bench.tcl-2.1 [1] 2377 VTK/Local * XMesaCloseFullScreen * [1]Fertigvtk sphere-bench.tcl-2.1 It was no fullscreen context, I am sure. Another texture memory problem (saw that with the trunk, too). graphics/examplesTcl vtk TestLargeTextures.tcl Mesa implementation error: tdfx driver: extreme texmem fragmentation Please report to the DRI bug database at dri.sourceforge.net Mesa implementation error: AllocTexMem returned NULL! tmu=0 texmemsize=16777216 Please report to the DRI bug database at dri.sourceforge.net Last one: KPager (KDE-2.2.2) and the DVD player Mplayer (gmplayer is the X frontend) (http://www.MPlayerHQ.hu/homepage/) interfear. It is Xv extention related. To few memory on the board left? /home/nuetzel WARNING: KDE detected X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 14 In file kernel/qpixmap_x11.cpp, line 1629: Out of memory Maybe an QT error? Thanks, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-0-branch: only one compilation error left
Oh, I've forgotten to send you a little screenshot. It shows some texture/clipping errors, too. Yours, Dieter Am Donnerstag, 29. November 2001 23:23 schrieb Dieter Nützel: Am Donnerstag, 29. November 2001 16:40 schrieb Alan Hourihane: On Thu, Nov 29, 2001 at 04:31:30PM +0100, Dieter Nützel wrote: Am Donnerstag, 29. November 2001 09:42 schrieb Alan Hourihane: That's because you need to use the mesa_4_0_branch check out from mesa3d too, and not the trunk code. You call the Mesa CVS (4.1) which I use, the trunk? So I have to checkout the Mesa 4.0/4.0.1 branch? Correct. Hip, hip, hurray. I have the DRI mesa-4-0-branch finally running on my Voodoo5 5500 AGP. UT (436) is running as smooth as with the trunk. Q3A 1.30 (final) is running at the same speed as with the trunk. But some texture problems? The Intro screen and all Cinematics are playing but do not show up. PARSEC V0.99 build 0196 is running but some texture are missing (on the space ships and some of the cockpit environment. Now I see a slowdown with ipers, gloss (teapot mode) and with VTK's Simple Sphere Benchmark V 2.1/2.3 (yes, V 2.1 is faster, it use a bigger sphere per default). trunk 3-5 4-0 --- -- gears (fps) 770 766 770 ipers (fps) 15-16 not tested 11-12 :-( texture disabled, no fog, but I see no difference if I swith fog on or off 80.000-100.000 fewer Poly/sec gloss (fps) 57 not tested 50 teapot sph V 2.1 167015001580 sph V 2.3 137012501340 kpolys/s Is there a texture rendering slowdown? VTK/Local vtk sphere-bench.tcl-2.1 [1] 2377 VTK/Local * XMesaCloseFullScreen * [1]Fertigvtk sphere-bench.tcl-2.1 It was no fullscreen context, I am sure. Another texture memory problem (saw that with the trunk, too). graphics/examplesTcl vtk TestLargeTextures.tcl Mesa implementation error: tdfx driver: extreme texmem fragmentation Please report to the DRI bug database at dri.sourceforge.net Mesa implementation error: AllocTexMem returned NULL! tmu=0 texmemsize=16777216 Please report to the DRI bug database at dri.sourceforge.net Last one: KPager (KDE-2.2.2) and the DVD player Mplayer (gmplayer is the X frontend) (http://www.MPlayerHQ.hu/homepage/) interfear. It is Xv extention related. To few memory on the board left? /home/nuetzel WARNING: KDE detected X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 14 In file kernel/qpixmap_x11.cpp, line 1629: Out of memory Maybe an QT error? Thanks, Dieter Bildschirmphoto1.png Description: PNG image
Re: [Dri-devel] mesa-4-0-branch: Not in good shape?
Am Donnerstag, 22. November 2001 17:20 schrieb Keith Whitwell: Dieter Nützel wrote: Am Mittwoch, 7. November 2001 07:07 schrieb Keith Whitwell: Dieter Nützel wrote: Yes, I know it _is_ wok in progress, but I am trying to test it. The former mesa-3-5-branch has some bugs in conjunction with the tdfx driver and was slower as the trunk. I think it is worth to test it before it goes on. Can you be a little more specific, here? but when they do it will behave exactly as the 3-5 branch does because it is the same code. If you can find out why the 3-5 branch is slower, then that would be useful information. Yep. Dieter, Can you give me some information about the bugs you're talking about? First, I have to say sorry for my delay. I had my birthday on Thursday and was of since Friday afternoon (CET) 'cause my ISP was in trouble. All test are done with the tdfx driver (Voodoo5 5500 AGP) ;-) trunk: A texture bug show up with VTK. graphics/examplesTcl vtk TestLargeTextures.tcl Mesa implementation error: tdfx driver: extreme texmem fragmentation Please report to the DRI bug database at dri.sourceforge.net tdfxTMAllocTexMem returned NULL! unit=0 size=16777216 mesa-3-5: UT (436, latest) show a hall mirror effect, it looks like that there is some (whole) scene redraw missing. When I stop it immediately (press ESC) I can restart in again (for some seconds) or use the system the normal way. But when it runs for 10 seconds or a little bit longer the X server hangs hard. I have no remote console so I have to use SysRq+R. What about the performance issues? Where are you seeing slowdowns? I see a little slowdown with gears and with VTK's Simple Sphere Benchmark V 2.1/2.3 (yes, V 2.1 is faster, it use a bigger sphere per default). gears sph V 2.1 sph V 2.3 --- trunk 770 1670 kpolys/s 1370 kpolys/s 3-5 766 1500 kpolys/s 1250 kpolys/s VTK/Local vtk sphere-bench.tcl-2.1 [1] 3558 VTK/Local * XMesaCloseFullScreen * [1]Fertigvtk sphere-bench.tcl-2.1 mesa-4-0: My Mesa dir point to /opt/Mesa --- Mesa-CVS (4.1) Do _NOT_ compile without errors for me :-( mtypes.h version is -rw-r--r--1 nuetzel users 54639 Nov 19 16:07 /opt/Mesa/src/mtypes.h Thanks, Dieter gcc -c -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -I../../../../exports/include -I../../../../exports/include/X11 -I../../../../include/extensions -I/opt/Mesa/src -I../../../../lib/GL/dri-I/opt/Mesa/include -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 -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM accum.c accum.c:48: macro `ASSERT_OUTSIDE_BEGIN_END' used with just one arg accum.c:69: macro `ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH' used with just one arg accum.c: In function `_mesa_ClearAccum': accum.c:48: parse error before `)' accum.c:48: parse error before `)' accum.c:55: warning: implicit declaration of function `TEST_EQ_4V' accum.c:58: warning: implicit declaration of function `FLUSH_VERTICES' accum.c:58: `_NEW_ACCUM' undeclared (first use in this function) accum.c:58: (Each undeclared identifier is reported only once accum.c:58: for each function it appears in.) accum.c: In function `_mesa_Accum': accum.c:69: parse error before `)' accum.c:69: parse error before `)' accum.c:71: request for member `accumRedBits' in something not a structure or union accum.c:72: warning: implicit declaration of function `_mesa_error' accum.c:77: warning: implicit declaration of function `_mesa_update_state' accum.c:94: structure has no member named `Accum' make[5]: *** [accum.o] Error 1 rm -f api_arrayelt.o gcc -c -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -I../../../../exports/include -I../../../../exports/include/X11 -I../../../../include/extensions -I/opt/Mesa/src -I../../../../lib/GL/dri-I/opt/Mesa/include -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
RE: [Dri-devel] tdfx mesa-3-5-branch fix. / status / Glide3 / 3DNow!
Hello all, after your latest fixes I've to report the following issues together with my Voodoo5 5500 AGP. First of all: Do I have to use the Mesa-4.0 CVS tree? Keith what was the name of the path variable, again? 1. UT 436 show a mirror hall effect (it seems to me that there are some redraw/flush events missing). First I can stop it with the ESC key but later it crash and hang the whole X server. 2. Parsec show some texture corruption. 3. Triangle calculation is much slower. For example ipers goes down to ~11 fps where the trunk gave me 15~16 fps on my 1 GHz Athlon II SlotA (with Glide3 _WITH_ 3DNow! optimizations on). --- Yes, I got it working, again. Later more on this topic. Second example, VTK (sphere-bench.tcl-2.1, stripper mode) goes down to ~1450kpolys/s where as the trunk gave ~1640kpolys/s. mesa-3.5: VTK Simple Sphere Benchmark 2.1 - Robert Riviere (results) : [EMAIL PROTECTED] www.inria.fr/caiman/personnel/Robert.Riviere/vtk/sphere-bench.html - Sebastien Barre (script) : [EMAIL PROTECTED] www.hds.utc.fr/~barre/vtk/sphere-bench.html Find the best sphere resolutions for your card, launch *bench combinations* and send us your results (copy the session with Control /) along with a complete description of your system (VTK/OS version, hardware description). System : - i686 running Linux 2.4.11-pre2-preempt - VTK 3.2.0 (rev: 1.995, 2001/10/04 00:04:14) - OpenGL - Visual is 1280x1024, truecolor/truecolor/24 - Tcl/Tk 8.3.2 Defaults : WARNING : $active_camera GetClippingRange was 2.45199 4.78654 , should be 0.348564 17.4282 - VTK : wrong, please report us your values... - Rotation limit, increment, number : (300 by 30) x 3 - Sphere opacity (if transparency activated) : 0.3 - Sphere radius and small radius (if small_sphere activated) : 0.9, 0.5 - Combinations : [stripper] [small_sphere] [] [transparency] [wireframe] [texture] [texture, transparency] NOTE : the 512x512 and above sphere resolutions are *really* high, use them carefully, as it might hang your system for a while. Moreover, they have no real signification in 400x400 or less window. IMPORTANT : move the camera a little to interact with the sphere before playing with this bench... Benching for sphere resolutions : 32, 64, 128, 256, 512 Setting(s) : window is 400 x 400, sphere radius is 0.9 Option(s) : [stripper] 32x32 : 174.6 kpolys/s 64x64 : 974.4 kpolys/s 128x128 : 1156.0 kpolys/s 256x256 : 1228.6 kpolys/s 512x512 : 1452.4 kpolys/s *** I get one segmentation fault with the 3DNow! accelerated Glide3 lib: SunWave1nm /usr/lib/libglide3.so.3.1 |grep 3DNow 00035d00 T _grDrawTriangles_3DNow 000367fd T _grDrawVertexList_3DNow_Clip 00036440 T _grDrawVertexList_3DNow_Window 000351c0 T _grTexDownload_3DNow_MMX 00035300 T _trisetup_3DNow_clip_cull_invalid 00035300 T _trisetup_3DNow_clip_cull_valid 00035300 T _trisetup_3DNow_clip_nocull_invalid 00035300 T _trisetup_3DNow_clip_nocull_valid 00035540 T _trisetup_3DNow_win_cull_invalid 00035800 T _trisetup_3DNow_win_cull_valid 00035300 T _trisetup_3DNow_win_nocull_invalid 00035ac0 T _trisetup_3DNow_win_nocull_valid SunWave1gdb geartrain core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-suse-linux...(no debugging symbols found)... Core was generated by `geartrain'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libglut.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/X11R6/lib/libglut.so.3 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /lib/libpthread.so.0...done. rw_common (): write: Success. warning: unable to set global thread event mask [New Thread 1024 (LWP 9422)] rw_common (): write: Success. warning: stop_or_attach_thread: generic error Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6
[Dri-devel] Re: Progress of mesa-3.5 tree? Update to Mesa-3.6/4.0
Brian Paul wrote: Here's the deal. The DRI developers, including myself, have been laid-off from VA Linux. Today (Friday) is my last day. That's sad. But how the world goes. Daryll, what are you doing, next? There's an effort to relocate us to a new organization but it's too early to say what'll happen on that front. In the mean time, some of us will try to do some DRI work in our spare time. Progress might be slow though. Volunteers are all the more welcome now. Some little hope ;-) Good luck to all of you and as always may the source be with you. Greetings, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Feedback on preemptible kernel patch
Am Freitag, 14. September 2001 06:35 schrieb Robert Love:
On Thu, 2001-09-13 at 22:47, Dieter Nützel wrote:
-- ReiserFS may be another problem.
Can't wait for that.
Most wanted, now.
third, you may be experiencing problems with a kernel optimized for
Athlon. this may or may not be related to the current issues with an
Athlon-optimized kernel. Basically, functions in arch/i386/lib/mmx.c
seem to need some locking to prevent preemption. I have a basic patch
and we are working on a final one.
Can you please send this stuff along to me?
You know I own an Athlon (since yester Athlon II 1 GHz :-) and need some
input...
Yes, find the Athlon patch below. Please let me know if it works.
Tried it and it works so far.
It seems to be that kswap put some additional load on the disk from time to
time. Or is it the ReiserFS thing, again?
Mobo is MSI MS-6167 Rev 1.0B (AMD Irongate C4, yes the very first one)
Kernel with preempt patch and mmx/3dnow! optimization crash randomly.
Never had that (without preempt) during the last two years.
Oh, I did not remember you having problems with Athlon. I try to keep a
list of what problems are being had.
Have you a copy of my posted ksymoops file?
But the oopses seems to be cured.
Are there any other configurations where you have problems?
I don't know exactly 'cause kernel hacking is not my main focus.
But have you thought about the MMX/3DNow! stuff in Mesa/OpenGL (XFree86 DRI)?
And what do you think about the XFree86 Xv extentions (video) or the whole
MPEG2/3/4, Ogg-Vorbis, etc. (multimedia stuff)?
Do all these libraries (progs) need some preempt patches?
That's why I cross posted to the DRI-Devel List (sorry).
Before applying, note there are new patches at
http://tech9.net/rml/linux - a patch for 2.4.10-pre9 and a _new_ patch
for 2.4.9-ac10. These include everything (highmem, etc) except the
Athlon patch.
The problem with Athlon compiled kernels is that MMX/3DNow routines used
in the kernel are not preempt safe (but SMP safe, so I missed them).
This patch should correct it.
I understand ;-)
It seems to calm it.
diff -urN linux-2.4.10-pre8/arch/i386/kernel/i387.c
linux/arch/i386/kernel/i387.c ---
linux-2.4.10-pre8/arch/i386/kernel/i387.c Thu Sep 13 19:24:48 2001 +++
linux/arch/i386/kernel/i387.c Thu Sep 13 20:00:57 2001
@@ -10,6 +10,7 @@
#include linux/config.h
#include linux/sched.h
+#include linux/spinlock.h
#include asm/processor.h
#include asm/i387.h
#include asm/math_emu.h
@@ -65,6 +66,8 @@
{
struct task_struct *tsk = current;
+ ctx_sw_off();
+
if (tsk-flags PF_USEDFPU) {
__save_init_fpu(tsk);
return;
diff -urN linux-2.4.10-pre8/include/asm-i386/i387.h
linux/include/asm-i386/i387.h ---
linux-2.4.10-pre8/include/asm-i386/i387.h Thu Sep 13 19:27:28 2001 +++
linux/include/asm-i386/i387.h Thu Sep 13 20:01:30 2001
@@ -12,6 +12,7 @@
#define __ASM_I386_I387_H
#include linux/sched.h
+#include linux/spinlock.h
#include asm/processor.h
#include asm/sigcontext.h
#include asm/user.h
@@ -24,7 +25,7 @@
extern void restore_fpu( struct task_struct *tsk );
extern void kernel_fpu_begin(void);
-#define kernel_fpu_end() stts()
+#define kernel_fpu_end() stts(); ctx_sw_on()
#define unlazy_fpu( tsk ) do { \
Now, here are my results.
Athlon II 1 GHz (0.18 µm)
MSI MS-6167 Rev 1.0B (Irongate C4)
640 MB PC100-2-2-2 SDRAM
IBM DDYS 18 GB U160 (on AHA-2940UW)
ReiserFS 3.6 on all partitions
dbench-1.1 32 clients
2.4.10-pre9
Throughput 22.8881 MB/sec (NB=28.6102 MB/sec 228.881 MBit/sec)
15.000u 52.710s 3:05.59 36.4% 0+0k 0+0io 911pf+0w
load: 3168
2.4.10-pre9 + patch-rml-2.4.10-pre9-preempt-kernel-1
Throughput 22.7157 MB/sec (NB=28.3946 MB/sec 227.157 MBit/sec)
15.070u 52.730s 3:06.97 36.2% 0+0k 0+0io 911pf+0w
load: 2984
bonnie++
2.4.10-pre
Version 1.92a --Sequential Output-- --Sequential Input-
--Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec
%CP
SunWave1 1248M 117 95 14510 16 6206 6 189 98 27205 16 289.8
4
Latency 107ms2546ms 720ms 99241us 75832us3449ms
Version 1.92a --Sequential Create-- Random
Create
SunWave1-Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec
%CP
16 4215 38 + +++ 14227 93 8885 79 + +++ 4324
35
Latency 584ms8221us 14158us7681us 14274us 794ms
load: 321
2.4.10-pre9 + patch-rml-2.4.10-pre9-preempt-kernel-1
Version 1.92a --Sequential Output-- --Sequential Input-
--Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP
[Dri-devel] Progress of mesa-3.5 tree? Update to Mesa-3.6/4.0?
Anybody (Brian, Keith?) working on the Mesa-3.5-tree? I've didn't see any activity for some days/weeks, now. It would be very nice to see the Mesa-4.0/OpenGL 1.3 stuff comming, soon. The current Mesa-3.5 stuff crash under UT (all versions) with the Voodoo5 after some seconds. At the beginning you see (hall) mirroring all over the scene. 3D objects are translucent/transparent for some angles if they shouldn't. Thanks, Dieter BTW I would express my condolences to the USA and all there citizen. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: couple of questions about Glide3 ...
FROM: Daryll Strauss DATE: 06/30/2001 07:25:41 SUBJECT: RE: [Dri-devel] couple of questions about Glide3 ... On Sat, Jun 30, 2001 at 06:29:13AM -0500, EMAIL: PROTECTED wrote: 1) is anyone still maintaining the Glide source/CVS ? Not really. Too, sad ;-) 2) anyone noticed problems while compiling Glide3 for Voodoo5 with debug on? I get this error with the GL apps i tried (gears, Quake3, mine), except glxinfo which seems ok: gd.0: GLIDE DEBUG LIBRARY gd.0: cpu: 0x6 _grValidateState: alpha writes enabled even though depth buffering. gd error (glide): _grValidateState: alpha writes enabled even though depth buffering. I suspect that error message is a hold over from preV3 versions of Glide. It is perfectly legal to use Alpha and Depth later hardware, but it wasn't on the V1 or V2. I got this with all Glide versions since the beginning. Hello Daryll :-) Even Bill White couldn't fix it. BTW Glide3 didn't compile with 3DNow! enabled since last autumn (?). So I thing all distros ship without it. I'll looking into it if I reget a new clean CVS checkout... Any helping hands out there? Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Linux 2.4.5-ac14
Am Freitag, 15. Juni 2001 13:24 schrieben Sie: Dieter Nützel wrote: Am Freitag, 15. Juni 2001 05:32 schrieb Dieter Nützel: Am Freitag, 15. Juni 2001 04:30 schrieb John Cavan: Dieter Nützel wrote: Hello Alan, I see 4.29 GB under shm with your latest try. something wrong? - I don't seem to have the problem... You are using HIGHMEM?! Sort of necessary when you have 1gb of RAM. My machine is also a dual CPU box. You lucky man:-) I wish I had my dual Athlon MP 1/1.2 GHz with 512 MB DDR-SDRAM, now... I tested some more and found this. It is XFree86 4.1.0 DRI (tdfx driver) related. During my first run I used the 2.4.5-ac14 kernel DRM module. Now I am running with the latest DRI trunk DRM module. Both show the same symptoms. Well, I'm running XFree86 4.1.0 DRI with the Radeon driver and I don't show the symptoms. I use the Radeon module from DRI on SourceForge. Have you tried it with CONFIG_HIGHMEM in the kernel? No, but Christoph Rohland [EMAIL PROTECTED] (the SHM maintainer) send me a fix for it. It should appear in Alan's next try. Thanks for your fast response! -Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk) 4.1.0
Hello, UT show the same texture corruption running XFree86 DRI 4.1.0 (after David's update) with the tdfx driver (V5 5500, 1280x1024x24) as I reported some days ago for the trunk-branch. Every other thing I've tested looks OK. Even Xv (good work Alan). But I have some Linux 2.4.5-ac14 shm problems, now. Read my post here about it or at LKM. Regards, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] trunk: Latest update and before have broken textures with UT
Hello Brian, the rails (in the startup demo) and some other textures are broken. I've send Alan a post about the older version but he haven't have a copy of UT. Loki are you listening? Picture is available. -Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mesa-3.5-branch: The SPARC stuff
Hello Brian, one (?) file is missing in Mesa-3.5: make[5]: *** No rule to make target `/opt/Mesa/src/SPARC/misc.S', needed by `misc.S'. Stop. Thanks, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: [Mesa3d-dev] Re: mesa assuming glibc 2.2? (Cannot compile4.
It would be more complicated soon as more and more people start using the new Athlon 4/MP / Duron mobile 'cause they support 3DNow! Professional (full Intel SSE). The configure script (the user?) have to decide which one to use (3DNow!/3DNow! enhanced or SSE). Gareth which perform better on Athlon / Duron? If I remember right you found that 3DNow! on your Duron 600 was faster then SSE on your PIII 700 mobile? Regards, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: mesa assuming glibc 2.2? (Cannot compile4.
Am Mittwoch, 6. Juni 2001 04:55 schrieb Dieter Nützel: It would be more complicated soon as more and more people start using the new Athlon 4/MP / Duron mobile 'cause they support 3DNow! Professional (full Intel SSE). The configure script (the user?) have to decide which one to use (3DNow!/3DNow! enhanced or SSE). Gareth which perform better on Athlon / Duron? If I remember right you found that 3DNow! on your Duron 600 was faster then SSE on your PIII 700 mobile? Regards, Dieter Ups, sorry wrong List...;-) -Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Couldn't SuSE Labs or RedHat hire Gareth Hughes then?
My association with VA Linux Systems came to and end last week. Many of you will not know that I was never actually an employee of Precision Insight or VA. I started at PI as a contractor, with the expectation that once US work visa issues were resolved I'd relocate from Australia and come on as a full-time employee. Of course, the acquisition of PI by VA happened during this time, which made things slightly more complex than I had hoped. Unfortunately, due to circumstances I will not go into here, I never actually became an employee of VA and my contract was cancelled at the end of last month. What does this mean with respect to the DRI and Mesa projects? At the very least, I am going to take a well-earned break from things, and put aside all of my recent work on the DRM, Mesa 3.5 and the various drivers. Some of the work that's nearing completion (backwards compatibility stuff in the DRM in particular) will be handed over to VA, but I've stopped working on everything else. This break may very well turn into a permanant thing, and if that is the case I wish everyone the best of luck, it has been great working on Mesa and the drivers for the last year or two. I will certainly follow progress with interest no matter what happens. Oh yeah, and this is my permanent email address as well, for those who want it. -- Gareth I am very sad about this. Thank you for all of your input and great work! -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [ dri-Bugs-426782 ] Radeon + ASUS a7m266 MB
The a7m266 uses the AMD 761 chipset. Apparently that chipset is not supported yet. Can anyone confirm that? Search LKM and watchout for Alan Cox's info about AGP and the unknown chipset option (agp_try_unsupported=1). rmmod agpgart (if loaded) modprobe agpgart agp_try_unsupported=1 http://marc.theaimsgroup.com/?l=linux-kernelm=99020035221700w=2 (Alan) http://marc.theaimsgroup.com/?l=linux-kernelm=99019573701270w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=99021090127835w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=99022158532611w=2 Let us know what you get. -Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon on Irongate: DRI locks up machine instantly
and the chipset is one a lot of people have had problems with: an AMD IronGate AMD-751 (though most of the problems I've seen reported on the lists have been Radeon+AMD-750, not 751). I can only comment on this. AMD-750 (760/760MP with DDR-SDRAM support) is the name for the whole chipset. AMD-751 (761) System Controller (Northbridge); AGP, etc. AMD-756 (766) Peripheral Bus Controller (Southbridge); IDE, etc. http://www.amd.com/products/cpg/athlon/techdocs/index.html Regards, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] trunk 05.05.2001: SIS broken
I have it disabled in my host.cf but it stops compilation. Greetings, Dieter gcc -c -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../extras/Mesa/src -I../../../../../../extras/Mesa/include -I../../../../../../lib/GL/mesa/src/drv/common -I../../../../../../lib/GL/mesa/src/drv/sis -I../../../../../../lib/GL/dri -I../../../../../../lib/GL/glx -I../../../../../../exports/include -I../../../../../../exports/include/GL -I../../../../../../lib/GL/mesa/dri -I../../../../../../programs/Xserver/GL/dri -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/hw/xfree86/drivers/sis -I../../../../../../lib/GL/dri/drm -I../../../../../../lib/GL/mesa/src/X -I../../../../../.. -I../../../../../../exports/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 -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DSIS_USE_HW_CULL -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_KATMAI_ASM -DSIS_STEREO=0 sis_alloc.c sis_alloc.c: In function `sis_alloc_fb': sis_alloc.c:124: `SIS_IOCTL_FB_ALLOC' undeclared (first use in this function) sis_alloc.c:124: (Each undeclared identifier is reported only once sis_alloc.c:124: for each function it appears in.) sis_alloc.c: In function `sis_free_fb': sis_alloc.c:154: `SIS_IOCTL_FB_FREE' undeclared (first use in this function) sis_alloc.c: In function `sis_alloc_agp': sis_alloc.c:197: `SIS_IOCTL_AGP_ALLOC' undeclared (first use in this function) sis_alloc.c: In function `sis_free_agp': sis_alloc.c:224: `SIS_IOCTL_AGP_FREE' undeclared (first use in this function) make[6]: *** [sis_alloc.o] Error 1 make[6]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL/mesa/src/drv/sis' make[5]: *** [all] Error 2 make[5]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL/mesa/src/drv' make[4]: *** [all] Error 2 make[4]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib/GL' make[3]: *** [all] Error 2 make[3]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc' make[1]: *** [Everything] Error 2 make[1]: Leaving directory `/tmp/INSTALL/SOURCE/dri/xc/xc' make: *** [Everything] Error 2 ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fwd: Re: [Dri-devel] tdfx driver: Was trunk: broken after merge
Am Dienstag, 1. Mai 2001 20:58 schrieben Sie:
On Tue, May 01, 2001 at 08:49:00PM +0200, Dieter Nützel wrote:
Sorry for the little delay but my natural hardware needed some food...
Alan you are the man!
I will spend you some beer if you ever come to Germany.
But I think you can be wankered for your whole life if all the people
around the world spend you some;-)
This one plus the two in tdfx_context.c and tdfx_texman.c
(*** fxMesa-driDrawable ) {
did it.
Good.
With this stuff running I can use the immediate mode with render and
get nearly realtime animation with my dataset.
The isosurface inputfile for render is ~83,8 MB big and render need ~90
MB of my system memory (see pmap-of-render.log).
I must send you the attached screenshot.
The following problems with the tdfx driver still exists:
* alpha channel (transparency)
see the Alpha slider (0.5) in my screenshot
the bone which should be seen in the render window
disappear (partly) for some view angles
Gareth committed some fixes for some blend problems. Try 'cvs updating' in
the mesa/src/drv/tdfx directory.
I had them allready.
But they did not help.
The problem seems to be in Khoros because the problem still exists when I set
LIBGL_ALWAYS_INDIRECT. Only there software renderer (Marching Cubes) works.
But it looks a little bit broken, too...
I saw some screen corruption after playing with alpha/translucency.
Some screenshot are available.
* the KDE (2.1.1) KPager/KSnapshot texture problems
Does this work with 'LIBGL_ALWAYS_INDIRECT' ?
Yep, sorry forgotten that.
It works -- tdfx driver?
* Xv extention
e.g. Nathan's very nice fixes made it not into
the XFree86 4.0.3 release and the current DRI (4.0.99.2) tree
mpeg banding/horizontally ghost picture under 1280x1024x24
Nathan should update his change and commit.
See related posts on DRI-Devel.
I did some testing for Nathan.
* SLI (Yes, I know...:-)
No chance.
Shit...;-)
Maybe dual head (David)?
* Glide 3DNow! build fail and corruption
I will work on this if someone of you can help me
You know that I did the first Glide 3DNow! fix with help from
Holger Waechtler
Can you give me a clue here ?
I have to recompile with 3DNow! and recheck.
Running for severall months without 3DNow! because of this.
Sadly that Bill White isn't around anylonger.
-Dieter
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] tdfx driver
The DRM module from the DRI CVS seems to work fine in 2.4.4. (The one in the kernel however does seem to be broken.) Zephaniah E. Hull. I can't second that. 2.4.4-pre8 (latest pre) was broken (rwsem problem) and the DRI drm module worked fine but the final 2.4.4 kernel module works smooth. Make sure that you do not need AGPGART for any Voodoo card. Voodoo5 5500 SunWave1#cat /proc/version Linux version 2.4.4 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Sun Apr 29 19:31:30 CEST 2001 SunWave1#lsmod Module Size Used by ppp_async 6352 1 (autoclean) ppp_generic13360 3 (autoclean) [ppp_async] slhc5120 1 (autoclean) [ppp_generic] emu10k143648 2 (autoclean) soundcore 4016 4 (autoclean) [emu10k1] tdfx 53808 1 vmmon 18544 0 (unused) parport_pc 18576 0 (autoclean) parport27648 0 (autoclean) [parport_pc] ipv6 126880 -1 (autoclean) hid11328 0 (unused) input 3456 0 [hid] usb-ohci 18064 0 (unused) usbcore48624 1 [hid usb-ohci] eepro100 16176 1 (autoclean) serial 42384 2 (autoclean) -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mesa-3-5-branch do not compile
Sorry that I botther you and yes I know it IS under development but I will try it on my V5 because I found some glitches in the trunk (more on this tomorrow). Which configuration are you using? The old style or some configure stuff? Mesa-3.5 is there and I have the right line to it in host.def. So what's up? Thanks, Dieter gcc -o gen_matypes -O -mcpu=k6 -fomit-frame-pointer -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -fexpensive-optimizations -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -I../../../../../lib/X11 -I../../../../../include/extensions -I../include -I../../include -I../../dri -I.. -I../../../include -I../../../../.. -I../../../../../exports/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 -DUSE_MAKEDEPEND -DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DFX -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM gen_matypes.c -Wl,-rpath-link,../../../../../exports/lib In file included from gen_matypes.c:40: ../glheader.h:180: glcore.h: Datei oder Verzeichnis nicht gefunden In file included from gen_matypes.c:41: ../mtypes.h:52: warning: `CHAN_MAX' redefined ../config.h:160: warning: this is the location of the previous definition ../mtypes.h:53: warning: `CHAN_MAXF' redefined ../config.h:161: warning: this is the location of the previous definition In file included from gen_matypes.c:41: ../mtypes.h:115: redefinition of `GLcontext' ../config.h:197: `GLcontext' previously declared here ../mtypes.h:1104: field `Visual' has incomplete type In file included from ../mtypes.h:1374, from gen_matypes.c:41: ../dd.h:798: parse error before `points_func' ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] What's wrong with the mesa-3.5 branch?
Am Montag, 2. April 2001 15:28 schrieb Gareth Hughes: Dieter Ntzel wrote: Hello, I've tried the mesa-3.5-branch several times during the last weeks but had no luck, yet. ... Am I missing something? Build your copy of standalone Mesa. That's what I am doing for ages... I have it all up in /opt/Mesa. Fresh cvs update and "make check", but no "install". Do I need that, too? The "bootstrap" file is missing for several weeks, now. How can I get it back? SunWave1cd demos/ Directory: /opt/Mesa/demos SunWave1./glinfo GL_VERSION: 1.2 Mesa 3.5 beta GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_tranpose_matrix GL_EXT_abgr GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_logic_op 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_paletted_texture GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_shared_texture_palette GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_object GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_HP_occlusion_test GL_INGR_blend_func_separate GL_MESA_window_pos GL_MESA_resize_buffers GL_NV_texgen_reflection GL_PGI_misc_hints GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_pixel_texture GL_SGIS_texture_edge_clamp GL_SGIX_pixel_texture GL_RENDERER: Mesa X11 GL_VENDOR: Brian Paul GLU_VERSION: 1.1 Mesa 3.3 GLU_EXTENSIONS: GL_EXT_abgr GLUT_API_VERSION: 3 GLUT_XLIB_IMPLEMENTATION: 15 But no autogenerated matypes.h? And don't be surprised that development branches are sometimes difficult to use... I am not since the beginning of the DRI/Glide stuff...:-) Thanks, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
