[Dri-devel] Getting started on DRI hacking...
Hi. What do I need to do to get started on DRI hacking? I want to track down a bug in radeon_dri.so how do I build it? what sources do I need? ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 DMA, blits, AGP textures
OK, I finally committed my changes thus far as a checkpoint. I'm reading BM_GUI_TABLE in the dispatch routine to see when we hit the hardware pointer and wait once we reach it. So the dispatch is treating the descriptor table as a ring, and it helps. There's still lots of places to optimize and probably a fair amount of cruft and bugs lurking, but I wanted to get this into cvs while things are working. :) One of the main problems is context switches with the X server. Right now I have a wait for idle followed by saving the pattern registers (used for buffer aging) in EnterServer (atidri.c). I'm only restoring the registers if the X server changes them, but the engine must be idle before they can be stored. We really need to figure out how to do this better, because things slow down whenever you move the mouse now. This might be a good time to look into getting sync working with 2D accel as well, since we'll need to verify that the solution will work with XAA. AGP texturing is working, but the algorithm needs work. The trick is that for multitexturing, both textures need to be in either card local or AGP memory. I can go into more detail about these changes at Monday's meeting, but I'll be away for a couple of days and I wanted to get this checked in and post a quick message for now... -- Leif Delgass http://www.retinalburn.net ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRIVER info needed. [updated list]
Well, here is the updated list... anyone feel free to fill in features for the hardware they know... cmon, this is at worst 5 mins work for someone who knows a given card... 3D features --- Anti Aliasing Fullscreen Line / edge Glyph (text) Max Accelerated colourdepth / res Filtering Bilinear Trilinear Anisotropic TCL Triangle setup engine Key frame interpolation 4 matrix vertex skinning Shaders Vertex Pixel Texture handling Texture compositing Texture compression Video textures Perspective correct texturing Texture morphing Texture units available / used by DRI Displacement mapping Special effects / highlights Specular highlights Bump mapping Emboss, dot product and env. bump-mapping Spherical, dual-paraboloid and cubic env. mapping Fog effects Texture lighting Reflections Shadows Spotlights 2D features --- Video overlay de-interlacing iDCT accelleration Double buffering Triple buffering Hardware pageflip DMA frame transfer Misc things --- KTX buffer region extension Guard band clipping Gamma control Dual monitor support TV out support 3D glasses support ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Getting started on DRI hacking...
On 2002.05.18 10:41 Ian Molton wrote: Hi. What do I need to do to get started on DRI hacking? I want to track down a bug in radeon_dri.so how do I build it? what sources do I need? Ian, First thing you need is to download the cvs tree and build it. You can follow the instructions on http://dri.sourceforge.net/doc/DRIcompile.html. If you don't want to override your distro's XFree, then follow instead Leif's instructions on http://www.retinalburn.net/linux/dri_HOWTO.html replacing mach64-?-?-?-branch for the branch you're interested (either HEAD or tcl-0-0-branch). All this process can be quite tricky on the first time you make it, so make sure that you have you new Xfree running properly before you start playing with it. After, go to the radeon Mesa driver sources (see http://dri.sourceforge.net/doc/faq/architecture.html#ED-DRIVER-WHERE) and start debugging them, either by putting debug output statements, or running gdb on it, like: gdb glxgears run (there is always a breakpoint here due to the SSE detection - it's best the time to add breakpoints in radeon_dri.so) break nauthy-function-in-radeon-dri-so continue (it should popup) list step step next print foo ... if your app segfaults then when you run it with gdb it will breakpoint there. You don't need to recompile the whole X when you change parts of it. Just do make, (if you mess with header is better to do make clean first because the dependencies may be wrong) and then su -c make install When you got so far come to us again giving more details about the bug you're keen, and we'll give hints of places to look and answer any doubt you may have. José Fonseca ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRIVER info needed. [mach64 draft]
Ok, This is a draft for mach64. Please fell free to correct. What I'm not sure is marked with ?. On 2002.05.18 10:44 Ian Molton wrote: Well, here is the updated list... anyone feel free to fill in features for the hardware they know... cmon, this is at worst 5 mins work for someone who knows a given card... 3D features --- Anti Aliasing Fullscreen N/S Line / edge U Glyph (text)N/S Max Accelerated colourdepth / res 24 bpp / limited by card memory (you need basicaly 3x the screen size of memory as almost every other DRI driver) Filtering BilinearA Trilinear A/S ? Anisotropic ? TCL Triangle setup engine A (This shouldn't be here, should it?) Key frame interpolation N 4 matrix vertex skinningN Shaders Vertex N Pixel N Texture handling Texture compositing A (not all modes are supported by the hardware) Texture compression U (Not implemented) Video textures ? Perspective correct texturing A Texture morphing? Texture units available / used by DRI 2/2 Displacement mappingN Special effects / highlights Specular highlights A Bump mappingN Emboss, dot product and env. bump-mapping N Spherical, dual-paraboloid and cubic env. mapping N Fog effects A/U (card drivers can't handle fog and alpha blending at the same time) Texture lightingA ? Reflections N Shadows N Spotlights N 2D features --- Video overlay No * de-interlacing? * iDCT accelleration? * Double buffering Yes Triple buffering No Hardware pageflip No (yet) DMA frame transferNo * Misc things --- KTX buffer region extension ? Guard band clipping ? Gamma control ? Dual monitor support ? (If X supports, it's not with 3d) TV out supportNo * 3D glasses supportNo * Only when we merge with GATOS (A)ccelerated (U)naccelerated (N)ot available on that hardware (S)oftware rendered due to being unavailable on that hardware. José Fonseca ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Mach64 DMA, blits, AGP textures
On 2002.05.18 10:33 Leif Delgass wrote: OK, I finally committed my changes thus far as a checkpoint. I'm reading BM_GUI_TABLE in the dispatch routine to see when we hit the hardware pointer and wait once we reach it. So the dispatch is treating the descriptor table as a ring, and it helps. There's still lots of places to optimize and probably a fair amount of cruft and bugs lurking, but I wanted to get this into cvs while things are working. :) Great! I've fired the scripts to make a mach64 snapshot so a new one should appear within the next hour or so. One of the main problems is context switches with the X server. Right now I have a wait for idle followed by saving the pattern registers (used for buffer aging) in EnterServer (atidri.c). I'm only restoring the registers if the X server changes them, but the engine must be idle before they can be stored. We really need to figure out how to do this better, because things slow down whenever you move the mouse now. This might be a good time to look into getting sync working with 2D accel as well, since we'll need to verify that the solution will work with XAA. Agreed. AGP texturing is working, but the algorithm needs work. The trick is that for multitexturing, both textures need to be in either card local or AGP memory. I can go into more detail about these changes at Monday's meeting, but I'll be away for a couple of days and I wanted to get this checked in and post a quick message for now... I'm getting completely depressed because my work is giving me quite some headaches and I'm eagger to play with mach64 but I can't since the deadline is closing down... Regards, José Fonseca ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Getting started on DRI hacking...
On Sat, 18 May 2002 11:08:22 +0100 José Fonseca [EMAIL PROTECTED] wrote: On 2002.05.18 10:41 Ian Molton wrote: Hi. What do I need to do to get started on DRI hacking? I want to track down a bug in radeon_dri.so how do I build it? what sources do I need? Ian, First thing you need is to download the cvs tree and build it. You can I downloaded it and am trying to build it following the instructions you gave, but ran into this: make[3]: Entering directory `/usr/src/cvs/dri/build/xc/lib/xtrans' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* make[3]: Leaving directory `/usr/src/cvs/dri/build/xc/lib/xtrans' cleaning in lib/Xau... make[3]: Entering directory `/usr/src/cvs/dri/build/xc/lib/Xau' make[3]: *** No rule to make target `clean'. Stop. make[3]: Leaving directory `/usr/src/cvs/dri/build/xc/lib/Xau' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/usr/src/cvs/dri/build/xc/lib' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/usr/src/cvs/dri/build/xc' make: *** [World] Error 2 ian:/usr/src/cvs/dri/build/xc$ What is xtrans? All this process can be quite tricky on the first time you make it, so make sure that you have you new Xfree running properly before you start playing with it. is the DRI CVS all I need? or was I supposed to add it to a full X4.2 source? ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri feature lists IMPORTANT :-)
On Fri, May 17, 2002 at 09:23:18PM +0200, Arpi wrote: use dma to transfer frames to video ram, or memcpy? Do you know what drivers use DMA for this? Vedran Rodic ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Getting started on DRI hacking...
On 2002.05.18 13:31 Ian Molton wrote: On Sat, 18 May 2002 12:40:51 +0100 José Fonseca [EMAIL PROTECTED] wrote: First thing you need is to download the cvs tree and build it. You can I downloaded it and am trying to build it following the instructions you gave, but ran into this: Please tell which branch are you using, and if you changed the ProjectRoot in the host.def file or not. whatever the default is, I guess. I did this: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co xc here is my host.def: #define Options -Wall #define DefaultGcc2i386Opt -O2 #define LibraryCDebugFlags -O2 #define BuildServersOnly YES #define XF86CardDrivers vga radeon #define LinuxDistribution LinuxRedHat #define DefaultCCOptions -ansi GccWarningOptions -pipe #define BuildXF86DRI YES /* Optionally turn these on for debugging */ /* #define GlxBuiltInTdfx YES */ /* #define GlxBuiltInMga YES */ /* #define GlxBuiltInR128 YES */ /* #define GlxBuiltInRadeon YES */ /* #define DoLoadableServer NO */ #define SharedLibFont NO #define ProjectRoot /usr/src/X11test #define MesaUse3DNow YES You can't simply replace /xc/config/cf/host.def file that comes from the CVS. It's better if you just edit it and do not change below where it says Don't change anything below or the build will fail ;-) If you want to define ProjectRoot to /usr/src/X11test don't forget to lndir from /usr/X11R6 to /usr/src/X11test. This is just trying to clean everything. Attempt to do make World again and see if it gets over it. Already tried that. it didnt. You just need the DRI CVS and a working XFRee = 4.1.x installed on the system as the DRI source is partial and reads some headers from there. If you changed ProjectRoot to another thing (e.g., /usr/X11R6-DRI) then before you start to compile you need to do: mkdir -p /usr/X11R6-DRI cd /usr/X11R6-DRI lndir ../X11R6 so that when building the needed files are found in the right place. I'll give that a try. thanks. José Fonseca ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RADEON specs
On 2002.05.18 13:38 Keith Whitwell wrote: Ian Molton wrote: Hi I'd like copies of the Radeon specs, please? ATI say they have given them to the DRI project, and I was told to get my copy here. Some of us have specs, but I don't think we've ever received a license to distribute them... Given how protective they are about this stuff, I'd hesitate before doing so... Ian, this is what ATI tells to people when they request the specs and don't mention that its for the DRI project. They don't relly mean that you can get a copy from the others DRI developers, just that you can refer to them for that. Reply to ATI, stress that you're trying to help in the DRI development, that you're radeon owner and that you particularly want to help in debugging and bugfixing. Also give some background about yourself so that they fill confident in releasing the specs to you, and perhaps you succeed. If you already read the NDA section on the FAQ you know that this is quite often complicated. Be patient. The specs aren't that useful in the beginning (some are just a bunch of tables whose contents is already on the DRI tree as a C header). Understanding the radeon driver code will give much more understanding than the specs do. (And you'll get the specs sooner or later anyway). José Fonseca ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA, blits, AGP textures
On 2002.05.18 15:40 Felix Kühling wrote: On Sat, 18 May 2002 15:01:51 +0200 Felix Kühling [EMAIL PROTECTED] wrote: For this test I compiled everything with gcc-2.95.4. I had a different problem after compiling with gcc-3.0. I have to try that again and check for compile errors. The problem was that the X server segfaulted on startup. I'll report more details later. Ok, I recompiled with gcc-3.0 again. There are no errors in world.log. The X-server segfaults on startup. Note that I had a working Xserver+DRI compiled with gcc-3.0 before Leif's last changes. These are the relevant parts of my logfiles: kern.log: [...] May 18 16:18:28 viking kernel: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xd000 64MB May 18 16:18:28 viking kernel: [drm] Initialized mach64 1.0.0 20020417 on minor 0 May 18 16:18:29 viking kernel: [drm] Setting FIFO size to 128 entries May 18 16:18:29 viking kernel: [drm] Creating pci pool May 18 16:18:29 viking kernel: [drm] Allocating descriptor table memory May 18 16:18:29 viking kernel: [drm] descriptor table: cpu addr: 0xc0268000, bus addr: 0x00268000 May 18 16:18:29 viking kernel: [drm] Starting DMA test... May 18 16:18:29 viking kernel: [drm] starting DMA transfer... May 18 16:18:29 viking kernel: [drm] waiting for idle... May 18 16:18:29 viking kernel: [drm] waiting for idle...done May 18 16:18:29 viking kernel: [drm] DMA test succeeded, using asynchronous DMA mode XFree86.1.log: [...] (==) ATI(0): Write-combining range (0xd400,0x80) (II) ATI(0): [drm] SAREA 2200+1212: 3412 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 11, (OK) drmGetBusid returned '' (II) ATI(0): [drm] loaded kernel module for mach64 driver (II) ATI(0): [drm] created mach64 driver at busid PCI:1:0:0 (II) ATI(0): [drm] added 8192 byte SAREA at 0xd08bf000 (II) ATI(0): [drm] mapped SAREA 0xd08bf000 to 0x40015000 (II) ATI(0): [drm] framebuffer handle = 0xd400 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [agp] Using AGP 1x Mode (II) ATI(0): [agp] Using 8 MB AGP aperture (II) ATI(0): [agp] Mode 0x1f000201 [AGP 0x1106/0x0305; Card 0x1002/0x474d] (II) ATI(0): [agp] 8192 kB allocated with handle 0xd10c3000 (II) ATI(0): [agp] Using 2 MB DMA buffer size (II) ATI(0): [agp] vertex buffers handle = 0xd000 (II) ATI(0): [agp] Vertex buffers mapped at 0x40a38000 (II) ATI(0): [agp] AGP texture region handle = 0xd020 (II) ATI(0): [agp] AGP Texture region mapped at 0x40c38000 (II) ATI(0): [drm] register handle = 0xd600 (II) ATI(0): [dri] Visual configs initialized (II) ATI(0): [dri] Block 0 base at 0xd6000400 (II) ATI(0): Memory manager initialized to (0,0) (640,1637) (II) ATI(0): Reserved back buffer from (0,480) to (640,960) (II) ATI(0): Reserved depth buffer from (0,960) to (640,1440) (II) ATI(0): Reserved 6144 kb for textures at offset 0x1ff900 (II) ATI(0): Largest offscreen areas (with overlaps): (II) ATI(0): 640 x 6072 rectangle at 0,480 (II) ATI(0): 512 x 6073 rectangle at 0,480 (**) ATI(0): Option XaaNoScreenToScreenCopy (II) ATI(0): Using XFree86 Acceleration Architecture (XAA) Setting up tile and stipple cache: 32 128x128 slots 18 256x256 slots 7 512x512 slots (==) ATI(0): Backing store disabled (==) ATI(0): Silken mouse enabled (**) Option dpms (**) ATI(0): DPMS enabled (II) ATI(0): X context handle = 0x0001 (II) ATI(0): [drm] installed DRM signal handler (II) ATI(0): [DRI] installation complete (II) ATI(0): [drm] Added 128 16384 byte DMA buffers Fatal server error: Caught signal 11. Server aborting I also got a debugger backtrace after the segfault: Program received signal SIGSEGV, Segmentation fault. 0x086c0c3c in ?? () #0 0x086c0c3c in ?? () #1 0x086bef1b in ?? () #2 0x080bfe18 in AddScreen (pfnInit=0x86be944, argc=5, argv=0xba04) at main.c:768 #3 0x0806c425 in InitOutput (pScreenInfo=0x81cda00, argc=5, argv=0xba04) at xf86Init.c:819 #4 0x080bf378 in main (argc=5, argv=0xba04, envp=0xba1c) at main.c:380 I know, this backtrace is not very helpful. Is there a way to get the ?? resolved? Regards, Felix Nice report ;-) Try with xfree-gdb (http://www.dawa.demon.co.uk/xfree-gdb/) to see if you have better luck. José Fonseca ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED]
Re: [Dri-devel] Mach64 DMA, blits, AGP textures
On Sat, 18 May 2002 11:30:28 -0400 (EDT) Leif Delgass [EMAIL PROTECTED] wrote: Did you have a 2D accelerated server running on another vt? The DDX saves and restores its register state on mode switches, so it could be a problem with the FIFO depth or pattern registers being changed. Try testing without another X server running if you haven't already. Also, does anything show up in the system log? I did have a 2D accelerated X-server running. But I started the DRI server from a text console and didn't switch between the servers during the tests, so it shouldn't matter. As to the syslog, my kern.log file is actually the syslog. My distro configures syslog so that it sends all syslog messages from the kernel to kern.log. In the other syslog files there are no further messages. Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] How to see Radeon 'sync' problems
On Sat, May 18, 2002 at 02:57:24AM +0200, Vedran Rodic wrote: I think I found a cause for a problem described at http://marc.theaimsgroup.com/?l=dri-develm=101843821602258w=2 If I run a X11 application that updates the screen periodicaly (clock from KDE kicker, gkrellm), I'll see this problem happen. When I'm not running the apps, the problem will go away. Yes, I see it. In fact I see it even though (a) my kicker panel autohides so that in principle nothing on screen is updated (b) the app I ran runs fullscreen. Basically running billiard-gl and just watching the intro table rotating and there's a noticable pause every second, switching the clock to 'fuzzy' so it just said 'weekend!' and the pool table at the beginning smoothly rotates around. -- Michael. ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA, blits, AGP textures
On Sat, 18 May 2002 15:56:00 +0100
José Fonseca [EMAIL PROTECTED] wrote:
Nice report ;-)
Thanks :)
Try with xfree-gdb (http://www.dawa.demon.co.uk/xfree-gdb/) to see if you
have better luck.
Yep, that gave better results. Since I have only one computer here and
the display turns black I had to do this with a gdb command script. This
is the script:
run :1 vt8 -xf86config XF86Config-mach64004
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
continue
bt
Here is the log:
Program received signal SIGUSR1, User defined signal 1.
_loader_debug_state () at loader.c:1331
1331{
#0 _loader_debug_state () at loader.c:1331
#1 0x0809c71a in ARCHIVELoadModule (modrec=0x831cbd0, arfd=8,
ppLookup=0xb848) at loader.c:1036
#2 0x0809cd56 in LoaderOpen (
module=0x833eb28 /usr/X11R6-mach64004/lib/modules/extensions/libxie.a,
cname=0x8276b68 xie, handle=0, errmaj=0xb8d4, errmin=0xb8d8,
wasLoaded=0xb898) at loader.c:1183
#3 0x0809e739 in LoadModule (module=0x8276b08 xie, path=0x0,
subdirlist=0x0, patternlist=0x0, options=0x0, modreq=0x0,
errmaj=0xb8d4, errmin=0xb8d8) at loadmod.c:924
#4 0x0806e630 in xf86LoadModules (list=0x820f760, optlist=0x820f790)
at xf86Init.c:1716
#5 0x0806c5f7 in InitOutput (pScreenInfo=0x81e09e0, argc=5, argv=0xba04)
at xf86Init.c:358
#6 0x080c55e6 in main (argc=5, argv=0xba04, envp=0xba1c) at main.c:380
#7 0x4006e14f in __libc_start_main () from /lib/libc.so.6
Program received signal SIGUSR1, User defined signal 1.
_loader_debug_state () at loader.c:1331
1331{
#0 _loader_debug_state () at loader.c:1331
#1 0x0809c71a in ARCHIVELoadModule (modrec=0x831cbd0, arfd=8,
ppLookup=0xb848) at loader.c:1036
#2 0x0809cd56 in LoaderOpen (
module=0x833eb28 /usr/X11R6-mach64004/lib/modules/extensions/libxie.a,
cname=0x8276b68 xie, handle=0, errmaj=0xb8d4, errmin=0xb8d8,
wasLoaded=0xb898) at loader.c:1183
#3 0x0809e739 in LoadModule (module=0x8276b08 xie, path=0x0,
subdirlist=0x0, patternlist=0x0, options=0x0, modreq=0x0,
errmaj=0xb8d4, errmin=0xb8d8) at loadmod.c:924
#4 0x0806e630 in xf86LoadModules (list=0x820f760, optlist=0x820f790)
at xf86Init.c:1716
#5 0x0806c5f7 in InitOutput (pScreenInfo=0x81e09e0, argc=5, argv=0xba04)
at xf86Init.c:358
#6 0x080c55e6 in main (argc=5, argv=0xba04, envp=0xba1c) at main.c:380
#7 0x4006e14f in __libc_start_main () from /lib/libc.so.6
Program received signal SIGUSR1, User defined signal 1.
_loader_debug_state () at loader.c:1331
1331{
#0 _loader_debug_state () at loader.c:1331
#1 0x0809c71a in ARCHIVELoadModule (modrec=0x831cbd0, arfd=8,
ppLookup=0xb848) at loader.c:1036
#2 0x0809cd56 in LoaderOpen (
module=0x833eb28 /usr/X11R6-mach64004/lib/modules/extensions/libxie.a,
cname=0x8276b68 xie, handle=0, errmaj=0xb8d4, errmin=0xb8d8,
wasLoaded=0xb898) at loader.c:1183
#3 0x0809e739 in LoadModule (module=0x8276b08 xie, path=0x0,
subdirlist=0x0, patternlist=0x0, options=0x0, modreq=0x0,
errmaj=0xb8d4, errmin=0xb8d8) at loadmod.c:924
#4 0x0806e630 in xf86LoadModules (list=0x820f760, optlist=0x820f790)
at xf86Init.c:1716
#5 0x0806c5f7 in InitOutput (pScreenInfo=0x81e09e0, argc=5, argv=0xba04)
at xf86Init.c:358
#6 0x080c55e6 in main (argc=5, argv=0xba04, envp=0xba1c) at main.c:380
#7 0x4006e14f in __libc_start_main () from /lib/libc.so.6
Program received signal SIGUSR1, User defined signal 1.
_loader_debug_state () at loader.c:1331
1331{
#0 _loader_debug_state () at loader.c:1331
#1 0x0809c71a in ARCHIVELoadModule (modrec=0x831cbd0, arfd=8,
ppLookup=0xb848) at loader.c:1036
#2 0x0809cd56 in LoaderOpen (
module=0x833eb28 /usr/X11R6-mach64004/lib/modules/extensions/libxie.a,
cname=0x8276b68 xie, handle=0, errmaj=0xb8d4, errmin=0xb8d8,
wasLoaded=0xb898) at loader.c:1183
#3 0x0809e739 in LoadModule (module=0x8276b08 xie, path=0x0,
subdirlist=0x0, patternlist=0x0, options=0x0, modreq=0x0,
errmaj=0xb8d4, errmin=0xb8d8) at loadmod.c:924
#4 0x0806e630 in xf86LoadModules (list=0x820f760, optlist=0x820f790)
at xf86Init.c:1716
#5 0x0806c5f7 in InitOutput (pScreenInfo=0x81e09e0, argc=5, argv=0xba04)
at xf86Init.c:358
#6 0x080c55e6 in main (argc=5, argv=0xba04, envp=0xba1c) at main.c:380
#7 0x4006e14f in __libc_start_main () from /lib/libc.so.6
Program received signal SIGUSR1, User defined signal 1.
_loader_debug_state () at loader.c:1331
1331{
#0 _loader_debug_state () at loader.c:1331
#1 0x0809c71a in ARCHIVELoadModule (modrec=0x85d7188, arfd=8,
ppLookup=0xb848) at loader.c:1036
#2 0x0809cd56 in LoaderOpen (
module=0x862ed08 /usr/X11R6-mach64004/lib/modules/fonts/libspeedo.a,
cname=0x8667760 speedo, handle=0,
Re: [Dri-devel] Mach64 DMA, blits, AGP textures
On Sat, 18 May 2002 18:26:52 +0100 José Fonseca [EMAIL PROTECTED] wrote: I also have to start using another X server in a sep window cause having to log out everytime I want to test is a PITA. I'm not sure whether I get this correctly. Anyway, I have my 2D Xserver running on vt7 and start the 3D Xserver from a text console on vt8. bt continue ... Here is the log: ... Program received signal SIGSEGV, Segmentation fault. 0x082385e0 in DRILock (pScreen=0x0, flags=0) at dri.c:1759 1759DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen); #0 0x082385e0 in DRILock (pScreen=0x0, flags=0) at dri.c:1759 The problem is that pScreen is NULL here and DRILock is trying to dereference it. This is the second sigsegv. I found it strange that the debugger could continue after the first one. I assume that this one actually happens while the first one is handled. #1 0x086d9ffe in intE6_handler () #2 0x086ff93d in VBEGetVBEpmi () at atipreinit.c:548 #3 0x08706fa9 in fbBlt (srcLine=0x0, srcStride=0, srcX=0, dstLine=0x8706fa9, dstStride=-1073744732, dstX=0, width=0, height=141643160, alu=1, pm=141643240, bpp=137618992, reverse=0, upsidedown=142025672) at fbblt.c:295 #4 0x080a8ca8 in xf86XVLeaveVT (index=0, flags=0) at xf86xv.c:1241 #5 0x0806d5de in AbortDDX () at xf86Init.c:1135 #6 0x080dbf20 in AbortServer () at utils.c:436 #7 0x080dd62f in FatalError () at utils.c:1399 #8 0x08080d0b in xf86SigHandler (signo=11) at xf86Events.c:1085 See ... #9 0x4007e6b8 in sigaction () from /lib/libc.so.6 #10 0x086ea8d8 in intE6_handler () #11 0x080c60f0 in AddScreen (pfnInit=0x86ea268 intE6_handler+79240, argc=5, argv=0xba04) at main.c:768 #12 0x0806c383 in InitOutput (pScreenInfo=0x81e09e0, argc=5, argv=0xba04) at xf86Init.c:819 #13 0x080c55e6 in main (argc=5, argv=0xba04, envp=0xba1c) at main.c:380 #14 0x4006e14f in __libc_start_main () from /lib/libc.so.6 Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. I grepped for intE6_handler and found it in programs/Xserver/hw/xfree86/int10/xf86int10.c. I think, it's not mach64 specific and it hasn't changed since January. So the actual problem must be somewhere else. Don't forget that the problem ocurred in DRILock and not intE6_handler. The first sigsegv occurred in intE6_handler. First let's try to eliminate the most simple options first. I noticed on the CVS Update log that Leif changed quite a deal of places. You mentioned in your first post that you'd recompiled everything. Did you also re-installed everything? It happened quite a lot having problems because I forgot to recompile/reinstall parts that had been changed. I used make world to recompile everything and make install to install. I also copied the kernel module. Did I forget anything? Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri feature lists IMPORTANT :-)
On Sat, 2002-05-18 at 14:43, Vedran Rodic wrote: On Fri, May 17, 2002 at 09:23:18PM +0200, Arpi wrote: use dma to transfer frames to video ram, or memcpy? Do you know what drivers use DMA for this? Only r128 yet, but it's quite fragile there, and when I played with adding it to the radeon driver, I didn't get it to do anything but lock up yet. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Mach64 DMA, blits, AGP textures
Hi all So, I took the first snapshot with textures - and ready to say something good. Well, DRI now works even in 1280x1024 - great thanks to Leif and others. At least I don't have to modify XF86Config every time... 1. glxinfo - OK, usual report. 2 glxgears does not show me any real difference in the speed (something around 280). Sometimes I see a bad thing: Couldn't alloc placeholder sz 1 ofs 2 Memory heap 0x80723e8: Offset:, Size:0001, U. Offset:0001, Size:00010200, .. End of memory blocks In dmesg: [drm:mach64_dma_dispatch_vertex] *ERROR* mach64_dma_dispatch_vertex: empty placeholder list in DMAADVANCE() 3. celestia _always_ crashes - same type of error messages (same in dmesg). 4. counter-strike runs. Though 1024x768 - does not run:( Hope my error messages will help. Cheers, Sergey ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
