Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffersize
On Wed, 5 Feb 2003, Keith Whitwell wrote: > Leif Delgass wrote: > > Hurrah! ... this fixes the vertex data corruption in the UT2003 opening > > screen. There's still vertex problems in game (though not quite as much). > > The remaining problems may be because of cube mapping (I'm testing on > > R100). > > Hmm. Do you have an r200? I wonder whats up there... Nope. See my other reply (to Felix) -- there are still problems with TCL disabled and in game maps even with TCL. I was wondering if it was related to use of more than 2 texcoords, but I still had the problem with texturing disabled in ut2k3. I'm starting to look at what we need to do to handle glTexCoord3/4. The tricky thing is that the templates (e.g. radeon_maos_verts.c) seem to assume either 2 coords, or 4 coords (with r unused). We need to be able to choose either the third or fourth texcoord to put in the card's q slot, depending on whether the target is a 3D/cubemap texture or a 2D texture. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Confusing..?
cd programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ make -f Makefile.linux MODULE.o I would just add that if you're using a kernel that uses a better source directory naming scheme (e.g. 2.4.19 unpacks to linux-2.4.19 whereas 2.4.18 unpacks to just linux), you'll want to use the TREE=/usr/src/linux-2.4.XX/include option in your make command. Like so: make -f Makefile.linux TREE=/usr/src/linux-2.4.XX/include MODULE.o (I've never included the MODULE.o part, but if that works, then sweet. No sense in building r128 modules when I've got a Radeon.) and then as root: cp MODULE.o /lib/modules/`uname -r`/kernel/drivers/char/drm/ depmod -a where MODULE.o corresponds to the drm-driver you need -Andy [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffersize
Leif Delgass wrote: Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). Hmm. Do you have an r200? I wonder whats up there... Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Stop viruses and keep your PC safe qcjwp vvsir
*NEW-Special Package Deal!* 2003 McAfee Version 7.0 Software Suite - Home Edition- THE NAME THAT MEANS SECURITY FOR YOUR PC COMPUTER. Do not leave your PC open for a virus that could destroy your data. McAfee VirusScan is the #1 software used by Corporate Businesses to protect PCs against virus transmissions via the internet, disks, CDs or any media that might transmit damaging viruses. Businesses trust McAfee VirusScan over Norton AntiVirus to protect and safeguard millions of PCs around the world. Includes - Feature-Packed Utilities...ALL For ONE Special LOW Price! - McAfee VirusScan 7.0 - McAfee Firewall - Intuitive Interface - Faster Scanning Speeds - Scans & Cleans Instant-Messenger Attachments - Received 5-Stars from PC Magazine & CNET Editors's Choice Award - Scans for Viruses Faster Than Norton AntiVirus This Software Will: - Protect your computer from unwanted and hazardous viruses - Help secure your private & valuable information - Allow you to transfer files and send e-mails safely Two Feature-Packed Utilities...For One Great Price! A $100-Plus Combined Retail Value! YOURS for Only $29.99! (Includes FREE** Shipping TOO!) Don't fall prey to destructive viruses or hackers! Protect your computer and your valuable information! CLICK HERE to Order Yours NOW! http://www.2003deals4u.net/bestbuy/mcafee/mcafee.htm If you no longer wish to receive our special offers Click Here http://www.2003deals4u.net/bestbuy/rem.html k ckv korlzc oshabftlk ft trwpq hrsdy cddqv eapal jcktdl f
Re: [Dri-devel] Re: [Dri-users] Flashing textures problem with ATIRadeon 7500
On Mit, 2003-02-05 at 21:30, [EMAIL PROTECTED] wrote: > I'll second this. In some of the screenhacks from xscreensaver 4.06, > there is flickering when they are displayed on the root window (as you > would normally play them as screensavers). They don't actually render to the root window when you blank or lock the display; xscreensaver fakes a root window for them, so it's not necessarily the same thing. > I'm also still having the lockup problems I noted in the thread "DRI-CVS > pseudo-lockups on radeon.o (Radeon VE/7000)" from several weeks ago. If > this has been resolved recently in CVS (or if someone thinks it has > been), I'll be happy to try it out. Please try the current DRM, I'm curious if recent changes make a difference. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffersize
On Thu, 6 Feb 2003, Felix Kühling wrote: > On Wed, 5 Feb 2003 20:17:57 -0500 (EST) > Leif Delgass <[EMAIL PROTECTED]> wrote: > > > Hurrah! ... this fixes the vertex data corruption in the UT2003 opening > > screen. There's still vertex problems in game (though not quite as much). > > The remaining problems may be because of cube mapping (I'm testing on > > R100). > > I see lots of vertex data corruption with TCL disabled in torcs and in > quakeforge. With TCL enabled there is some strange corruption in > quakeforge when the console is active. Actually, disabling TCL does cause some vertex corruption right at the start of the intro. Also I tried disabling texturing (rmode 7) and the vertex corruption in-game is still there, so it doesn't seem to be related to cube mapping. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Flashing textures problem with ATIRadeon 7500
I'll second this. In some of the screenhacks from xscreensaver 4.06, there is flickering when they are displayed on the root window (as you would normally play them as screensavers). With a quick check, I notice this behavior in superquadrics, atlantis, moebius, queens, and pulsar (there are probably more.) I'm currently using: $ X -version This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.2 (DRI trunk) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 21 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18 i686 [ELF] Module Loader present $ and my dri module is perhaps a couple weeks old (I'm sorry that I can't be more specific than this; is there a way that I can tell from my local tree when the last time was that I checked it out?). I'm also using XFree86 on a Radeon VE (7000; I think this is *also* known as the r100 (?) ) which has no "TCL", so, when running the GL hacks, I get: $ superquadrics disabling TCL support $ I'm also still having the lockup problems I noted in the thread "DRI-CVS pseudo-lockups on radeon.o (Radeon VE/7000)" from several weeks ago. If this has been resolved recently in CVS (or if someone thinks it has been), I'll be happy to try it out. Thanks. Andy [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffer size
On Wed, 5 Feb 2003 20:17:57 -0500 (EST) Leif Delgass <[EMAIL PROTECTED]> wrote: > Hurrah! ... this fixes the vertex data corruption in the UT2003 opening > screen. There's still vertex problems in game (though not quite as much). > The remaining problems may be because of cube mapping (I'm testing on > R100). I see lots of vertex data corruption with TCL disabled in torcs and in quakeforge. With TCL enabled there is some strange corruption in quakeforge when the console is active. __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffersize
Hurrah! ... this fixes the vertex data corruption in the UT2003 opening screen. There's still vertex problems in game (though not quite as much). The remaining problems may be because of cube mapping (I'm testing on R100). On Wed, 5 Feb 2003, Keith Whitwell wrote: > Felix Kühling wrote: > > On Wed, 05 Feb 2003 16:25:27 -0700 > > Keith Whitwell <[EMAIL PROTECTED]> wrote: > > > > > >>Felix Kühling wrote: > >> > >>>I attached a patch that fixes the problem. It introduces a new > >>>TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. > >>>Looks kind of hackish to me. Does anyone have a better idea? Comments? > >> > >>Mesa should respect ctx->Const.MaxArrayVertices, which should be being set in > >>radeon_context.c --- it may be that this code is disabled - can you check > >>that & try turning it back on. > > > > > > Found it: radeon_context.c around line 375: > > /* ctx->Const.MaxArrayLockSize = */ > > /*MIN2( ctx->Const.MaxArrayLockSize, */ > > /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ > > > > And then there is the definition of RADEON_MAX_TCL_VERTSIZE in > > radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the > > real MAX_TCL_VERTSIZE is even bigger? > > Yes it is, because we went back to using vertexes instead of individual > arrays, but forgot to reset this max value. I've committed the fix. > > Keith > > > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld ÿomething 2 See! > http://www.vasoftware.com > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffersize
Felix Kühling wrote: On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx->Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that & try turning it back on. Found it: radeon_context.c around line 375: /* ctx->Const.MaxArrayLockSize = */ /*MIN2( ctx->Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Yes it is, because we went back to using vertexes instead of individual arrays, but forgot to reset this max value. I've committed the fix. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Flashing textures problem with ATI Radeon 7500
On Sun, 26 Jan 2003, qqq wrote: > > I have the same problems > > I use the dri trunk Xfree86 4.2.99 radeon 1.8.0 > > games too. > > > I was using XFree in versions 4.2, 4.2.1, cvs and from DRI, the effect > > is the same. > Maybe it is a chipset related problem, I have VIA Apollo pro, and what about you? I've similar problems with the Radeon Mobility M6 LY 16MB in a i180 chipset, on two different installations, one gcc-3.2, one gcc-3.2.1, both XF 4.2.99.3 I've walls in armagetron which flicker between normal and 100% transparent. gltron works as normal unless I set shadow type to stencil, then floor flashes in a halted (crash) scene beteen normal texture and a grey floor with strange shadows on it and I can change the flickering by only moving the camera with the mouse, so this should not be a game problem I think. Also flickering is racer, the road flashed terribly between grey and the road and also the tree textures a little. If I can do something more than sending this and the lines from the log file below, please let me know. Bernd Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 203M agpgart: Detected Intel i845 chipset agpgart: AGP aperture is 256M @ 0xe000 [drm] Module unloaded [drm] AGP 0.99 aperture @ 0xe000 256MB [drm] Initialized radeon 1.7.0 20020828 on minor 0 (--) PCI:*(1:0:0) ATI Technologies Inc Radeon Mobility M6 LY rev 0, Mem @ 0xd800/27, 0xd010/16, I/O @ 0x3000/8 (WW) RADEON(0): Restoring MEM_CNTL (), setting to 2d08 (WW) RADEON(0): Restoring CONFIG_MEMSIZE (0100), setting to 0100 (--) RADEON(0): Chipset: "ATI Radeon Mobility M6 LY (AGP)" (ChipID = 0x4c59) (--) RADEON(0): Linear framebuffer at 0xd800 (--) RADEON(0): MMIO registers at 0xd010 (--) RADEON(0): VideoRAM: 16384 kByte (64-bit DDR SDRAM) (II) RADEON(0): CloneDisplay option not set -- defaulting to auto-detect (II) RADEON(0): Primary Display == Type 2 (II) RADEON(0): Panel ID string: 1024x768 (II) RADEON(0): Panel Size from BIOS: 1024x768 (II) RADEON(0): PLL parameters: rf=2700 rd=60 min=12000 max=35000; xclk=14400 (II) RADEON(0): Validating modes on Primary head (DDCType: 0) - (II) RADEON(0): Total number of valid DDC mode(s) found: 0 (II) RADEON(0): Valid mode using on-chip RMX: 1024x768 (II) RADEON(0): Total number of valid FP mode(s) found: 1 (**) RADEON(0): Disabling page flipping (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (II) do I need RAC? No, I don't. (==) RADEON(0): Write-combining range (0xd800,0x100) (WW) RADEON(0): Cannot read colourmap from VGA. Will restore with default drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xd18d9000 (II) RADEON(0): [drm] mapped SAREA 0xd18d9000 to 0x40014000 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x8086/0x1a30; Card 0x1002/0x4c59] (II) RADEON(0): [agp] 8192 kB allocated with handle 0xd18dc000 (II) RADEON(0): [agp] ring handle = 0xe000 (II) RADEON(0): [agp] Ring mapped at 0x41264000 (II) RADEON(0): [agp] ring read ptr handle = 0xe0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x40016000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x41365000 (II) RADEON(0): [agp] AGP texture map handle = 0xe0302000 (II) RADEON(0): [agp] AGP Texture map mapped at 0x41565000 (II) RADEON(0): [drm] register handle = 0xd010 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB AGP aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for AGP textures (II) RADEON(0): Memory manager initialized to (0,0) (1024,8191) (II) RADEON(0): Reserved area from (0,768) to (1024,770) (II) RADEON(0): Largest offscreen area available: 1024 x 7421 (II) RADEON(0): Will use back buffer at offset 0x48 (II) RADEON(0): Will use depth buffer at offset 0x60 (II) RADEON(0): Will use 8704 kb for textures at offset 0x78 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 10 (II) RADEON(0): [drm] Initialized kernel agp heap manager, 5111808 ---
Re: [Dri-devel] mach64 blend
On Thu, 6 Feb 2003 00:44:12 +0200 "Arkadi Shishlov" <[EMAIL PROTECTED]> wrote: > > Now I think it is texture alpha. Quite pointless to have RGBA texture > without ability to use it alpha channel. > http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg Hows Quakeforge comming, btw - it'd be nice to play it on my Radeon 9000. fun game. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Which card?
On Wed, Feb 05, 2003 at 10:53:20PM +, John Gay wrote: > I posted this on the XFree86 list, but was refered here instead. > > I'm getting ready to rebuild my system from scratch and am pondering which > card to put into it. > > 1) a 3DLabs GVX1 AGP card. This works fine in 2D but the 3D support is still > pending. I would prefer to work with this card as I'm very interested in 3D > stuff and plan to get 3D glasses (one day ;-) > > 2) an ATI Rage128 card. I understand that this does have 3D support, but > would it warrant getting rid of hte GVX card? I think there should be much > better capabilities in the GVX1 card. Plus, the ATI card does not work with > 3D glasses. I would go with the Rage128. It's supported, it works *now*, and IMO 3D glasses are just a headache-inducing gimmick anyway. :D -- http://trikuare.cx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Confusing..?
John S. Chalice wrote: I just last night downloaded the newest CVS from dri.sourceforge.net.. and tried compiling it.. it went smoothly.. no errors.. *BUT*.. none of the kernel modules were created.. for *any* of the video drivers listed in the host.def file.. Any ideas? well, you can always build them manually after compiling the rest: cd programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ make -f Makefile.linux MODULE.o and then as root: cp MODULE.o /lib/modules/`uname -r`/kernel/drivers/char/drm/ depmod -a where MODULE.o corresponds to the drm-driver you need regards, Stefan -- John S. Chalice --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
> That would be easy enough to verify with oprofile. Just take a profile > with and without the patch. In order to get profile data on the GL > driver, do this: > oprofpp -l /usr/X11R6/lib/modules/dri/radeon_dri.so Thanks for the explanation. If there's anything else I can do to support your effort instead of pointing to FlightGear related trouble every day I'd be glad to hear - I mean, except writing C code, you don't really want to look at my C skills Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffer size
On Wed, 05 Feb 2003 16:25:27 -0700 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > > I attached a patch that fixes the problem. It introduces a new > > TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. > > Looks kind of hackish to me. Does anyone have a better idea? Comments? > > Mesa should respect ctx->Const.MaxArrayVertices, which should be being set in > radeon_context.c --- it may be that this code is disabled - can you check > that & try turning it back on. Found it: radeon_context.c around line 375: /* ctx->Const.MaxArrayLockSize = */ /*MIN2( ctx->Const.MaxArrayLockSize, */ /* RADEON_BUFFER_SIZE / RADEON_MAX_TCL_VERTSIZE ); */ And then there is the definition of RADEON_MAX_TCL_VERTSIZE in radeon_tcl.h which is (4*4). However, I saw vertex_size==24! Maybe the real MAX_TCL_VERTSIZE is even bigger? Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MarbleBlast
On Wed, 5 Feb 2003, Ian Romanick wrote: > Adam K Kirchhoff wrote: > > So there's this really great game from Garagegames called > > MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher > > or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the > > ATI FireGL drivers, but segfaults when trying to use the opensource > > drivers: > > > > Program received signal SIGFPE, Arithmetic exception. > > [Switching to Thread 16384 (LWP 2053)] > > 0x40c9fa70 in _mesa_test_os_sse_exception_support () from > > /usr/X11R6/lib/modules/dri/r200_dri.so > > (gdb) bt > > #0 0x40c9fa70 in _mesa_test_os_sse_exception_support () from > > /usr/X11R6/lib/modules/dri/r200_dri.so > > #1 0x40c9f7e7 in check_os_sse_support () at common_x86.c:191 > > This is a FAQ x 1,000,000. This is not a crash or anything bad. This > is the driver trying to detect if you CPU supports the SSE instruction > set. Type 'continue' and move on. :) So I've been told :-) > Is there a demo version of this game available? If so, it would be > useful for testing. http://www.garagegames.com/pg/demo.php?id=3 Have fun :-) It's quite an addictive little game. Adam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][patch] radeonAllocDmaRegion calledwith bytes > dma buffer size
I grepped for this and didn't find it, but in Mesa there is Const.MaxArrayLockSize which defaults to 3000 (wasn't that the count in the last backtrace?). There's nowhere in the radeon or r200 driver that refer to MaxArrayLockSize. -Leif On Wed, 5 Feb 2003, Keith Whitwell wrote: > Felix Kühling wrote: > > I attached a patch that fixes the problem. It introduces a new > > TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. > > Looks kind of hackish to me. Does anyone have a better idea? Comments? > > Mesa should respect ctx->Const.MaxArrayVertices, which should be being set in > radeon_context.c --- it may be that this code is disabled - can you check > that & try turning it back on. > > Keith > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld ÿomething 2 See! > http://www.vasoftware.com > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MarbleBlast
On Wed, 2003-02-05 at 22:58, Adam K Kirchhoff wrote: > Hello all, > > So there's this really great game from Garagegames called > MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher > or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the > ATI FireGL drivers, but segfaults when trying to use the opensource > drivers: > > Program received signal SIGFPE, Arithmetic exception. > [Switching to Thread 16384 (LWP 2053)] > 0x40c9fa70 in _mesa_test_os_sse_exception_support () from > /usr/X11R6/lib/modules/dri/r200_dri.so This is meant to happen. Its testing if FPE works. What you want to do is ignore the FPU exceptions in gdb, then run it and get the real segfault > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MarbleBlast
> > Program received signal SIGFPE, Arithmetic exception. > > [Switching to Thread 16384 (LWP 2053)] > > 0x40c9fa70 in _mesa_test_os_sse_exception_support () from > > This is expected, just press 'c' to continue. Look at the name of the > function -- it's deliberately trying to raise an exception. D'oh.. Thanks Keith and Leif. Can't believe I messed that up... Anyway, here's the important output: (gdb) c Continuing. [New Thread 32769 (LWP 1136)] [New Thread 16386 (LWP 1137)] [New Thread 32771 (LWP 1138)] [New Thread 49156 (LWP 1139)] Program received signal SIGSEGV, Segmentation fault. r200UpdateTextureEnv (ctx=0x8391a38, unit=0) at r200_texstate.c:739 739const GLenum format = tObj->Image[tObj->BaseLevel]->Format; (gdb) bt #0 r200UpdateTextureEnv (ctx=0x8391a38, unit=0) at r200_texstate.c:739 #1 0x40cc5419 in disable_tex (ctx=0x8391a38, unit=0) at r200_texstate.c:1401 #2 0x40cc5966 in r200UpdateTextureUnit (ctx=0x8391a38, unit=0) at r200_texstate.c:1644 #3 0x40cc598a in r200UpdateTextureState (ctx=0x8391a38) at r200_texstate.c:1656 #4 0x40caa521 in r200ValidateState (ctx=0x8391a38) at r200_state.c:2036 #5 0x40cc8c42 in r200NotifyBegin (ctx=0x8391a38, p=5) at r200_vtxfmt.c:918 #6 0x40c771d7 in _tnl_Begin (mode=5) at t_imm_api.c:215 #7 0x40c77301 in _tnl_hard_begin (ctx=0x8391a38, p=5) at t_imm_api.c:245 #8 0x40c7517a in fallback_drawelements (ctx=0x8391a38, mode=5, count=9, indices=0x850ea10) at t_array_api.c:65 #9 0x40c7572f in _tnl_DrawElements (mode=5, count=9, type=5123, indices=0x4091ec3c) at t_array_api.c:336 I'll gladly test what I can. Adam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MarbleBlast
Adam K Kirchhoff wrote: So there's this really great game from Garagegames called MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the ATI FireGL drivers, but segfaults when trying to use the opensource drivers: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 16384 (LWP 2053)] 0x40c9fa70 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) bt #0 0x40c9fa70 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x40c9f7e7 in check_os_sse_support () at common_x86.c:191 This is a FAQ x 1,000,000. This is not a crash or anything bad. This is the driver trying to detect if you CPU supports the SSE instruction set. Type 'continue' and move on. :) Is there a demo version of this game available? If so, it would be useful for testing. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MarbleBlast
Adam K Kirchhoff wrote: Hello all, So there's this really great game from Garagegames called MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the ATI FireGL drivers, but segfaults when trying to use the opensource drivers: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 16384 (LWP 2053)] 0x40c9fa70 in _mesa_test_os_sse_exception_support () from This is expected, just press 'c' to continue. Look at the name of the function -- it's deliberately trying to raise an exception. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Martin Spott wrote: Ian, now that you've merged in the software support for combine3 from the Mesa trunk, I'm trying to get it working in hardware on R100 with texmem (impatient as I am ;) ). Where do I find at least a short explanation on the effect this patch should show to me (to the user) ? The only impression I have after a short test is decreased frame rate in FlightGear under certain conditions. I'm pretty shure this is not your primary intention with this patch ;-) So obviously this patch is considered to improve something else that FlightGear das not benefit from, Which patch do you mean? Do you mean the patch in Leif's e-mail in this thread or the patch in his e-mail with the "[PATCH] texmem-0-0-1 branch" subject? Or do you mean something else? :) The patch in this thread should not have any impact on performance. It adds a couple of extra combine modes to the list in ARB_texture_env_combine. The patch in the other thread fixes some bugs that can lead to texture corruption when there are multiple active GL contexts. It's possible that could effect performance, but only in the case of multiple active contexts. That would be easy enough to verify with oprofile. Just take a profile with and without the patch. In order to get profile data on the GL driver, do this: oprofpp -l /usr/X11R6/lib/modules/dri/radeon_dri.so Or whatever your driver is. If more time shows up in any of the functions in lib/GL/mesa/src/drv/common/texmem.c or in the texture upload functions in the driver, then you can blame the patch. :) Either way, it would be interesting to see profiles of common apps. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MarbleBlast
You need to continue past this exception to get to the segfault. This is just Mesa testing for SSE. On Wed, 5 Feb 2003, Adam K Kirchhoff wrote: > > Hello all, > > So there's this really great game from Garagegames called > MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher > or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the > ATI FireGL drivers, but segfaults when trying to use the opensource > drivers: > > Program received signal SIGFPE, Arithmetic exception. > [Switching to Thread 16384 (LWP 2053)] > 0x40c9fa70 in _mesa_test_os_sse_exception_support () from > /usr/X11R6/lib/modules/dri/r200_dri.so > (gdb) bt > #0 0x40c9fa70 in _mesa_test_os_sse_exception_support () from > /usr/X11R6/lib/modules/dri/r200_dri.so > #1 0x40c9f7e7 in check_os_sse_support () at common_x86.c:191 > #2 0x40c9f96d in _mesa_init_all_x86_transform_asm () at common_x86.c:275 > #3 0x40c1b557 in _math_init () at m_xform.c:218 > #4 0x40bada66 in one_time_init (ctx=0x8391a38) at context.c:564 > #5 0x40bafee0 in _mesa_initialize_context (ctx=0x8391a38, > visual=0xbfffbc40, share_list=0x0, > driver_ctx=0x838e908, direct=1) at context.c:1663 > #6 0x40bb083f in _mesa_create_context (visual=0xbfffbc40, share_list=0x0, > driver_ctx=0x838e908, direct=1) > at context.c:1900 > #7 0x40ca483f in r200CreateContext (glVisual=0xbfffbc40, > driContextPriv=0x838d350, sharedContextPrivate=0x0) > at r200_context.c:252 > #8 0x40b9ca94 in driCreateContext (dpy=0x8381a50, vis=0x838ce20, > sharedPrivate=0x0, pctx=0x838e0d4) > at dri_util.c:852 > #9 0x40b53a07 in CreateContext (dpy=0x8381a50, vis=0x838ce20, > shareList=0x0, allowDirect=1, contextID=0) > at glxcmds.c:184 > #10 0x40b53b19 in glXCreateContext (dpy=0x8381a50, vis=0x838ce20, > shareList=0x0, allowDirect=1) at glxcmds.c:221 > #11 0x4004cab9 in X11_GL_CreateContext () from /usr/lib/libSDL-1.2.so.0 > #12 0x4005086d in X11_CheckMouseMode () from /usr/lib/libSDL-1.2.so.0 > #13 0x40050b9a in X11_CheckMouseMode () from /usr/lib/libSDL-1.2.so.0 > #14 0x4004690d in SDL_SetVideoMode () from /usr/lib/libSDL-1.2.so.0 > > Any ideas what might be causing this? > > Adam > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][patch] radeonAllocDmaRegion calledwith bytes > dma buffer size
Felix Kühling wrote: I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Mesa should respect ctx->Const.MaxArrayVertices, which should be being set in radeon_context.c --- it may be that this code is disabled - can you check that & try turning it back on. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffer size
On Thu, 06 Feb 2003 07:46:35 +1000 Chris Ison <[EMAIL PROTECTED]> wrote: > a couple of us QF codes are questioning this, looks like gcc > optimizations or gdb are interefering cause the way QF handles the > vertex array (with error checking), it's impossable for starters for it > send a NULL indices pointer, not to mention a 0 count. Looks like you're right. I recompiled the radeon driver with -O0 and got this: #0 0x40334581 in kill () from /lib/libc.so.6 #1 0x40334394 in raise () from /lib/libc.so.6 #2 0x403358d1 in abort () from /lib/libc.so.6 #3 0x4032edb2 in __assert_fail () from /lib/libc.so.6 #4 0x41654522 in radeonAllocDmaRegion (rmesa=0x8164680, region=0x81670c0, bytes=72000, alignment=3) at radeon_ioctl.c:635 #5 0x4165455e in radeonAllocDmaRegionVerts (rmesa=0x8164680, region=0x81670c0, numverts=3000, vertsize=24, alignment=4) at radeon_ioctl.c:647 #6 0x4165996a in radeonEmitArrays (ctx=0x8167898, inputs=265) at radeon_maos_verts.c:311 #7 0x4167d063 in radeon_run_tcl_render (ctx=0x8167898, stage=0x82e2d38) at radeon_tcl.c:318 #8 0x4162e6b3 in _tnl_run_pipeline (ctx=0x8167898) at t_pipeline.c:154 #9 0x41666a9b in radeonWrapRunPipeline (ctx=0x8167898) at radeon_state.c:2088 #10 0x4161f095 in _tnl_DrawElements (mode=2823, count=3000, type=137243856, indices=0x8318bb8) at t_array_api.c:99 #11 0x415ba8b6 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #12 0x41685fde in radeon_fallback_DrawElements (mode=7, count=3000, type=5125, indices=0x8318bb8) at ../../../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #13 0x415ba8b6 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 ---Type to continue, or q to quit--- #14 0x40026f38 in Draw_nString (x=6, y=1078070736, str=0x4144e780 "_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset", ' ' , "GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D", ' ' , "GL_EXT_texture_env_add GL_EXT_texture_env_combine "..., count=0) at gl_draw.c:367 #15 0x72676f74 in ?? () Cannot access memory at address 0x7369685f There are still a few 0 counts but the source of neutral_DrawElements is in a different directory and is still compiled with -O3. The 3000 looks more sensible. With vertex size 24 this makes 72000 bytes which is more than fits into one 64KB DMA buffer. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MarbleBlast
Hello all, So there's this really great game from Garagegames called MarbleBlast, which they've ported to Linux. Game requires TNT2 and higher or Radeon 8500 and higher. It plays just fine on my Radeon 8500 using the ATI FireGL drivers, but segfaults when trying to use the opensource drivers: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 16384 (LWP 2053)] 0x40c9fa70 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) bt #0 0x40c9fa70 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x40c9f7e7 in check_os_sse_support () at common_x86.c:191 #2 0x40c9f96d in _mesa_init_all_x86_transform_asm () at common_x86.c:275 #3 0x40c1b557 in _math_init () at m_xform.c:218 #4 0x40bada66 in one_time_init (ctx=0x8391a38) at context.c:564 #5 0x40bafee0 in _mesa_initialize_context (ctx=0x8391a38, visual=0xbfffbc40, share_list=0x0, driver_ctx=0x838e908, direct=1) at context.c:1663 #6 0x40bb083f in _mesa_create_context (visual=0xbfffbc40, share_list=0x0, driver_ctx=0x838e908, direct=1) at context.c:1900 #7 0x40ca483f in r200CreateContext (glVisual=0xbfffbc40, driContextPriv=0x838d350, sharedContextPrivate=0x0) at r200_context.c:252 #8 0x40b9ca94 in driCreateContext (dpy=0x8381a50, vis=0x838ce20, sharedPrivate=0x0, pctx=0x838e0d4) at dri_util.c:852 #9 0x40b53a07 in CreateContext (dpy=0x8381a50, vis=0x838ce20, shareList=0x0, allowDirect=1, contextID=0) at glxcmds.c:184 #10 0x40b53b19 in glXCreateContext (dpy=0x8381a50, vis=0x838ce20, shareList=0x0, allowDirect=1) at glxcmds.c:221 #11 0x4004cab9 in X11_GL_CreateContext () from /usr/lib/libSDL-1.2.so.0 #12 0x4005086d in X11_CheckMouseMode () from /usr/lib/libSDL-1.2.so.0 #13 0x40050b9a in X11_CheckMouseMode () from /usr/lib/libSDL-1.2.so.0 #14 0x4004690d in SDL_SetVideoMode () from /usr/lib/libSDL-1.2.so.0 Any ideas what might be causing this? Adam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Which card?
I posted this on the XFree86 list, but was refered here instead. I'm getting ready to rebuild my system from scratch and am pondering which card to put into it. 1) a 3DLabs GVX1 AGP card. This works fine in 2D but the 3D support is still pending. I would prefer to work with this card as I'm very interested in 3D stuff and plan to get 3D glasses (one day ;-) 2) an ATI Rage128 card. I understand that this does have 3D support, but would it warrant getting rid of hte GVX card? I think there should be much better capabilities in the GVX1 card. Plus, the ATI card does not work with 3D glasses. Unfortunately, I've only one box with AGP, my regular desktop, though I also have a PCI version of the GVX card. That is in my daughters PC. I'm not much of a programmer, yet, but I am working on it. See homepage.eircom.net/johngay/frames.html for an example of the limits of my C knowledge. I was hoping that getting inside the gamma and pm3 code could be enlightening, eventually. Cheers, John Gay --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 blend
On Tue, Feb 04, 2003 at 09:51:30PM -0500, Leif Delgass wrote: > On Wed, 5 Feb 2003, Arkadi Shishlov wrote: > > What do you mean by aren't fully compliant? Final A = Fragment A or > > Final A = Texture A? It looks like Fragment A.. > > Yes, I think that's right. As an example, there's a texture in the first > UT map (can't remember the name offhand) that uses an RGBA vine texture > with MODULATE. It looks it's applied to an opaque quad, since the > transparent part of the texture shows up as black. Now I think it is texture alpha. Quite pointless to have RGBA texture without ability to use it alpha channel. http://idea.hosting.lv/a/tmp/quakeforge-mach64-blend.jpg It is GL_MODULATE, no lighting, GL_RGBA texture, glBlend(alpha, one_minus_alpha). Looking at screenshot the first that come in mind - mach64 doesn't do linear filtering for magnification. arkadi. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
On Wed, 5 Feb 2003, Ian Romanick wrote:
> Leif Delgass wrote:
> > Ian, now that you've merged in the software support for combine3 from the
> > Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
> > (impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
> > the registers. I'm attaching a patch of what I've got. My assumptions
> > are that RADEON_BLEND_CTL_[ADD,ADDSIGNED,SUBTRACT] will do the
> > corresponding MODULATE_[ADD,ADDSIGNED,SUBTRACT] with three args. Also,
> > I'm assuming I can use RADEON_[COLOR,ALPHA]_ARG_A_ZERO or-ed with
> > _COMP_ARG_A to get GL_ONE.
>
> Those assumptions seem to be correct. For the most part, your patch
> looks a lot like what I have in my local tree. :) The only thing I did
> different was I overlapped the zero and one tables.
>
> static GLuint radeon_zero_alpha[] =
> {
> RADEON_ALPHA_ARG_A_ZERO,
> RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A,
> RADEON_ALPHA_ARG_A_ZERO
> };
OK, so you add one to op for GL_ONE then?
> > Does this look right? Ian, you mentioned seeing problems with SUBTRACT,
> > and in an older message you were wondering about the difference between
> > how r100 and r200 handle PREVIOUS. Two questions: Did you come to any
> > conclusions on either of those questions? and what are you using to test
> > this? I was thinking of trying to add support to the glean texcombine
> > test, but I wanted to see if you had something already.
>
> WRT GL_PREVIOUS, my conclusion is that the I didn't understand the way
> that r200 texture combiners work. :) It's actually quite different from
> the r100. Based on numerous glean tests, both are correct.
>
> About GL_SUBTRACT on r100, I just don't know. I hacked up the
> ttexcombine test in glean to test GL_MODULATE_*_ATI and GL_SUBTRACT.
> EVERY mode that uses subtraction failed on the r100. Looking at the
> "expected" and "got" output from glean, I could see that it was
> expecting the right thing, but the output was wrong.
>
> > Also, should I go ahead and commit my revised texmem patch?
>
> Yes.
OK, will do. Do you want to commit your patch for combine3 to texmem? I
don't have an R200, so I can't test that, but it looks like it should be
easy to add there too. If SUBTRACT is the only problem, I don't think
that should prevent you committing it, as that's apparently a problem even
without the extension.
Regarding glean, I need to test again, but I was seeing some other
failures even with the mesa-4-0-4 and trunk. I think there were some
off-by-one scissor errors and a couple of others. One question I had was
whether the Radeon driver should really advertise a destination alpha
channel. At depth 24, glxinfo reports 8 bit alpha for color and accum
buffers. This doesn't seem to be consistent across the drivers. Some
don't even seem to be consistent for a given entry between alpha bits,
alpha mask, and buffer size. Here's a little chart I made a while back:
Mach64/R128
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 24 16 16 16 0 24
Radeon/R200
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 ff00 24 16 16 16 16 24
MGA
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 8 32 16 16 16 0 24
GLINT
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 5 5 5 000f1000 16 16 16 16 0 15 (pScrn->depth)
8 8 8 0 32 16 16 16 0 24 (pScrn->depth)
tdfx
r g b a amaskbsz ar ag ab aa Xvisual dpth
5 6 5 0 16 16 16 16 0 16
8 8 8 0 16 16 16 16 0 24 (pScrn->bitsPerPixel)
8 8 8 8 ff00 16 16 16 16 16 32 (pScrn->bitsPerPixel)
--
Leif Delgass
http://www.retinalburn.net
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-devel][patch] radeonAllocDmaRegion called with bytes > dma buffer size
I attached a patch that fixes the problem. It introduces a new TCL_FALLBACK if there are too many vertices to fit into one DMA buffer. Looks kind of hackish to me. Does anyone have a better idea? Comments? Regards, Felix On Wed, 5 Feb 2003 12:04:45 +0100 Felix Kühling <[EMAIL PROTECTED]> wrote: > Hi, > > while I was trying to understand the DMA buffer allocation of the radeon > driver a few months ago I added an assertion at the end of > radeonAllocDmaRegion: > >assert (rmesa->dma.current.ptr <= rmesa->dma.current.end); > > It fails if someone tries to allocate more DMA buffer space than one DMA > buffer size. Now while testing quakeforge after a long time again the > assertion did actually fail. RADEON_DEBUG=ioctl shows that > radeonAllocDmaRegion is called with bytes=72000. IIRC the DMA buffer > size is 65536. Here is a backtrace: > > nq-glx: radeon_ioctl.c:635: radeonAllocDmaRegion: Assertion `rmesa->dma.current.ptr ><= rmesa->dma.current.end' failed. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 1024 (LWP 1016)] > 0x40334581 in kill () from /lib/libc.so.6 > (gdb) bt > #0 0x40334581 in kill () from /lib/libc.so.6 > #1 0x40334394 in raise () from /lib/libc.so.6 > #2 0x403358d1 in abort () from /lib/libc.so.6 > #3 0x4032edb2 in __assert_fail () from /lib/libc.so.6 > #4 0x41654ce7 in radeonAllocDmaRegion () at radeon_ioctl.c:609 > #5 0x41656442 in radeonEmitArrays (ctx=0x8167898, inputs=24) > at radeon_maos_verts.c:305 > #6 0x416788e5 in radeon_run_tcl_render (ctx=0x8167898, stage=0x82e2d38) > at radeon_tcl.c:315 > #7 0x4162f733 in _tnl_run_pipeline (ctx=0x8167898) at t_pipeline.c:154 > #8 0x41661d87 in radeonWrapRunPipeline (ctx=0x8167898) at radeon_state.c:2088 > #9 0x41620115 in _tnl_DrawElements (mode=2823, count=137243856, > type=137243856, indices=0x8318ba8) at t_array_api.c:99 > #10 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) > at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 > #11 0x41680571 in radeon_fallback_DrawElements (mode=0, count=0, type=0, > indices=0x0) at ../../../../../../extras/Mesa/src/vtxfmt_tmp.h:369 > #12 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) > at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 > #13 0x40026f38 in Draw_nString (x=6, y=1078070736, > str=0x4144e780 "_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset", ' ' >, "GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D", >' ' , "GL_EXT_texture_env_add GL_EXT_texture_env_combine ---Type > to continue, or q to quit--- > "..., count=0) at gl_draw.c:367 > #14 0x72676f74 in ?? () > Cannot access memory at address 0x7369685f __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! Index: radeon_tcl.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.c,v retrieving revision 1.5 diff -u -r1.5 radeon_tcl.c --- radeon_tcl.c25 Nov 2002 19:58:29 - 1.5 +++ radeon_tcl.c5 Feb 2003 22:15:18 - @@ -303,6 +303,9 @@ struct vertex_buffer *VB = &tnl->vb; GLuint i,flags = 0,length; + /* reset vb count fallback, is this the right place? */ + TCL_FALLBACK(ctx, RADEON_TCL_FALLBACK_VB_COUNT, GL_FALSE); + /* TODO: separate this from the swtnl pipeline */ if (rmesa->TclFallback) @@ -313,6 +316,10 @@ radeonReleaseArrays( ctx, stage->changed_inputs ); radeonEmitArrays( ctx, stage->inputs ); + /* have to fall back to sw t&l if radeonEmitArrays finds that the vertices +* don't fit into one DMA buffer */ + if (rmesa->TclFallback) + return GL_TRUE; rmesa->tcl.Elts = VB->Elts; @@ -504,7 +511,8 @@ "Texgen unit 0", "Texgen unit 1", "Texgen unit 2", - "User disable" + "User disable", + "Too many vertices" }; Index: radeon_tcl.h === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.h,v retrieving revision 1.2 diff -u -r1.2 radeon_tcl.h --- radeon_tcl.h12 Jun 2002 15:50:26 - 1.2 +++ radeon_tcl.h5 Feb 2003 22:15:18 - @@ -56,6 +56,7 @@ #define RADEON_TCL_FALLBACK_TEXGEN_1 0x20 /* texgen, unit 1 */ #define RADEON_TCL_FALLBACK_TEXGEN_2 0x40 /* texgen, unit 2 */ #define RADEON_TCL_FALLBACK_TCL_DISABLE 0x80 /* user disable */ +#define RADEON_TCL_FALLBACK_VB_COUNT 0x100 /* too many vertices */ #define RADEON_MAX_TCL_VERTSIZE (4*4) /* using maos now... */ Index: radeon_maos_verts.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_maos_verts.c,v retrieving revision 1.5 diff -u -r1.5 radeon_maos_
Re: [Dri-devel] Context teardown
Good advice! It looks like a double free in __driUtilUpdateDrawableInfo when freeing pdp->pClipRects. But at that point not only has pClipRects been freed, so has pdp! This happens (in the original code) with __driGarbageCollectDrawables being called before the driver's DestroyContext and the subsequent lock trying to operate on a drawable that doesn't exist. However, the context still has a copy of the drawable pointer, which now points to freed memory. So it looks like the first patch eliminates the problem in this case. However, I wonder if the driver's DestroyBuffer should set the context's drawable pointer to NULL, since that's called by driDestroyDrawable right before the drawable is freed. The problem there is we'd then need to fix the lock function to handle the case where there is no drawable. --Leif On Wed, 5 Feb 2003, Brian Paul wrote: > Keith Whitwell wrote: > > Leif Delgass wrote: > > > >> On Wed, 5 Feb 2003, Keith Whitwell wrote: > >> > >> > >>> Ian Romanick wrote: > >>> > Keith Whitwell wrote: > > > > The other bug report I've had is triggered in similar > > circumstances, but goes into an infinite loop inside > > DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets > > updated because the X protocol message never succeeds -- but it > > doesn't segfault. > > > > I've got a patch that solves (I hope) that problem, but I'm not > > sure working around this is a good idea as it seems to result from > > maybe a double free somewhere... > > > > Yes. The light-05 test in viewperf shows this bug on r200. If you > want to send me your patch, I can try it out. > >>> > >>> > >>> There are now two patches, one from Egbert Eich (who reported the > >>> problem). I haven't had time to look at his as it changes some deep, > >>> dark, dri stuff that I wasn't ever involved with, but looks sane > >>> nonetheless. His avoids the error reply from the X server, whereas mine > >>> copes with it once it arrives. I'm not sure either will help texobj > >>> which seems to be a malloc/free bug. > >>> > >>> I'm attaching both. I actually think applying *both* is the way to go. > >> > >> > >> > >> The reordering in driDestroyDrawable fixes the X error with texobj for > >> me. I never got a segfault running texobj outside of gdb. I do remember > >> seeing one once while debugging, but I can't recall how I got there and > >> can't reproduce it. Where did you see the malloc problem? > > > > > > The segfault you report is inside malloc, but called from the X error > > handler. As the 2nd patch removes the error, you never get to malloc, > > but my guess is something is still screwy there. However, as you say, > > you only see this in gdb, so I don't know what that means... > > Someone could probably track down the malloc problem pretty quickly with > ElectricFence or with libc's built-in memory debugger. From 'man malloc': > > > Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) > include a malloc implementation which is tunable via environment vari- > ables. When MALLOC_CHECK_ is set, a special (less efficient) implemen- > tation is used which is designed to be tolerant against simple errors, > such as double calls of free() with the same argument, or overruns of a > single byte (off-by-one bugs). Not all such errors can be protected > against, however, and memory leaks can result. If MALLOC_CHECK_ is set > to 0, any detected heap corruption is silently ignored; if set to 1, a > diagnostic is printed on stderr; if set to 2, abort() is called immedi- > ately. This can be useful because otherwise a crash may happen much > later, and the true cause for the problem is then very hard to track > down. > > > -Brian > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
> Ian, now that you've merged in the software support for combine3 from the > Mesa trunk, I'm trying to get it working in hardware on R100 with texmem > (impatient as I am ;) ). Where do I find at least a short explanation on the effect this patch should show to me (to the user) ? The only impression I have after a short test is decreased frame rate in FlightGear under certain conditions. I'm pretty shure this is not your primary intention with this patch ;-) So obviously this patch is considered to improve something else that FlightGear das not benefit from, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffer size
a couple of us QF codes are questioning this, looks like gcc optimizations or gdb are interefering cause the way QF handles the vertex array (with error checking), it's impossable for starters for it send a NULL indices pointer, not to mention a 0 count. > #9 0x41620115 in _tnl_DrawElements (mode=2823, count=137243856, > type=137243856, indices=0x8318ba8) at t_array_api.c:99 > #10 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) > at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 > #11 0x41680571 in radeon_fallback_DrawElements (mode=0, count=0, type=0, > indices=0x0) at ../../../../../../extras/Mesa/src/vtxfmt_tmp.h:369 > #12 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) > at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 > #13 0x40026f38 in Draw_nString (x=6, y=1078070736, > str=0x4144e780 "_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset", ' ' >, "GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D", >' ' , "GL_EXT_texture_env_add GL_EXT_texture_env_combine ---Type > to continue, or q to quit--- > "..., count=0) at gl_draw.c:367 > #14 0x72676f74 in ?? () --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Steven Paul Lilly wrote: Will all this stuff about context teardown fix the problem I'm having with my glut based program that always gives me X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 144 (XFree86-DRI) Minor opcode of failed request: 9 () Value in failed request: 0x101 Serial number of failed request: 73 Current serial number in output stream: 73 when I exit? I'm using X compiled from the dri trunk about a week ago. I don't see this when direct rendering is disabled. Quite possibly -- try applying in particular the second (inline) patch from my earlier post. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R100 GL_ATI_texture_env_combine3
Leif Delgass wrote:
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
the registers. I'm attaching a patch of what I've got. My assumptions
are that RADEON_BLEND_CTL_[ADD,ADDSIGNED,SUBTRACT] will do the
corresponding MODULATE_[ADD,ADDSIGNED,SUBTRACT] with three args. Also,
I'm assuming I can use RADEON_[COLOR,ALPHA]_ARG_A_ZERO or-ed with
_COMP_ARG_A to get GL_ONE.
Those assumptions seem to be correct. For the most part, your patch
looks a lot like what I have in my local tree. :) The only thing I did
different was I overlapped the zero and one tables.
static GLuint radeon_zero_alpha[] =
{
RADEON_ALPHA_ARG_A_ZERO,
RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A,
RADEON_ALPHA_ARG_A_ZERO
};
Does this look right? Ian, you mentioned seeing problems with SUBTRACT,
and in an older message you were wondering about the difference between
how r100 and r200 handle PREVIOUS. Two questions: Did you come to any
conclusions on either of those questions? and what are you using to test
this? I was thinking of trying to add support to the glean texcombine
test, but I wanted to see if you had something already.
WRT GL_PREVIOUS, my conclusion is that the I didn't understand the way
that r200 texture combiners work. :) It's actually quite different from
the r100. Based on numerous glean tests, both are correct.
About GL_SUBTRACT on r100, I just don't know. I hacked up the
ttexcombine test in glean to test GL_MODULATE_*_ATI and GL_SUBTRACT.
EVERY mode that uses subtraction failed on the r100. Looking at the
"expected" and "got" output from glean, I could see that it was
expecting the right thing, but the output was wrong.
Also, should I go ahead and commit my revised texmem patch?
Yes.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeonAllocDmaRegion called with bytes > dma buffer size
> #12 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) > at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 > #13 0x40026f38 in Draw_nString (x=6, y=1078070736, > str=0x4144e780 "_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset", ' ' >, "GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D", >' ' , "GL_EXT_texture_env_add GL_EXT_texture_env_combine ---Type > to continue, or q to quit--- > "..., count=0) at gl_draw.c:367 > #14 0x72676f74 in ?? () if you notice count=0, DRI shouldn't really go any further with a 0 count --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Confusing..?
I just last night downloaded the newest CVS from dri.sourceforge.net.. and tried compiling it.. it went smoothly.. no errors.. *BUT*.. none of the kernel modules were created.. for *any* of the video drivers listed in the host.def file.. Any ideas? -- John S. Chalice
Re: [Dri-devel] Context teardown
Will all this stuff about context teardown fix the problem I'm having with my glut based program that always gives me X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 144 (XFree86-DRI) Minor opcode of failed request: 9 () Value in failed request: 0x101 Serial number of failed request: 73 Current serial number in output stream: 73 when I exit? I'm using X compiled from the dri trunk about a week ago. I don't see this when direct rendering is disabled. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Keith Whitwell wrote: Leif Delgass wrote: On Wed, 5 Feb 2003, Keith Whitwell wrote: Ian Romanick wrote: Keith Whitwell wrote: The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault. I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere... Yes. The light-05 test in viewperf shows this bug on r200. If you want to send me your patch, I can try it out. There are now two patches, one from Egbert Eich (who reported the problem). I haven't had time to look at his as it changes some deep, dark, dri stuff that I wasn't ever involved with, but looks sane nonetheless. His avoids the error reply from the X server, whereas mine copes with it once it arrives. I'm not sure either will help texobj which seems to be a malloc/free bug. I'm attaching both. I actually think applying *both* is the way to go. The reordering in driDestroyDrawable fixes the X error with texobj for me. I never got a segfault running texobj outside of gdb. I do remember seeing one once while debugging, but I can't recall how I got there and can't reproduce it. Where did you see the malloc problem? The segfault you report is inside malloc, but called from the X error handler. As the 2nd patch removes the error, you never get to malloc, but my guess is something is still screwy there. However, as you say, you only see this in gdb, so I don't know what that means... Someone could probably track down the malloc problem pretty quickly with ElectricFence or with libc's built-in memory debugger. From 'man malloc': Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment vari- ables. When MALLOC_CHECK_ is set, a special (less efficient) implemen- tation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immedi- ately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down. -Brian --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Leif Delgass wrote: On Wed, 5 Feb 2003, Keith Whitwell wrote: Ian Romanick wrote: Keith Whitwell wrote: The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault. I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere... Yes. The light-05 test in viewperf shows this bug on r200. If you want to send me your patch, I can try it out. There are now two patches, one from Egbert Eich (who reported the problem). I haven't had time to look at his as it changes some deep, dark, dri stuff that I wasn't ever involved with, but looks sane nonetheless. His avoids the error reply from the X server, whereas mine copes with it once it arrives. I'm not sure either will help texobj which seems to be a malloc/free bug. I'm attaching both. I actually think applying *both* is the way to go. The reordering in driDestroyDrawable fixes the X error with texobj for me. I never got a segfault running texobj outside of gdb. I do remember seeing one once while debugging, but I can't recall how I got there and can't reproduce it. Where did you see the malloc problem? The segfault you report is inside malloc, but called from the X error handler. As the 2nd patch removes the error, you never get to malloc, but my guess is something is still screwy there. However, as you say, you only see this in gdb, so I don't know what that means... Anyway, it sounds like it's worthwhile committing these. Keith --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
On Wed, 5 Feb 2003, Keith Whitwell wrote: > Ian Romanick wrote: > > Keith Whitwell wrote: > > > >> The other bug report I've had is triggered in similar circumstances, > >> but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as > >> a magic stamp value never gets updated because the X protocol message > >> never succeeds -- but it doesn't segfault. > >> > >> I've got a patch that solves (I hope) that problem, but I'm not sure > >> working around this is a good idea as it seems to result from maybe a > >> double free somewhere... > > > > > > Yes. The light-05 test in viewperf shows this bug on r200. If you want > > to send me your patch, I can try it out. > > There are now two patches, one from Egbert Eich (who reported the > problem). I haven't had time to look at his as it changes some deep, > dark, dri stuff that I wasn't ever involved with, but looks sane > nonetheless. His avoids the error reply from the X server, whereas mine > copes with it once it arrives. I'm not sure either will help texobj > which seems to be a malloc/free bug. > > I'm attaching both. I actually think applying *both* is the way to go. The reordering in driDestroyDrawable fixes the X error with texobj for me. I never got a segfault running texobj outside of gdb. I do remember seeing one once while debugging, but I can't recall how I got there and can't reproduce it. Where did you see the malloc problem? --Leif --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003
On Wed, 5 Feb 2003, Ian Romanick wrote: > Adam K Kirchhoff wrote: > > FYI, > > > > With the latest patch to UT2003 (2186), and drivers from the > > texmem branch as of this morning (for a Radeon 8500), ut2003 segfaults: > > > > Backtrace: > > [ 1] ./Core.so [0x409f635a] > > [ 2] /lib/libpthread.so.0 [0x40d7275a] > > [ 3] /lib/libc.so.6 [0x40b9f898] > > [ 4] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e74419] > > [ 5] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e74966] > > [ 6] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e7498a] > > [ 7] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e59521] > > [ 8] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e70614] > > [ 9] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e309e8] > > [10] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e24301] > > [11] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43dbf587] > > [12] > > /usr/local/games/ut2003/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRender > > Interface14EPrimitiveType+0x348) [0x42f49ac0] > > [13] ./Engine.so(Flush__11FCanvasUtil+0x1dc) [0x4035206c] > > [14] ./Engine.so(_._11FCanvasUtil+0x28) [0x40351dac] > > [15] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x97a) > > [0x403434 > > 96] > > [16] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x840) [0x4027b304] > > [17] > > /usr/local/games/ut2003/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) [0 > > x42f0a93b] > > [18] /usr/local/games/ut2003/System/SDLDrv.so(Tick__10USDLClient+0x85) > > [0x42f09 > > 365] > > [19] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0x40282111] > > [20] ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d] > > [21] ./ut2003-bin(main+0x328c) [0x8058b2c] > > [22] /lib/libc.so.6(__libc_start_main+0xdd) [0x40b8e9f1] > > [23] ./ut2003-bin(ValidateCDKey__Fv+0x4d) [0x80512d1] > > Signal: SIGSEGV [segmentation fault] > > > > Prior to this patch, the game would load, levels would load (of course, > > they'd render completely wrong), and my machine would lock up eventually. > > I'm not sure if I should consider this an improvement :-) > > I (finally) have an 8500, but UT2k3 is still on the way. Looking at > this backtrace, I assume that you got this from a core file. Actually, I didn't. UT2003 prints all sorts of nice debugging info when it crashes :-) > Can you run UT2k3 from inside gdb? You'll have to be able to ssh/telnet > into your box. I've been trying to reproduce this problem with other > programs, but I haven't had any luck. I think I can handle that sometime this week. Adam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
> There are now two patches, one from Egbert Eich (who reported the problem). I > haven't had time to look at his as it changes some deep, dark, dri stuff that > I wasn't ever involved with, but looks sane nonetheless. His avoids the error > reply from the X server, whereas mine copes with it once it arrives. I'm not > sure either will help texobj which seems to be a malloc/free bug. > I'm attaching both. I actually think applying *both* is the way to go. I didn't yet understand what this sould buy me with a Radeon7500, but at least I have the impression that these patches don't do any harm to me when running my beloved FlightGear, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R100 GL_ATI_texture_env_combine3
Ian, now that you've merged in the software support for combine3 from the
Mesa trunk, I'm trying to get it working in hardware on R100 with texmem
(impatient as I am ;) ). I don't have Radeon docs, so I'm guessing about
the registers. I'm attaching a patch of what I've got. My assumptions
are that RADEON_BLEND_CTL_[ADD,ADDSIGNED,SUBTRACT] will do the
corresponding MODULATE_[ADD,ADDSIGNED,SUBTRACT] with three args. Also,
I'm assuming I can use RADEON_[COLOR,ALPHA]_ARG_A_ZERO or-ed with
_COMP_ARG_A to get GL_ONE.
Does this look right? Ian, you mentioned seeing problems with SUBTRACT,
and in an older message you were wondering about the difference between
how r100 and r200 handle PREVIOUS. Two questions: Did you come to any
conclusions on either of those questions? and what are you using to test
this? I was thinking of trying to add support to the glean texcombine
test, but I wanted to see if you had something already.
Also, should I go ahead and commit my revised texmem patch?
--
Leif Delgass
http://www.retinalburn.net
Index: radeon_context.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c,v
retrieving revision 1.20.2.7
diff -u -r1.20.2.7 radeon_context.c
--- radeon_context.c5 Dec 2002 15:26:34 - 1.20.2.7
+++ radeon_context.c5 Feb 2003 19:19:51 -
@@ -137,6 +137,7 @@
"GL_EXT_texture_env_dot3",
"GL_EXT_texture_filter_anisotropic",
"GL_EXT_texture_lod_bias",
+"GL_ATI_texture_env_combine3",
"GL_ATI_texture_mirror_once",
"GL_IBM_texture_mirrored_repeat",
"GL_NV_blend_square",
Index: radeon_texstate.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_texstate.c,v
retrieving revision 1.8.2.5
diff -u -r1.8.2.5 radeon_texstate.c
--- radeon_texstate.c 5 Dec 2002 15:26:43 - 1.8.2.5
+++ radeon_texstate.c 5 Feb 2003 19:19:52 -
@@ -119,7 +119,7 @@
t->pp_txfilter |= tx_table[ baseImage->TexFormat->MesaFormat ].filter;
}
else {
- _mesa_problem(NULL, "unexpected texture format in radeonTexImage2D");
+ _mesa_problem(NULL, "unexpected texture format in %s", __FUNCTION__);
return;
}
@@ -198,7 +198,6 @@
assert(t->image[0][i].x == 0
|| (size < BLIT_WIDTH_BYTES && t->image[0][i].height == 1));
#endif
- curOffset += size;
if (0)
fprintf(stderr,
@@ -206,6 +205,9 @@
i, texImage->Width, texImage->Height,
t->image[0][i].x, t->image[0][i].y,
t->image[0][i].width, t->image[0][i].height, size, curOffset);
+
+ curOffset += size;
+
}
/* Align the total size of texture memory block.
@@ -670,6 +672,22 @@
RADEON_COLOR_ARG_A_CURRENT_ALPHA | RADEON_COMP_ARG_A
};
+static GLuint radeon_zero_color[] =
+{
+ RADEON_COLOR_ARG_A_ZERO,
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_COLOR_ARG_A_ZERO,
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A
+};
+
+static GLuint radeon_one_color[] =
+{
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_COLOR_ARG_A_ZERO,
+ RADEON_COLOR_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_COLOR_ARG_A_ZERO
+};
+
/* The alpha tables only have GL_SRC_ALPHA and GL_ONE_MINUS_SRC_ALPHA.
*/
static GLuint radeon_texture_alpha[][RADEON_MAX_TEXTURE_UNITS] =
@@ -704,6 +722,17 @@
RADEON_ALPHA_ARG_A_CURRENT_ALPHA | RADEON_COMP_ARG_A
};
+static GLuint radeon_zero_alpha[] =
+{
+ RADEON_ALPHA_ARG_A_ZERO,
+ RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A
+};
+
+static GLuint radeon_one_alpha[] =
+{
+ RADEON_ALPHA_ARG_A_ZERO | RADEON_COMP_ARG_A,
+ RADEON_ALPHA_ARG_A_ZERO
+};
/* Extract the arg from slot A, shift it into the correct argument slot
* and set the corresponding complement bit.
@@ -900,6 +929,9 @@
numColorArgs = 2;
break;
case GL_INTERPOLATE:
+case GL_MODULATE_ADD_ATI:
+case GL_MODULATE_SIGNED_ADD_ATI:
+case GL_MODULATE_SUBTRACT_ATI:
numColorArgs = 3;
break;
default:
@@ -917,6 +949,9 @@
numAlphaArgs = 2;
break;
case GL_INTERPOLATE:
+case GL_MODULATE_ADD_ATI:
+case GL_MODULATE_SIGNED_ADD_ATI:
+case GL_MODULATE_SUBTRACT_ATI:
numAlphaArgs = 3;
break;
default:
@@ -943,6 +978,12 @@
case GL_PREVIOUS:
color_arg[i] = radeon_previous_color[op];
break;
+ case GL_ZERO:
+ color_arg[i] = radeon_zero_color[op];
+ break;
+ case GL_ONE:
+ color_arg[i] = radeon_one_color[op];
+ break;
default:
return GL_FALSE;
}
@@ -965,6 +1006,12 @@
Re: [Dri-devel] Context teardown
Keith Whitwell wrote: Ian Romanick wrote: Keith Whitwell wrote: The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault. I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere... Yes. The light-05 test in viewperf shows this bug on r200. If you want to send me your patch, I can try it out. There are now two patches, one from Egbert Eich (who reported the problem). I haven't had time to look at his as it changes some deep, dark, dri stuff that I wasn't ever involved with, but looks sane nonetheless. His avoids the error reply from the X server, whereas mine copes with it once it arrives. I'm not sure either will help texobj which seems to be a malloc/free bug. I'm attaching both. I actually think applying *both* is the way to go. Both those patches look reasonable. Even better, they make the light-05 problems go away. :) ugs-01 still tanks, but that seems to be related to the displaylist memory usage bug mentioned earlier. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Ian Romanick wrote:
Keith Whitwell wrote:
The other bug report I've had is triggered in similar circumstances,
but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as
a magic stamp value never gets updated because the X protocol message
never succeeds -- but it doesn't segfault.
I've got a patch that solves (I hope) that problem, but I'm not sure
working around this is a good idea as it seems to result from maybe a
double free somewhere...
Yes. The light-05 test in viewperf shows this bug on r200. If you want
to send me your patch, I can try it out.
There are now two patches, one from Egbert Eich (who reported the problem). I
haven't had time to look at his as it changes some deep, dark, dri stuff that
I wasn't ever involved with, but looks sane nonetheless. His avoids the error
reply from the X server, whereas mine copes with it once it arrives. I'm not
sure either will help texobj which seems to be a malloc/free bug.
I'm attaching both. I actually think applying *both* is the way to go.
Keith
--- dri_util.c 2002/11/25 14:26:55 1.1.1.3
+++ dri_util.c 2003/02/05 10:17:40
@@ -758,8 +762,8 @@
psp->fullscreen = NULL;
}
}
- __driGarbageCollectDrawables(pcp->driScreenPriv->drawHash);
(*pcp->driScreenPriv->DriverAPI.DestroyContext)(pcp);
+ __driGarbageCollectDrawables(pcp->driScreenPriv->drawHash);
(void)XF86DRIDestroyContext(dpy, scrn, pcp->contextID);
Xfree(pcp);
}
Warning: Remote host denied X11 forwarding.
Index: dri_util.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/dri/dri_util.c,v
retrieving revision 1.6
diff -u -r1.6 dri_util.c
--- dri_util.c 28 Nov 2002 19:16:45 - 1.6
+++ dri_util.c 4 Feb 2003 23:06:41 -
@@ -618,16 +618,20 @@
&pdp->numBackClipRects,
&pdp->pBackClipRects
)) {
+ /* Error -- eg the window may have been destroyed. Keep going
+* with no cliprects.
+*/
+pdp->pStamp = &pdp->lastStamp; /* prevent endless loop */
pdp->numClipRects = 0;
pdp->pClipRects = NULL;
pdp->numBackClipRects = 0;
pdp->pBackClipRects = 0;
- /* ERROR!!! */
}
+else
+ pdp->pStamp = &(psp->pSAREA->drawableTable[pdp->index].stamp);
DRM_SPINLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
-pdp->pStamp = &(psp->pSAREA->drawableTable[pdp->index].stamp);
}
/*/
Re: [Dri-devel] Context teardown
Keith Whitwell wrote: The other bug report I've had is triggered in similar circumstances, but goes into an infinite loop inside DRI_VALIDATE_DRAWABLE_INFO(), as a magic stamp value never gets updated because the X protocol message never succeeds -- but it doesn't segfault. I've got a patch that solves (I hope) that problem, but I'm not sure working around this is a good idea as it seems to result from maybe a double free somewhere... Yes. The light-05 test in viewperf shows this bug on r200. If you want to send me your patch, I can try it out. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] UT2003
Adam K Kirchhoff wrote: FYI, With the latest patch to UT2003 (2186), and drivers from the texmem branch as of this morning (for a Radeon 8500), ut2003 segfaults: Backtrace: [ 1] ./Core.so [0x409f635a] [ 2] /lib/libpthread.so.0 [0x40d7275a] [ 3] /lib/libc.so.6 [0x40b9f898] [ 4] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e74419] [ 5] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e74966] [ 6] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e7498a] [ 7] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e59521] [ 8] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e70614] [ 9] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e309e8] [10] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43e24301] [11] /usr/X11R6/lib/modules/dri/r200_dri.so [0x43dbf587] [12] /usr/local/games/ut2003/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRender Interface14EPrimitiveType+0x348) [0x42f49ac0] [13] ./Engine.so(Flush__11FCanvasUtil+0x1dc) [0x4035206c] [14] ./Engine.so(_._11FCanvasUtil+0x28) [0x40351dac] [15] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x97a) [0x403434 96] [16] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x840) [0x4027b304] [17] /usr/local/games/ut2003/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) [0 x42f0a93b] [18] /usr/local/games/ut2003/System/SDLDrv.so(Tick__10USDLClient+0x85) [0x42f09 365] [19] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0x40282111] [20] ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d] [21] ./ut2003-bin(main+0x328c) [0x8058b2c] [22] /lib/libc.so.6(__libc_start_main+0xdd) [0x40b8e9f1] [23] ./ut2003-bin(ValidateCDKey__Fv+0x4d) [0x80512d1] Signal: SIGSEGV [segmentation fault] Prior to this patch, the game would load, levels would load (of course, they'd render completely wrong), and my machine would lock up eventually. I'm not sure if I should consider this an improvement :-) I (finally) have an 8500, but UT2k3 is still on the way. Looking at this backtrace, I assume that you got this from a core file. Can you run UT2k3 from inside gdb? You'll have to be able to ssh/telnet into your box. I've been trying to reproduce this problem with other programs, but I haven't had any luck. Has anyone else seen this problem? --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 driver on Compaq Armada M300
On Mit, 2003-02-05 at 17:50, Albert Cohen wrote: > (II) ATI(0): [drm] drmSetBusid failed (7, PCI:0:5:0), Permission denied > (EE) ATI(0): [dri] DRIScreenInit Failed This has been discussed several times here: you need to make sure the DRM is built with the same compiler as the kernel. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 driver on Compaq Armada M300
First of all, congratulations for the new drivers for ATI Mach64 and for the support of more and more video cards, even older ones... Still, I could not successfully use DRM and 3D acceleration on my AGP-disabled 4MB Mach64 card, using the Debian-package xserver-xfree86-dri-mach64. Even in the 16bit 640*480 and 16bit 800*600 modes, the only ones that fit in the cards tiny memory, I got the following PCI setbus error : (II) ATI(0): [drm] SAREA 2200+1208: 3408 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmGetBusid returned '' (II) ATI(0): [drm] drmSetBusid failed (7, PCI:0:5:0), Permission denied (EE) ATI(0): [dri] DRIScreenInit Failed I don't know enough about PCI to conclude... but I hope there is a cure! Here is an extract of my PCI bus info (Compaq Armada M300): 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03) 00:04.0 CardBus bridge: Texas Instruments PCI1211 00:05.0 VGA compatible controller: ATI Technologies Inc 3D Rage LT Pro (rev dc) 00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Thanks for your help. Sincerely, Albert Cohen -- Albert Cohenhttp://www-rocq.inria.fr/~acohen INRIA Rocquencourt, BP 105, 78153 Le Chesnay, France --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeonAllocDmaRegion called with bytes > dma buffer size
Hi, while I was trying to understand the DMA buffer allocation of the radeon driver a few months ago I added an assertion at the end of radeonAllocDmaRegion: assert (rmesa->dma.current.ptr <= rmesa->dma.current.end); It fails if someone tries to allocate more DMA buffer space than one DMA buffer size. Now while testing quakeforge after a long time again the assertion did actually fail. RADEON_DEBUG=ioctl shows that radeonAllocDmaRegion is called with bytes=72000. IIRC the DMA buffer size is 65536. Here is a backtrace: nq-glx: radeon_ioctl.c:635: radeonAllocDmaRegion: Assertion `rmesa->dma.current.ptr <= rmesa->dma.current.end' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1024 (LWP 1016)] 0x40334581 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40334581 in kill () from /lib/libc.so.6 #1 0x40334394 in raise () from /lib/libc.so.6 #2 0x403358d1 in abort () from /lib/libc.so.6 #3 0x4032edb2 in __assert_fail () from /lib/libc.so.6 #4 0x41654ce7 in radeonAllocDmaRegion () at radeon_ioctl.c:609 #5 0x41656442 in radeonEmitArrays (ctx=0x8167898, inputs=24) at radeon_maos_verts.c:305 #6 0x416788e5 in radeon_run_tcl_render (ctx=0x8167898, stage=0x82e2d38) at radeon_tcl.c:315 #7 0x4162f733 in _tnl_run_pipeline (ctx=0x8167898) at t_pipeline.c:154 #8 0x41661d87 in radeonWrapRunPipeline (ctx=0x8167898) at radeon_state.c:2088 #9 0x41620115 in _tnl_DrawElements (mode=2823, count=137243856, type=137243856, indices=0x8318ba8) at t_array_api.c:99 #10 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #11 0x41680571 in radeon_fallback_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #12 0x415bb936 in neutral_DrawElements (mode=0, count=0, type=0, indices=0x0) at ../../../../extras/Mesa/src/vtxfmt_tmp.h:369 #13 0x40026f38 in Draw_nString (x=6, y=1078070736, str=0x4144e780 "_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset", ' ' , "GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_texture3D", ' ' , "GL_EXT_texture_env_add GL_EXT_texture_env_combine ---Type to continue, or q to quit--- "..., count=0) at gl_draw.c:367 #14 0x72676f74 in ?? () Cannot access memory at address 0x7369685f Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
