[Dri-devel] why so many contexts?
If I'm reading the drm source right, there seems to be either 32,000 or 64,000 contexts provided for, with the ctxbitmap routines. Isnt that overkill for typical use? Wont the average user tend to have MAYBE 5 or 10 active contexts at a time, and no more than that? --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] drm_write_string: debug, or neccessary?
I note that the apparent sole purpose for drm_write_string() is to record context switches in a buffer, which can be read by processes doing userland read() calls on the drm dev. Is this for debug purposes only? --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa 4.1 branch
[...] hmm, that's odd. I still get floating point exceptions for almost every GL-app. with TCL disabled. Demos that _do_ work with TCL disabled include: clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos Maybe this can give you a clue, why some are working and some aren't? Could I have messed something up during checking out/compiling/installing that is causing these FPE's? Can you run with gdb and find where the FP exception is happening? Well, first I gotta admit that I don't have any experience in debugging, so this log might be completely useless. If that's the case, I'd appreciate if anyone can give me a quick howto in basic debugging. harkpabst [../MESA-CVS/Mesa/demos] $ export R200_NO_TCL=1 harkpabst [../MESA-CVS/Mesa/demos] $ gdb ./gears GNU gdb 2002-08-18-cvs Copyright 2002 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-linux...(no debugging symbols found)... (gdb) run Starting program: /mnt/hdc1/benutzer/src/dri/MESA-CVS/Mesa/demos/gears [New Thread 1024 (LWP 27531)] Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1024 (LWP 27531)] 0x406452df in _mesa_test_os_sse_exception_support () from /usr/X11R6-DRI/lib/modules/dri/r200_dri.so (gdb) c Continuing. disabling TCL support Program received signal SIGFPE, Arithmetic exception. 0x4064872a in _mesa_sse_transform_points3_general () from /usr/X11R6-DRI/lib/modules/dri/r200_dri.so (gdb) bt #0 0x4064872a in _mesa_sse_transform_points3_general () from /usr/X11R6-DRI/lib/modules/dri/r200_dri.so #1 0x08055e10 in ?? () #2 0x40644e01 in init_vertex_stage (ctx=0x805ba68, stage=0x81da6cc) at t_vb_vertex.c:286 #3 0x4060b704 in _tnl_run_pipeline (ctx=0x805ba68) at t_pipeline.c:155 #4 0x40653ddc in r200WrapRunPipeline (ctx=0x805ba68) at r200_state.c:2088 #5 0x40608eb5 in _tnl_run_cassette (ctx=0x805ba68, IM=0x81e14a0) at t_imm_exec.c:400 #6 0x405fe5f4 in execute_compiled_cassette (ctx=0x805ba68, data=0x81f372c) at t_imm_dlist.c:377 #7 0x404cd6a0 in execute_list (ctx=0x805ba68, list=1) at dlist.c:4218 #8 0x404d0556 in _mesa_CallList (list=1) at dlist.c:5095 #9 0x4055ac4a in neutral_CallList (i=1) at /mnt/hdc1/benutzer/src/dri/MESA-CVS/Mesa/src/vtxfmt_tmp.h:339 #10 0x0804cad7 in draw () #11 0x40030d55 in processWindowWorkList (window=0x64) at glut_event.c:1297 #12 0x4019a0bf in __libc_start_main () from /lib/libc.so.6 (gdb) quit A debugging session is active. Do you still want to close the debugger?(y or n) y harkpabst [../MESA-CVS/Mesa/demos] $ Do you require backtraces from more different demos? One other thing that might be worth noting: Starting quake3.x86 from text console within gdb (switch to vt with C-M-F1, export DISPLAY=:0, gdb ./quake3.x86, run, c) does work with TCL disabled, for some reason. I attached some info about my system (cpuinfo, compiler-version etc.) Stefan -Brian sysinfo.bz2 Description: Binary data
Re: [Dri-devel] why so many contexts?
Am Mittwoch, 16. Oktober 2002 10:05 schrieb Keith Whitwell: Philip Brown wrote: If I'm reading the drm source right, there seems to be either 32,000 or 64,000 contexts provided for, with the ctxbitmap routines. Isnt that overkill for typical use? Wont the average user tend to have MAYBE 5 or 10 active contexts at a time, and no more than that? Yes, but it's not hard to create more. I don't see the benefit in limiting it to the current typical usage. That said, when I try create many contexts, something fails around nr 32, and I get indirect rendering from then on. I haven't looked into why. r200 at exactly 29 (#0-27 are OK). Next change in behavior between #37 and #38 (see below). But I got some (whole) system lock ups (live locks). VTK and medical 3D apps (VIS) easily reach 5-10 (more). -Dieter ./manywin 31 Name: 27 Display: 0x93fd080 Window: 0x6a2 Context: 0x93ffd90 GL_VERSION: 1.2 Mesa 4.0.4 GL_VENDOR: Tungsten Graphics, Inc. GL_RENDERER: Mesa DRI R200 20020827 AGP 4x x86/MMX/3DNow!/SSE TCL libGL error: drmMap of framebuffer failed 800, 200 Name: 28 Display: 0x9541450 Window: 0x6c2 Context: 0x958 GL_VERSION: 1.3 Mesa 4.0.4 GL_VENDOR: Mesa project: www.mesa3d.org GL_RENDERER: Mesa GLX Indirect libGL error: drmMap of framebuffer failed 900, 200 Name: 29 Display: 0x9585278 Window: 0x6e2 Context: 0x9587a30 GL_VERSION: 1.3 Mesa 4.0.4 GL_VENDOR: Mesa project: www.mesa3d.org GL_RENDERER: Mesa GLX Indirect libGL error: drmMap of framebuffer failed 0, 300 Name: 30 Display: 0x95c7f50 Window: 0x702 Context: 0x95ca708 GL_VERSION: 1.3 Mesa 4.0.4 GL_VENDOR: Mesa project: www.mesa3d.org GL_RENDERER: Mesa GLX Indirect Hit ESC 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: 0x82 Serial number of failed request: 41 Current serial number in output stream: 41 ./manywin 37 [-] libGL error: drmMap of framebuffer failed 600, 300 Name: 36 Display: 0x9758c60 Window: 0x7e2 Context: 0x975b418 GL_VERSION: 1.3 Mesa 4.0.4 GL_VENDOR: Mesa project: www.mesa3d.org GL_RENDERER: Mesa GLX Indirect 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: 0x302 Serial number of failed request: 41 Current serial number in output stream: 41 ./manywin 38 libGL error: drmMap of framebuffer failed 700, 300 Name: 37 Display: 0x979b938 Window: 0x802 Context: 0x979e0f0 GL_VERSION: 1.3 Mesa 4.0.4 GL_VENDOR: Mesa project: www.mesa3d.org GL_RENDERER: Mesa GLX Indirect Speicherschutzverletzung ./manywin 100 ;-) libGL error: drmMap of framebuffer failed 900, 900 Name: 99 Display: 0xa7c97e0 Window: 0xfe2 Context: 0xa7cbf98 GL_VERSION: 1.3 Mesa 4.0.4 GL_VENDOR: Mesa project: www.mesa3d.org GL_RENDERER: Mesa GLX Indirect Speicherschutzverletzung --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm_write_string: debug, or neccessary?
Philip Brown wrote: I note that the apparent sole purpose for drm_write_string() is to record context switches in a buffer, which can be read by processes doing userland read() calls on the drm dev. Is this for debug purposes only? Probably. I didn't know it was there... Keith --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] mach64 DMA on PPC
On Wed, 16 Oct 2002, Colin Leroy wrote: Hi, ok, I made a few more tests about why dma doesn't work on ppc. I made mmio-mode dump ring info in mach64_ring_idle when everything was fine, and compared with the mach64_do_wait_for_idle failing in dma mode. I found some differences in the logs, some seem logical, some are hard to understand why (for me at least ;-)) Here's a few info: mmio: BUS_CNTL = 0x7b2fa150 dma: 0x7b2fa110 Here, bit 6 means disable bus mastering, so this is normal. It's set for mmio but not dma. mmio: BM_FRAME_BUF_OFFSET = 0x007ff980 dma: 0x007ffe48 BM_FRAME_BUF_OFFSET is only used with bus mastering. The value is always 0x007ff800 (the offset of the register map in the framebuffer) plus the register address. So for dma here the register address is 0x648, which is BM_DATA. That means the last dma transfer was a gui-master where the dma buffer is filled with alternating register offsets and data. Other values you'll see are 0x007ffe44 (BM_HOSTDATA), which indicates a texture blit, and 0x007ff980 (BM_FRAME_BUF_OFFSET), which means the card is transferring a DMA descriptor in preperation for a gui-master or blit. mmio: GUI_STAT = 0x0080 dma: 0x00800201 (the one making the problem visible) Here, bit 0 means the engine is busy, and bits 23:16 indicate the number of free FIFO slots. In the case of mmio, the register shows all slots open and the engine is idle. In the case of dma here, all slots are open but the engine is busy, when this state doesn't change and bit 0 remains high, it indicates a lockup. Bits 11:8 indicate that the draw destination is outside of the current scissor, in this case DSTX is right of the right scissor. I'm not sure if the scissor is really the problem here, this could also indicate corrupt vertex data. There are several different possible causes of a lockup. mmio: head_addr: 0x08550290 head: 164 tail: 164 (head_addr always 0x855, head and tail vary) dma: head_addr: 0x07988ae0 head: 696 tail: 700 (head_addr always 0x789, head and tail vary) The range of head_addr will vary from one server generation to the next, since the descriptor ring placement will depend on available memory, but the size is always 16kB. The head_addr should always be between the ring bus address reported by the drm at startup and the start address + 16K. The head and tail are constantly changing as descriptors are added to the ring at the tail and the card consumes them from the head, moving along and wrapping at the end of the ring. Here, since in the mmio case the card is idle, the head and tail are equal. In the dma case, the card locked-up on the last descriptor in the ring (each descriptor is 4 dwords and the head and tail shown are dword offsets). Note that mmio is implemented by generating dma descriptors as with the dma path, and then manually processing the descriptor ring and feeding the data from the dma buffers one register at a time. So the ring and buffer data should be the same with mmio and dma for a given series of GL operations, except for the descriptor and buffer addresses which will vary depending on the placement in memory of the ring and buffers. Well :) Hope it could be of some use! I don't see anything unusual here -- except the lockup, of course. Determining the root cause of the lockup is the difficult part. Have you found any Mesa demos that don't lock up with either sync or async dma? -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] PCIGART Radeon AIW support
Hi. I'm using an All-In-Wonder Radeon card, and its the PCI version (not AGP). I complied the drm radeon.o module, and I editting the radeon_cp.c file to say #define PCIGART (presumably to try using the PCI GART). If I just insmod radeon.o and not agpgart.o, then I get: (II) RADEON(0): [drm] created radeon driver at busid PCI:0:9:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf088d000 (II) RADEON(0): [drm] mapped SAREA 0xf088d000 to 0x40014000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (EE) RADEON(0): [agp] AGP not available (EE) RADEON(0): [drm] failed to remove DRM signal handler (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf088d000 at 0x40014000 and glxinfo uses Mesa Indirect. I tried to insmod both agpgart.o and radeon.o, then startx. Then, all I see is a bunch of green lines whipping by on the screen. I'm pretty sure its not a resolution/sync problem. The computer still runs, but I only see the green lines. CTRL-ALT-BKSPC doesn't return to the console properly. The xfree86.0.log looks ok: (II) RADEON(0): [drm] created radeon driver at busid PCI:0:9:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf08a3000 (II) RADEON(0): [drm] mapped SAREA 0xf08a3000 to 0x40014000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x1106/0x0305; Card 0x1002/0x5144] (II) RADEON(0): [agp] 8192 kB allocated with handle 0xf28a7000 (II) RADEON(0): [agp] ring handle = 0xe600 (II) RADEON(0): [agp] Ring mapped at 0x42207000 (II) RADEON(0): [agp] ring read ptr handle = 0xe6101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x40016000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe6102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x42308000 (II) RADEON(0): [agp] AGP texture map handle = 0xe6302000 (II) RADEON(0): [agp] AGP Texture map mapped at 0x42508000 (II) RADEON(0): [drm] register handle = 0xdf00 (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): Largest offscreen area available: 1024 x 7423 (II) RADEON(0): Will use back buffer at offset 0x90 (II) RADEON(0): Will use depth buffer at offset 0xc0 (II) RADEON(0): Will use 17408 kb for textures at offset 0xf0 (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled Fatal server error: Caught signal 11. Server aborting (presumably the ctrl-alt-backspace causes the sig11) the only warnings I get are further up: (--) RADEON(0): Chipset: ATI Radeon QD (AGP) (ChipID = 0x5144) (--) RADEON(0): Linear framebuffer at 0xe000 (--) RADEON(0): MMIO registers at 0xdf00 (--) RADEON(0): BIOS at 0x000c (WW) System lacks support for changing MTRRs and something to do with xaa: (II) Loading sub module xaa (II) LoadModule: xaa (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (WW) module minor version (0) is less than the required minor version (1) (II) UnloadModule: xaa (II) Unloading /usr/X11R6/lib/modules/libxaa.a (II) Loading sub module xaa (II) LoadModule: xaa (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 Is there anything else I need to do to get the PCI GART working? Any ideas would be appreciated. Thanks very much. -James --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] celestia and multitexture
anyhow i found that it still crashs when one goes to saturn or any other ringed planet, from searching the forums on celestia i found that it seems to be due to multitexture problems in dri or mesa BTW, I can confirm. Even with old (gcc296) binaries I have the same problem with Saturn and others... Sergey --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] PCIGART Radeon AIW support
On Mit, 2002-10-16 at 23:14, James Fung wrote: I'm using an All-In-Wonder Radeon card, and its the PCI version (not AGP). I complied the drm radeon.o module, and I editting the radeon_cp.c file to say #define PCIGART (presumably to try using the PCI GART). You need to do the same in programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c . Let us know if it works. -- 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: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Backing store on Radeon?
On Wed, Oct 16, 2002 at 01:07:16AM +0200, Michel Dänzer wrote: On Die, 2002-10-15 at 20:30, Ian Romanick wrote: Warning: ignorant questions on the way... I've gotten some questions from a couple of people about backing store with DRI, on the R100 driver specifically. Because my background isn't firmly rooted in X-Windows, I wasn't really familiar with what that meant. :) I did a little searching, and I think I have a vauge idea now. In any case, as near as I can tell, when the Radeon DRI driver gets loaded, backing store is explicitly disabled. Why is that? Is it a hardware limitation or is it just to conserve memory? Something else? I was going to guess something like 'because there can't be backing store for direct rendered windows?', but are you actually sure about this? I just started a server with DRI enabled and +bs, and both the log and xdpyinfo indicated that backing store was enabled. If you have more questions about backing store, you should probably post to Xpert. So, I did a little tinkering on this, I have a tiny script called x_twm that looks like: #!/bin/sh X $* xterm exec twm If I run it as 'x_twm -depth 24', everything is fine. However, if I do 'x_twm -depth 24 +bs', it *says* that backing store is enabled. If I left click to bring up the menu, it is blank until I move the mouse pointer over each menu entry. *Something* isn't right. This also happens when I comment out dri and glx from the Module section, so it doesn't seem specific to DRI. Ideas? Is this a (previously) known issue? -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
