Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
fixing this :) Anyway, you should not expect 2D + 3D acceleration too soon. OK. At least - thanks for explanation. problems right now (especially on the mach64 branch :). :)) I see. It makes sense. I solved both the resolution and 2d acceleration problems for me by having two X servers installed, one with 2d acceleration and high resolution and one with 3d acceleration and low resolution. When I want to test DRI I start the 3d server as display :1 on vt8. I don't even have to exit my 2D session for that. :) Well, but current binary snapshots do not allow me to do this, don't they? I would love to be able to do this too. It is a bit annoying to restart X session each time I want to play... Regards, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. I really don't know but... Well, it works now (snapshot 0502). No OOPS detected. In my syslog I see: May 2 20:31:23 localhost kernel: [drm] Creating pci pool May 2 20:31:23 localhost kernel: [drm] Allocating descriptor table memory May 2 20:31:23 localhost kernel: [drm] descriptor table: cpu addr: 0xc08a4000, bus addr: 0x008a4000 May 2 20:31:23 localhost kernel: [drm] Starting DMA test... May 2 20:31:23 localhost kernel: [drm] starting DMA transfer... May 2 20:31:23 localhost kernel: [drm] waiting for idle... May 2 20:31:23 localhost kernel: [drm] waiting for idle...done May 2 20:31:23 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode Does it mean DMA works for me? AFAIK it does. BTW, does synchronous mean there will be asynchronous somewhere?:) About FPS - they are still lower than in good old user-mode MMIO... (241 vs 286 in 0-0-3). But DMA is already enabled - does this mean I will never get anything better? Well, glxgears works OK. So does Counter-Strike. As usual, in texture-intensive apps (celestia) we are waiting for GART... Anyway, thanks for fast fix. Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
On 2 May 2002, Sergey V. Udaltsov wrote: Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. I really don't know but... Well, it works now (snapshot 0502). No OOPS detected. In my syslog I see: May 2 20:31:23 localhost kernel: [drm] Creating pci pool May 2 20:31:23 localhost kernel: [drm] Allocating descriptor table memory May 2 20:31:23 localhost kernel: [drm] descriptor table: cpu addr: 0xc08a4000, bus addr: 0x008a4000 May 2 20:31:23 localhost kernel: [drm] Starting DMA test... May 2 20:31:23 localhost kernel: [drm] starting DMA transfer... May 2 20:31:23 localhost kernel: [drm] waiting for idle... May 2 20:31:23 localhost kernel: [drm] waiting for idle...done May 2 20:31:23 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode Does it mean DMA works for me? AFAIK it does. BTW, does synchronous mean there will be asynchronous somewhere?:) Yes, that's the goal. Synchronous DMA means that we wait for the card to idle after submitting each DMA pass, rather than going on to do other things and polling or handling interrupts to check for completion of the DMA transfer. Synchronous operation isn't meant to be fast, it's just a first step in testing that we are submitting the DMA pass correctly. About FPS - they are still lower than in good old user-mode MMIO... (241 vs 286 in 0-0-3). But DMA is already enabled - does this mean I will never get anything better? see above. Well, glxgears works OK. So does Counter-Strike. As usual, in texture-intensive apps (celestia) we are waiting for GART... We'll get there eventually. ;) I don't think AGP textures will be too hard to add once we get there. We're already allocating a region of the AGP aperture for textures, but the implementation of using it isn't done yet. Anyway, thanks for fast fix. Sure. Let us know if you experience a lockup again. There will be some big changes coming in the drm in 0-0-4 soon, so it's likely to be a bit unstable for a while. -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Yes, that's the goal. Synchronous DMA means that we wait for the card to idle after submitting each DMA pass, rather than going on to do other things and polling or handling interrupts to check for completion of the DMA transfer. Synchronous operation isn't meant to be fast, it's just a first step in testing that we are submitting the DMA pass correctly. That's exactly what I thought. Good, I am not that dumb... Probably eventually I'll grow smart enough to join the team:) Any estimations on speedup we'll get in glxgears? Sure. Let us know if you experience a lockup again. There will be some big changes coming in the drm in 0-0-4 soon, so it's likely to be a bit unstable for a while. COOL. My laptop is eager to be crashed by new snapshots. Just announce GART or asynchronous DMA - and it is yours. BTW, it was mentioned it was easy to enable 2D acceleration back. Is it true? Can it be done in snapshots (by checking this illustrious pATI-directRenderingEnabled). So people could use snapshot drivers in everyday life - without restarting X... Also, just one question - if I set in XF86Config Modes 1280x1024 800x600 - could I have DRI enabled in 800x600 (switching by Alt+Gr-) - though I don't have enough video RAM for 1280x1024? Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
On 02 May 2002 23:19:10 +0100 Sergey V. Udaltsov [EMAIL PROTECTED] wrote: BTW, it was mentioned it was easy to enable 2D acceleration back. Is it true? Can it be done in snapshots (by checking this illustrious pATI-directRenderingEnabled). So people could use snapshot drivers in everyday life - without restarting X... I started looking into this about two weeks ago and I got stuck at the vt and mode switching. It seems that there are locks in the right places (compared to other drivers) but it doesn't work anyway. It seems to be related to textures in some way but I havn't had time to look at how textures are handled by the driver. Maybe José or Leif will be faster at fixing this :) Anyway, you should not expect 2D + 3D acceleration too soon. Also, just one question - if I set in XF86Config Modes 1280x1024 800x600 - could I have DRI enabled in 800x600 (switching by Alt+Gr-) - though I don't have enough video RAM for 1280x1024? I guess not, at least not too soon either. Currently all the DRI stuff is allocated on X server startup. This concerns all DRI drivers so far. One thing that was discussed recently is to allocate depth and stencil and whatever buffers dynamically for each OpenGL client window. But it would require some work to change this and people are busy with other problems right now (especially on the mach64 branch :). I solved both the resolution and 2d acceleration problems for me by having two X servers installed, one with 2d acceleration and high resolution and one with 3d acceleration and low resolution. When I want to test DRI I start the 3d server as display :1 on vt8. I don't even have to exit my 2D session for that. Cheers, Sergey Cheers, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Do you use some framebuffer device? To the best of my knowledge - no. You can start to give us the last lines of /var/log/messages, as I think that there should be a kernel oops in there. The XFree86.log may be interesting too. YESS! There is OOPS. See attached. Cheers, Sergey May 1 20:50:56 localhost kernel: [drm] Creating pci pool May 1 20:50:56 localhost kernel: [drm] Allocating descriptor table memory May 1 20:50:56 localhost kernel: [drm] descriptor table: cpu addr: 0xc0318000, bus addr: 0x00318000 May 1 20:50:56 localhost kernel: [drm] Starting DMA test... May 1 20:50:56 localhost kernel: [drm] starting DMA transfer... May 1 20:50:56 localhost kernel: [drm] waiting for idle... May 1 20:50:56 localhost kernel: [drm] waiting for idle...done May 1 20:50:56 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode May 1 20:51:02 localhost kernel: [drm] freeing descriptor table from pci pool May 1 20:51:02 localhost kernel: Unable to handle kernel paging request at virtual address 5a5a5a5a May 1 20:51:02 localhost kernel: printing eip: May 1 20:51:02 localhost kernel: c01aec39 May 1 20:51:02 localhost kernel: *pde = May 1 20:51:02 localhost kernel: Oops: May 1 20:51:02 localhost kernel: CPU:0 May 1 20:51:02 localhost kernel: EIP:0010:[pool_find_page+25/128]Not tainted May 1 20:51:02 localhost kernel: EIP:0010:[c01aec39]Not tainted May 1 20:51:02 localhost kernel: EFLAGS: 00013096 May 1 20:51:02 localhost kernel: EIP is at pool_find_page [kernel] 0x19 May 1 20:51:02 localhost kernel: eax: 5a5a5a5a ebx: 5a5a5a5a ecx: 5a5a5a5a edx: d0c48000 May 1 20:51:02 localhost kernel: esi: 5a5a5a5a edi: 5a5a5a5a ebp: 5a5a5a5a esp: d0b23e84 May 1 20:51:02 localhost kernel: ds: 0018 es: 0018 ss: 0018 May 1 20:51:02 localhost kernel: Process X (pid: 1383, stackpage=d0b23000) May 1 20:51:02 localhost kernel: Stack: c0321a84 0001 3296 5a5a5a5a 5a5a5a5a 5a5a5a5a cde3d000 c01aecbf May 1 20:51:02 localhost kernel:5a5a5a5a 5a5a5a5a 5a5a5a5a 0001 d0bd8bcc cde3d000 d0b23f48 cde3d000 May 1 20:51:02 localhost kernel:d2987cb6 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a d298d720 006c 0002 May 1 20:51:02 localhost kernel: Call Trace: [pci_pool_free+31/240] pci_pool_free [kernel] 0x1f May 1 20:51:02 localhost kernel: Call Trace: [c01aecbf] pci_pool_free [kernel] 0x1f May 1 20:51:02 localhost kernel: [mach64:mach64_do_cleanup_dma+154/196] mach64_do_cleanup_dma [mach64] 0x9a May 1 20:51:02 localhost kernel: [d2987cb6] mach64_do_cleanup_dma [mach64] 0x9a May 1 20:51:02 localhost kernel: [mach64:__insmod_mach64_S.rodata_L304+17424/26288] __insmod_mach64_S.rodata_L304 [mach64] 0x4410 May 1 20:51:02 localhost kernel: [d298d720] __insmod_mach64_S.rodata_L304 [mach64] 0x4410 May 1 20:51:02 localhost kernel: [mach64:mach64_dma_init+173/196] mach64_dma_init [mach64] 0xad May 1 20:51:02 localhost kernel: [d2987d8d] mach64_dma_init [mach64] 0xad May 1 20:51:02 localhost kernel: [mach64:mach64_ioctl+239/256] mach64_ioctl [mach64] 0xef May 1 20:51:02 localhost kernel: [d2982d97] mach64_ioctl [mach64] 0xef May 1 20:51:02 localhost kernel: [sys_ioctl+535/560] sys_ioctl [kernel] 0x217 May 1 20:51:02 localhost kernel: [c0143907] sys_ioctl [kernel] 0x217 May 1 20:51:02 localhost kernel: [system_call+51/56] system_call [kernel] 0x33 May 1 20:51:02 localhost kernel: [c0106ecb] system_call [kernel] 0x33 May 1 20:51:02 localhost kernel: May 1 20:51:02 localhost kernel: May 1 20:51:02 localhost kernel: Code: 8b 00 8b 54 24 20 eb 39 8b 04 24 89 c2 89 44 24 04 8b 72 10
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
On 1 May 2002, Sergey V. Udaltsov wrote: Hi Do you use some framebuffer device? To the best of my knowledge - no. You can start to give us the last lines of /var/log/messages, as I think that there should be a kernel oops in there. The XFree86.log may be interesting too. YESS! There is OOPS. See attached. Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. Cheers, Sergey -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. OK, thanks. So it will be a part of today's build, won't it? I will take and test it tomorrow... Report will follow... Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How much video memory isneeded?
From this moment the mach64 binary snapshots in http://dri.sourceforge.net/snapshots/bleeding-edge/ are taken from the 0-0-4 branch. Thanks. Just tried. Well, it seems 0-0-4 has long way to go:) First, I just run install.sh and restarted X. I got segmentation fault on glxinfo - after displaying most (or all?) of the info in xterm. Then glxgears just did not want to start - some drmMach64Clean... (sorry, I forget to write it down) returned -22. What could this be? Well, then I wanted to stop X and switched to vconsole 1 - and the whole display froze (but not the whole system!) - so I managed to reboot correctly. After this point, I managed to run X and even run glxgears and glxinfo without problems (though glxgears gives 268fps vs 286 in 0-0-3 - anyway, better than 191 in Mesa). Anyway, X is still unable to shut down gracefully - at killall X in xterm I get frozen screen (though Ctl-Alt-Del works as if I were in console). In XFree86.0.log DRM is reported on (glxinfo has same idea). Well, later I will play more... BTW, is there any way to check whether DMA is on or off? Can I see it in /proc/dma? Thanks for your efforts, Lazy tester Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
It seems that the mach64 kernel moduled wasn't replaced from memory, causing a kernel oops. Usually you need to run install.sh without X running (I usually do init 3). Well, at least with 0-0-3 I managed to do in without stopping X. Just install.sh and restarting X was enough. OK, if you tell 0-0-4 _requires_ me to stop X before installing... There shouldn't be much difference since DMA is off. (DMA at this time even slows things more) I am aware of it. So I do not expect too much:) better than 191 in Mesa). Anyway, X is still unable to shut down gracefully - at killall X in xterm I get frozen screen (though Ctl-Alt-Del works as if I were in console). mmm.. I don't see what it could be. Is there any way I can help do find the reason? As said, there could be some problems with the install.sh not replacing everything properly. That's the more likely. Again, how can I debug this? No. There isn't any yet. But we can arrange to something be printed on the system log when the DMA is enabled on runtime. That would be nice. Also, Leif offered to turn DMA on if bus mastering is detected. Is it possible to do it in today/tommorow snapshots? Just to test... Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How much video memory is needed?
On 2002.04.30 10:54 Sergey V. Udaltsov wrote:
It seems that the mach64 kernel moduled wasn't replaced from memory,
causing a kernel oops. Usually you need to run install.sh without X
running (I usually do init 3).
Well, at least with 0-0-3 I managed to do in without stopping X. Just
install.sh and restarting X was enough. OK, if you tell 0-0-4
_requires_ me to stop X before installing...
In the previous 0-0-3 branch we almost never messed with the DRM, so it
was binary compatible between all snapshots. Now is exactly the opposite.
Nevertheless you shouldn't need to stop X if you're running your distro X.
You need only if you are running X from a mach64 branch, because in this
situation the kernel module is being used and the install.sh script will
surely fail to remove it from memory.
There shouldn't be much difference since DMA is off. (DMA at this time
even slows things more)
I am aware of it. So I do not expect too much:)
better than 191 in Mesa). Anyway, X is still unable to shut down
gracefully - at killall X in xterm I get frozen screen (though
Ctl-Alt-Del works as if I were in console).
mmm.. I don't see what it could be.
Is there any way I can help do find the reason?
As said, there could be some problems with the install.sh not replacing
everything properly. That's the more likely.
Again, how can I debug this?
Please check that the mach64.o in the kernel, the mach64_dri.so and the
ati_{drv,misc}.o files in your system were indeed updated by install.sh
script. (They path should popup if you run locate with their name).
The reason is that I've changed the dripkg/install scripts sometime, and I
didn't receive any feedback (positive or negative) so something could be
going wrong and it's best to be sure of that before looking for other
explanations - especially since no one who built directly from CVS
experienced that so far.
No. There isn't any yet. But we can arrange to something be printed
on
the system log when the DMA is enabled on runtime.
That would be nice. Also, Leif offered to turn DMA on if bus mastering
is detected. Is it possible to do it in today/tommorow snapshots? Just
to test...
Putting the check will take a little more than that (I have a paper
submission deadline in 1 June and I'm barely starting to do the research I
proposed to do in that paper, so I'm a great deal of pressure to get
results ASAP), but I can put the DMA by default so that the interested
ones can try. In the worst case, they can always use the
mach64-0-0-3-branch.
PS: Don't remove the working mach64-0-0-3 snapshot that you may have, as
they will eventually get deleted from the DRI website.
Cheers,
Sergey
José Fonseca
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
In the previous 0-0-3 branch we almost never messed with the DRM, so it
was binary compatible between all snapshots. Now is exactly the opposite.
Nevertheless you shouldn't need to stop X if you're running your distro X.
You need only if you are running X from a mach64 branch, because in this
situation the kernel module is being used and the install.sh script will
surely fail to remove it from memory.
I run ATI.2 drivers from GATOS. AFAIK this should not cause problems,
should it?
Please check that the mach64.o in the kernel, the mach64_dri.so and the
ati_{drv,misc}.o files in your system were indeed updated by install.sh
script. (They path should popup if you run locate with their name).
OK. I will do and report.
Putting the check will take a little more than that (I have a paper
submission deadline in 1 June and I'm barely starting to do the research I
proposed to do in that paper, so I'm a great deal of pressure to get
Best luck with this.
results ASAP), but I can put the DMA by default so that the interested
ones can try. In the worst case, they can always use the
mach64-0-0-3-branch.
For me it's OK. I'm just afraid I'm not the only tester in town:)
PS: Don't remove the working mach64-0-0-3 snapshot that you may have, as
they will eventually get deleted from the DRI website.
Thanks for warning. BTW, probably it would make sense to move them to
separate directory - so people would know where to look more-less
stable:) drivers... Also, even after purging, the latest 0-0-3
snapshot would be nice to leave on FTP. Just in case... 1.5M is not very
large volume...
Cheers,
Sergey
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
On Tue, 30 Apr 2002, José Fonseca wrote: On 2002.04.30 10:54 Sergey V. Udaltsov wrote: No. There isn't any yet. But we can arrange to something be printed on the system log when the DMA is enabled on runtime. That would be nice. Also, Leif offered to turn DMA on if bus mastering is detected. Is it possible to do it in today/tommorow snapshots? Just to test... Putting the check will take a little more than that (I have a paper submission deadline in 1 June and I'm barely starting to do the research I proposed to do in that paper, so I'm a great deal of pressure to get results ASAP), but I can put the DMA by default so that the interested ones can try. In the worst case, they can always use the mach64-0-0-3-branch. I'll work on this, it should be fairly simple to do. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots Was: How muchvideo memory is needed?
Hi I cleaned up all modules and run 0-0-4 from clean state - still same lockup on X termination. Actully, I get the lockup not in termination but in attempts to switch to any textual console.:( The reason is that I've changed the dripkg/install scripts sometime, and I Could you please give me a tip - which lines exactly you changed last days... Regards, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
On 2002.04.30 22:33 Sergey V. Udaltsov wrote: Hi I cleaned up all modules and run 0-0-4 from clean state - still same lockup on X termination. Actully, I get the lockup not in termination but in attempts to switch to any textual console.:( Do you use some framebuffer device? The reason is that I've changed the dripkg/install scripts sometime, and I Could you please give me a tip - which lines exactly you changed last days... There were almost none in the install actually, but quite a few in dripkg, but if you removed all the mentioned files and the installation script ran fine without complains then that's most likely not the problem. The GATOS ati.2 doesn't seem to be either since the driver has the same name and would be overwritten. In 4 hrs a new snapshot should appear (with DMA enabled too). Please try it again. If nothing changes, then we'll need to make some heavy debugging, as with the PowerPC ;-) You can start to give us the last lines of /var/log/messages, as I think that there should be a kernel oops in there. The XFree86.log may be interesting too. Regards, Sergey José Fonseca
