[Dri-devel] Re: ATI Radeon 9200 and DRI
Ok, when I got to that point I was too tired to even see it! I searched around for libexpat.so.1, googled it and could nt find it. So I symlinked it to libexpat.so.0.4.0 and it works. Maybe the symlink wasn't a good idea? At any rate, thanks to you and all the ppl of the dri project for their work __ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Incomplete scene with OpenGL + direct rendering + mga
[I'm not sure this is a problem with DRI itself, but DRI is definitely
involved and a guy in
comp.os.linux.x told me to ask this list - so I'm trying my luck here.]
I have tried to compile and run some simple OpenGL programs. But lots
of them don't display anything or only part of the scene if direct
rendering is enabled.
However, with LIBGL_ALWAYS_INDIRECT=y the scene looks like it should
do - but animation is extremely slow.
My system is a standard SuSE 8.2 installation with XFree86 4.3.0 and
the standard 2.4.20 kernel.
Graphics adapter: Matrox Millenium G550 (only first head configured)
I would have already tried to upgrade some packages if i had known
where the problem is.
A program demonstrating this is the following.
As this is extracted from example source code of the NeHe OpenGL tutorial
(nehe.gamedev.net) there shouldn't be any coding mistakes in.
--- test.c ---
#include GL/glut.h
#include GL/gl.h
#include GL/glu.h
void InitGL(int Width, int Height)
{
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClearDepth(1.0);
glDepthFunc(GL_LESS);
glEnable(GL_DEPTH_TEST);
glShadeModel(GL_SMOOTH);
glViewport(0, 0, Width, Height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0f,(GLfloat)Width/(GLfloat)Height,0.1f,100.0f);
glMatrixMode(GL_MODELVIEW);
}
void DrawGLScene()
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
// Move Left 1.5 Units And Into The Screen 6.0
glTranslatef(-1.5f,0.0f,-6.0f);
// draw a triangle
glColor3f( 1.0f, 1.0f, 1.0f );
glBegin(GL_POLYGON);
glVertex3f( 0.0f, 1.0f, 0.0f);
glVertex3f( 1.0f,-1.0f, 0.0f);
glVertex3f(-1.0f,-1.0f, 0.0f);
glEnd();
// Move Right 3 Units
glTranslatef(3.0f,0.0f,0.0f);
// draw another triangle
glColor3f( 1.0f, 0.0f, 0.0f );
glBegin(GL_POLYGON);
glVertex3f( 0.0f, 1.0f, 0.0f);
glVertex3f( 1.0f,-1.0f, 0.0f);
glVertex3f(-1.0f,-1.0f, 0.0f);
glEnd();
glutSwapBuffers();
}
int main(int argc, char **argv)
{
glutInit(argc, argv);
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_DEPTH);
glutInitWindowSize(640, 480);
glutInitWindowPosition(0, 0);
glutCreateWindow(Window Title);
glutDisplayFunc(DrawGLScene);
glutFullScreen();
glutIdleFunc(DrawGLScene);
InitGL(640, 480);
glutMainLoop();
return 0;
}
-
I compile with
$ gcc -o test test.c -lglut -lGLU -lGL
If I run it with
$ ./test
I see one white triangle on the left side of the screen.
If I run with
$ LIBGL_ALWAYS_INDIRECT=y ./test
I see a white triangle on the left side and a red triangle on the
right side.
There aren't any error messages neither in XFree86.0.log nor on the
xterm when running the program - even with MESA_DEBUG=y.
Same result if the OpenGL window is created with GLX or SDL.
'Real', i.e. more complex OpenGL programs like bzflag run without
problems.
Another example demonstrating the problem is the cube example
program that comes with the glut library: With direct rendering
enabled it does only display a black window.
--- Output of glxinfo -
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: VA Linux Systems Inc.
OpenGL renderer string: Mesa DRI G400 20020221 AGP 1x x86/MMX/SSE
OpenGL version string: 1.2 Mesa 4.0.4
OpenGL extensions:
GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_texture_compression,
GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_abgr,
GL_EXT_bgra, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array,
GL_EXT_packed_pixels, GL_EXT_polygon_offset,
GL_EXT_rescale_normal,
GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object,
GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos,
GL_NV_texgen_reflection, GL_SGIS_generate_mipmap
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
--
0x23 24 tc 1 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None
0x24 24 tc 1 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None
0x25 24 tc 1 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None
0x26 24 tc 1 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None
0x27 24 tc 1 24 0 r y . 8 8 8 0 0 0 0 16
libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
Ian Romanick wrote: Michel Dnzer wrote: On Mon, 2003-11-24 at 20:01, en ne wrote: I send you the verbose output and the ldd output. libexpat.so.1 = not found This is getting old. This makes at least 10 reports of direct rendering not working that turned out to be libexpat.so problems. Are we or are we not staticly linking with libexpat for the nightly builds? I seriously thought that this was resolved weeks ago. If we're not going to link it statically, can we please use dlopen() and dlsym() to get the expat functionality, and if it's not available, do nothing? Keith --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Incomplete scene with OpenGL + direct rendering + mga
On Tue, Nov 25, 2003 at 10:40:27AM +0100, Jan Gukelberger wrote: I have tried to compile and run some simple OpenGL programs. But lots of them don't display anything or only part of the scene if direct rendering is enabled. However, with LIBGL_ALWAYS_INDIRECT=y the scene looks like it should do - but animation is extremely slow. My system is a standard SuSE 8.2 installation with XFree86 4.3.0 and the standard 2.4.20 kernel. Graphics adapter: Matrox Millenium G550 (only first head configured) I would have already tried to upgrade some packages if i had known where the problem is. The mga dri driver had a lot of bugs since no one was actively maintaining it. I took that job a few months ago and have since been fixing bugs and adding new features. What we have in cvs should be quite good. A program demonstrating this is the following. As this is extracted from example source code of the NeHe OpenGL tutorial (nehe.gamedev.net) there shouldn't be any coding mistakes in. This example works fine on my system. I'm running DirectFB instead of XFree86 but that should not make any difference. You should try the daily snapshots available from the DRI website... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
On Tue, 25 Nov 2003 10:31:21 + Keith Whitwell [EMAIL PROTECTED] wrote: Ian Romanick wrote: Michel Dänzer wrote: On Mon, 2003-11-24 at 20:01, en ne wrote: I send you the verbose output and the ldd output. libexpat.so.1 = not found This is getting old. This makes at least 10 reports of direct rendering not working that turned out to be libexpat.so problems. Are we or are we not staticly linking with libexpat for the nightly builds? I seriously thought that this was resolved weeks ago. If we're not going to link it statically, can we please use dlopen() and dlsym() to get the expat functionality, and if it's not available, do nothing? Apperently we're not linking statically with libexpat. This is really only a snapshot problem, so doing this dlopen thing would be overkill. As jfonseca doesn't seem to have much time to maintain the snapshots I'd volunteer to setup a snapshot build on freedesktop.org that would link statically with libexpat. I believe I could start building snapshots by the end of this week. If someone's quicker than tat, go ahead ;-) Keith Regards, felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] savage Makefiles
On Mon, 24 Nov 2003 15:40:12 -0600 (CST) [EMAIL PROTECTED] wrote: hi, I checked out the savage-2-0-0 branch but I can't get the savage drivers to compile make World ignores the directory programs/Xserver/hw/drivers/savage You need to add savage to XF86CardDrivers in config/cf/host.def. After that rerun make World world.log. I tried adding the directory in the drivers/Makefile but it causes a lot of errors, probably caused by make not pointing to the correct include directories. Has anyone compiled those drivers succesfuly? If so with which command? Yes, I did, using gcc-3.3.2. If you still get errors after following the instructions above, please post the relevant part of world.log. thanks Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
On Tue, Nov 25, 2003 at 01:27:32PM +0100, Felix Kühling wrote: On Tue, 25 Nov 2003 10:31:21 + Keith Whitwell [EMAIL PROTECTED] wrote: Ian Romanick wrote: Michel Dänzer wrote: On Mon, 2003-11-24 at 20:01, en ne wrote: I send you the verbose output and the ldd output. libexpat.so.1 = not found This is getting old. This makes at least 10 reports of direct rendering not working that turned out to be libexpat.so problems. Are we or are we not staticly linking with libexpat for the nightly builds? I seriously thought that this was resolved weeks ago. No we aren't... If we're not going to link it statically, can we please use dlopen() and dlsym() to get the expat functionality, and if it's not available, do nothing? Apperently we're not linking statically with libexpat. This is really only a snapshot problem, so doing this dlopen thing would be overkill. As jfonseca doesn't seem to have much time to maintain the snapshots I'd volunteer to setup a snapshot build on freedesktop.org that would link statically with libexpat. I believe I could start building snapshots by the end of this week. If someone's quicker than tat, go ahead ;-) Sorry. I forgot to flag your reply describing how to link statically and never remembered the subject again (at that time I was more concerned with the build failure...) I'm taking care of it now. Regarding puting the snapshot builds on freedesktop.org, I'm fine with it (it's true I've been quite busy with other stuff and that perhaps I can't give all the attention required) , but does it has the resources!? It takes about 2hrs in a 1.8GHz to build 3 branches, requiring about 600Mb of temporary hard-drive space to build a branch, plus 100Mb of permanent storage per-branch for the local CVS checkout. The latter can be ignored, since the repository is on the same machine, but the rest is not such a small deal for a machine which appears to be dedicated for web and CVS hosting... Alternatively, I may setup an account for you on my machine, and have the snapshots being built on that account so that you can apply the necessary fixes yourself whenever I'm too slow. Jose Fonseca --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
Actually I did have libexpat statically linked, but as you can see... test $BRANCH == config-0-0-1-branch sed -i -e 's/-lexpat/-Wl,-Bstatic -lexpat -Wl,-Bdynamic/' build/$BRANCH/xc/config/cf/X11.tmpl ... just on config-0-0-1-branch, because the config-0-0-1-branch hadn't been merged into the trunk at that time yet. I've fixed this now and I'll fire a snapshot build to verify it. Still, sorry for not noticing this earlier... Jose Fonseca On Tue, Nov 25, 2003 at 02:48:48PM +, José Fonseca wrote: On Tue, Nov 25, 2003 at 01:27:32PM +0100, Felix Kühling wrote: Ian Romanick wrote: This is getting old. This makes at least 10 reports of direct rendering not working that turned out to be libexpat.so problems. Are we or are we not staticly linking with libexpat for the nightly builds? I seriously thought that this was resolved weeks ago. No we aren't... Apperently we're not linking statically with libexpat. This is really only a snapshot problem, so doing this dlopen thing would be overkill. As jfonseca doesn't seem to have much time to maintain the snapshots I'd volunteer to setup a snapshot build on freedesktop.org that would link statically with libexpat. I believe I could start building snapshots by the end of this week. If someone's quicker than tat, go ahead ;-) Sorry. I forgot to flag your reply describing how to link statically and never remembered the subject again (at that time I was more concerned with the build failure...) I'm taking care of it now. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
On Tue, 2003-11-25 at 06:48, José Fonseca wrote: On Tue, Nov 25, 2003 at 01:27:32PM +0100, Felix Kühling wrote: On Tue, 25 Nov 2003 10:31:21 + Keith Whitwell [EMAIL PROTECTED] wrote: Ian Romanick wrote: Michel Dänzer wrote: On Mon, 2003-11-24 at 20:01, en ne wrote: I send you the verbose output and the ldd output. libexpat.so.1 = not found This is getting old. This makes at least 10 reports of direct rendering not working that turned out to be libexpat.so problems. Are we or are we not staticly linking with libexpat for the nightly builds? I seriously thought that this was resolved weeks ago. No we aren't... If we're not going to link it statically, can we please use dlopen() and dlsym() to get the expat functionality, and if it's not available, do nothing? Apperently we're not linking statically with libexpat. This is really only a snapshot problem, so doing this dlopen thing would be overkill. As jfonseca doesn't seem to have much time to maintain the snapshots I'd volunteer to setup a snapshot build on freedesktop.org that would link statically with libexpat. I believe I could start building snapshots by the end of this week. If someone's quicker than tat, go ahead ;-) Sorry. I forgot to flag your reply describing how to link statically and never remembered the subject again (at that time I was more concerned with the build failure...) I'm taking care of it now. Regarding puting the snapshot builds on freedesktop.org, I'm fine with it (it's true I've been quite busy with other stuff and that perhaps I can't give all the attention required) , but does it has the resources!? It takes about 2hrs in a 1.8GHz to build 3 branches, requiring about 600Mb of temporary hard-drive space to build a branch, plus 100Mb of permanent storage per-branch for the local CVS checkout. The latter can be ignored, since the repository is on the same machine, but the rest is not such a small deal for a machine which appears to be dedicated for web and CVS hosting... It's a dual 2.8 P4 with hyperthreading, sitting essentially idle. I don't see any problem with running snapshots on it. [EMAIL PROTECTED]:/home/anholt% df -m Filesystem 1M-blocks Used Available Use% Mounted on /dev/cciss/c0d0p7 9840 2400 6941 26% / /dev/cciss/c0d0p8 146897 12940133958 9% /home /dev/cciss/c0d0p1 19329 155 16% /boot -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
On Tue, Nov 25, 2003 at 08:55:03AM -0800, Eric Anholt wrote: On Tue, 2003-11-25 at 06:48, José Fonseca wrote: Regarding puting the snapshot builds on freedesktop.org, I'm fine with it (it's true I've been quite busy with other stuff and that perhaps I can't give all the attention required) , but does it has the resources!? It takes about 2hrs in a 1.8GHz to build 3 branches, requiring about 600Mb of temporary hard-drive space to build a branch, plus 100Mb of permanent storage per-branch for the local CVS checkout. The latter can be ignored, since the repository is on the same machine, but the rest is not such a small deal for a machine which appears to be dedicated for web and CVS hosting... It's a dual 2.8 P4 with hyperthreading, sitting essentially idle. I don't see any problem with running snapshots on it. [EMAIL PROTECTED]:/home/anholt% df -m Filesystem 1M-blocks Used Available Use% Mounted on /dev/cciss/c0d0p7 9840 2400 6941 26% / /dev/cciss/c0d0p8 146897 12940133958 9% /home /dev/cciss/c0d0p1 19329 155 16% /boot Great! I had no idea it had such specs. Felix, I'll update the scripts in http://dri.sf.net/snapshots/scripts ASAP. Jose Fonseca --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
On Tue, 25 Nov 2003 14:48:48 + José Fonseca [EMAIL PROTECTED] wrote: [snip] Sorry. I forgot to flag your reply describing how to link statically and never remembered the subject again (at that time I was more concerned with the build failure...) I'm taking care of it now. Thanks! Regarding puting the snapshot builds on freedesktop.org, I'm fine with it (it's true I've been quite busy with other stuff and that perhaps I can't give all the attention required) , but does it has the resources!? It takes about 2hrs in a 1.8GHz to build 3 branches, requiring about 600Mb of temporary hard-drive space to build a branch, plus 100Mb of permanent storage per-branch for the local CVS checkout. The latter can be ignored, since the repository is on the same machine, but the rest is not such a small deal for a machine which appears to be dedicated for web and CVS hosting... Alternatively, I may setup an account for you on my machine, and have the snapshots being built on that account so that you can apply the necessary fixes yourself whenever I'm too slow. What about putting the snapshot build/install scripts into CVS? Then anybody could modify them (with all the necessary care) and it wouldn't matter where the snapshots are being built. You'd just need one additional bootstrap script that would cvs update all the other scripts before building the snapshots. Jose Fonseca Regards, Felix P.S.: Maybe my previous statements about your being too busy were to harsh. I do appreciate the work and computer resources you dedicate to the snapshots. __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 optimization
Roland Scheidegger wrote: I'm really not sure about this, but I believe there could be a severe performance problem when using pci radeons (at least on x86). I haven't seen any measurements of this, and few people seem to have such hardware. But by using the BusType option, I've forced pci mode on my radeon 9000pro agp, and the results are simply terrible. In theory, results should probably be pretty much the same as AGP 1x (same raw data rata, as it's operating as a pci 66mhz device afaik), but it's very different That's not quite true. Most motherboards and cards only support 33MHz PCI. As far as I know, only a few 3dlabs and 3dfx boards ever supported 66MHz PCI fully. If a given application is texture (or vertex, or command) upload bound, that should, at worst, cut performance in half. What's beeing seen here is more like cutting it in a tenth. It's possible that this card is really bad at PCI transfers. Maybe we should put our vertex / command buffers in on-card memory in the PCI case and avoid AGP texturing. That seems yucky, but I'm not even sure how we would go about tracking this down otherwise. in practice. (Tests on other OS certainly show there is next to zero performance difference for graphic cards of this generation and fillrate-heavy games such as Q3A between AGP and PCI). However, since this isn't a true pci card, the chipset (or the driver?) might not like this mode of operation (not sure what could be a problem, but you never know - maybe someone with more knowledge of the drm/gart stuff could answer that). I don't think ATI makes a true PCI chip. They just wire the AGP chip to the bus in such a way that it looks PCI. Remember that AGP and PCI are, both in terms of physical and signal, very, very similar. Results (AXP 1600, 9000pro, 1GB sdram, KT133A Chipset): ^^^ I didn't know Quake3 was available for the Alpha. ;) I know, I know...AXP == Athlon XP. That abreviation was also used for the Alpha architecture, though. glxgears QuakeIII (1024x768, graphic options all set to high) AGP 4x 1910 62.5 AGP 1x 1860 61.1 PCI 200 16.8 Ouch. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Xserver crashing 2.4.22 kernel (Intel 82845G/GL)
Hi, I have a MSI 845GL-P barebone, 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 01) and do use it with 2.4.22, i830 and agpgart kernel modules and 4.3.0-0pre1v1 xfree86-xserver (debian package). Unfortunately the kernel crashes every few minutes. The problem is that it does not crash immediately, it continuously degenerates. Some programs start to behave crazy or simply disappear, and the kernel shows more and more malfunctions, like being unable to remove kernel modules or finding hard discs. I manged to get a trace once (see below), but I'm pretty sure it's useless, since this is not what's causing the problem. I am pretty sure that the combination of the xserver with this vga device corrupts kernel memory structures (many normal programs suddenly die with segmentation fault or with a kernel error message about mapping problems. When I finally get a Oops debug output, thing have already gone wrong. I first used the machine without i830 and agpgart modules, but this was even worse. Do you have any idea whether this is a known bug? regards Hadmut Unable to handle kernel paging request at virtual address 04004188 c013cc5a *pde = Oops: CPU:0 EIP:0010:[c013cc5a]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 04004160 ebx: d6116500 ecx: edx: esi: c158e340 edi: dede6780 ebp: dedf8500 esp: d60f5e8c ds: 0018 es: 0018 ss: 0018 Process .xsession (pid: 1543, stackpage=d60f5000) Stack: d6116500 d5f7c084 d77f4180 6000 deefa200 080dc000 c012cf1a deefa200 080dc000 6000 d77f4480 deefa200 d60f4000 000f c011a7e7 deefa200 0202 deefa200 c011f337 deefa200 c158631c d60f4000 Call Trace:[c012cf1a] [c011a7e7] [c011f337] [c0124e2c] [c0125005] [c0108dfa] [c011f691] [c011f955] [c01090f8] Code: 8b 50 28 85 d2 0f 85 8d 00 00 00 85 c0 74 17 8b 00 85 c0 74 EIP; c013cc5a fput+5a/120 = ebx; d6116500 _end+15e084a8/20612008 esi; c158e340 _end+12802e8/20612008 edi; dede6780 _end+1ead8728/20612008 ebp; dedf8500 _end+1eaea4a8/20612008 esp; d60f5e8c _end+15de7e34/20612008 Trace; c012cf1a exit_mmap+12a/140 Trace; c011a7e7 mmput+47/b0 Trace; c011f337 do_exit+77/260 Trace; c0124e2c sig_exit+ac/b0 Trace; c0125005 dequeue_signal+65/d0 Trace; c0108dfa do_signal+1ca/2c0 Trace; c011f691 sys_wait4+131/3d0 Trace; c011f955 sys_waitpid+25/30 Trace; c01090f8 signal_return+14/18 Code; c013cc5a fput+5a/120 _EIP: Code; c013cc5a fput+5a/120 = 0: 8b 50 28 mov0x28(%eax),%edx = Code; c013cc5d fput+5d/120 3: 85 d2 test %edx,%edx Code; c013cc5f fput+5f/120 5: 0f 85 8d 00 00 00 jne98 _EIP+0x98 Code; c013cc65 fput+65/120 b: 85 c0 test %eax,%eax Code; c013cc67 fput+67/120 d: 74 17 je 26 _EIP+0x26 Code; c013cc69 fput+69/120 f: 8b 00 mov(%eax),%eax Code; c013cc6b fput+6b/120 11: 85 c0 test %eax,%eax Code; c013cc6d fput+6d/120 13: 74 00 je 15 _EIP+0x15 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 optimization
On Tue, 2003-11-25 at 00:45, Roland Scheidegger wrote: Results (AXP 1600, 9000pro, 1GB sdram, KT133A Chipset): glxgears QuakeIII (1024x768, graphic options all set to high) AGP 4x 1910 62.5 AGP 1x 1860 61.1 PCI 200 16.8 I've seen similarly pathetic PCI GART performance with newer chips on Macs, but not with older chips (IIRC the M6 worked as expected, but not M7 and M9; I thought this might be related to the L3 cache which was added to PowerBooks at the same time). I basically see two possible reasons: * There's something about newer ATI AGP cards which makes them perform very poorly with PCI GART * Our drivers do something which makes newer chips perform very poorly with PCI GART, be they AGP or PCI The former wouldn't necessarily say anything about PCI cards, but I'm not sure how to determine which it is (and what exactly the actual cause is). -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
Keith Whitwell wrote: Ian Romanick wrote: Michel Dnzer wrote: On Mon, 2003-11-24 at 20:01, en ne wrote: I send you the verbose output and the ldd output. libexpat.so.1 = not found This is getting old. This makes at least 10 reports of direct rendering not working that turned out to be libexpat.so problems. Are we or are we not staticly linking with libexpat for the nightly builds? I seriously thought that this was resolved weeks ago. If we're not going to link it statically, can we please use dlopen() and dlsym() to get the expat functionality, and if it's not available, do nothing? The problem seems to be with older distros that have libexpat.so.0 instead of libexpat.so.1. People have found that it works if they symlink libexpat.so.0 to libexpat.so.1. Can we just link with libexpat.so instead? They dlsym option should also work, but may result in other false bug reports (i.e., DRI driver ignores my settings). :( --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Xserver crashing 2.4.22 kernel (Intel 82845G/GL)
[EMAIL PROTECTED] wrote: Hi, I have a MSI 845GL-P barebone, 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 01) and do use it with 2.4.22, i830 and agpgart kernel modules and 4.3.0-0pre1v1 xfree86-xserver (debian package). Unfortunately the kernel crashes every few minutes. The problem is that it does not crash immediately, it continuously degenerates. Some programs start to behave crazy or simply disappear, and the kernel shows more and more malfunctions, like being unable to remove kernel modules or finding hard discs. I manged to get a trace once (see below), but I'm pretty sure it's useless, since this is not what's causing the problem. Are you sure you don't have faulty hardware? These symptoms sound like they might well originate from bad ram, bad cpu, bad harddrive, or maybe an overheated system. I am pretty sure that the combination of the xserver with this vga device corrupts kernel memory structures (many normal programs suddenly die with segmentation fault or with a kernel error message about mapping problems. When I finally get a Oops debug output, thing have already gone wrong. I first used the machine without i830 and agpgart modules, but this was even worse. So why do you think the DRI drivers are the reason then? Do you have any idea whether this is a known bug? regards Hadmut --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] HAVE_HW_FLAT_SHADE inverted?
Hi,
I'm looking into the various templates in Mesa/src/tnl_dd as I'm trying
to port the savage driver to current Mesa. I was wondering what the
HAVE_HW_FLAT_SHADE macro is doing? It only appears in t_dd_unfilled.h
and it looks like it's doing the exact opposite of what it says:
if ((ctx-_TriangleCaps DD_FLATSHADE) HAVE_HW_FLATSHADE) {
/* ... save colors and copy from last vertex ... */
}
I believe it should be:
if ((ctx-_TriangleCaps DD_FLATSHADE) !HAVE_HW_FLATSHADE) {
/* ... save colors and copy from last vertex ... */
}
Am I missing something?
Regards,
Felix
__\|/_____ ___ -
Felix ___\_e -_/___/ __\___/ __\_ You can do anything,
Kühling (_\Ä// /_/ /) just not everything
[EMAIL PROTECTED] \___/ \___/ Uat the same time.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 optimization
Alan Cox wrote: On Maw, 2003-11-25 at 20:26, Michel Dnzer wrote: * Our drivers do something which makes newer chips perform very poorly with PCI GART, be they AGP or PCI The former wouldn't necessarily say anything about PCI cards, but I'm not sure how to determine which it is (and what exactly the actual cause is). Is there code reading from PCI space as it builds stuff or uploads textures. Anything that ends up doing *pciaddr=foo [blah] if(x) *pciaddr|=FOOFLAG; kills your performance on PCI bus. I'm pretty sure that anything that did that for PCI would also do it for AGP. I assume that would kill performance even more, yes? Could somebody with an actual PCI card try this with ATI's driver? If the performance is okay there, that will point the finger at our driver rather than the hardware. If the performance is horrible there, that will point the finger at the hardware. :) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 optimization
On Wed, 2003-11-26 at 10:32, Ian Romanick wrote: I'm pretty sure that anything that did that for PCI would also do it for AGP. I assume that would kill performance even more, yes? Could somebody with an actual PCI card try this with ATI's driver? If the performance is okay there, that will point the finger at our driver rather than the hardware. If the performance is horrible there, that will point the finger at the hardware. :) DRI is slow for the ATI Radeon 9000 PCI QuakeForge CVS default settings with timedemo overkill gets 16-17fps on averages, in windows I get between 30-35fps. NWN is unplayable for me in linux (estimate 2fps), yet in windows its fine. Wolf:ET, the graphics appears faster and smoother in windows than in linux, but I haven't been able to work out how to do any decent fps test with it yet. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 optimization
Chris Ison wrote: On Wed, 2003-11-26 at 10:32, Ian Romanick wrote: I'm pretty sure that anything that did that for PCI would also do it for AGP. I assume that would kill performance even more, yes? Could somebody with an actual PCI card try this with ATI's driver? If the performance is okay there, that will point the finger at our driver rather than the hardware. If the performance is horrible there, that will point the finger at the hardware. :) DRI is slow for the ATI Radeon 9000 PCI Can you try ATI's binary drivers for Linux, or are you not on x86? --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 optimization
Can you try ATI's binary drivers for Linux, or are you not on x86? ATI's FireGL drivers do not support PCI cards, lord knows I tried. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 optimization
Can you try ATI's binary drivers for Linux, or are you not on x86? ATI's FireGL drivers do not support PCI cards, lord knows I tried. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libexpat foo, was: Re: [Dri-devel] ATI radeon 9200 DRI
On Tue, Nov 25, 2003 at 12:28:29PM -0800, Ian Romanick wrote: The problem seems to be with older distros that have libexpat.so.0 instead of libexpat.so.1. People have found that it works if they symlink libexpat.so.0 to libexpat.so.1. It's not just older distros. Gentoo has libexpat.so.0 also. libexpat is version 1.95.7 btw. Why does the build system link with .1 anyway? Does it have two versions of libexpat installed and the linker does this automagically or does the distro package add some patch to expat forcing the name to .1? Gentoo's expat doesn't seem to have any patches related to this. Can we just link with libexpat.so instead? So someone should just relink the build system's libexpat with -soname libexpat.so? -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] HAVE_HW_FLAT_SHADE inverted?
On Tue, Nov 25, 2003 at 10:17:46PM +0100, Felix Kühling wrote:
Hi,
I'm looking into the various templates in Mesa/src/tnl_dd as I'm trying
to port the savage driver to current Mesa. I was wondering what the
HAVE_HW_FLAT_SHADE macro is doing? It only appears in t_dd_unfilled.h
and it looks like it's doing the exact opposite of what it says:
if ((ctx-_TriangleCaps DD_FLATSHADE) HAVE_HW_FLATSHADE) {
/* ... save colors and copy from last vertex ... */
}
I believe it should be:
if ((ctx-_TriangleCaps DD_FLATSHADE) !HAVE_HW_FLATSHADE) {
/* ... save colors and copy from last vertex ... */
}
Am I missing something?
I think so. For hardware without flatshading the copy is done in
t_dd_tritmp.h and so t_dd_unfilled.h must not do it again. But since
t_dd_unfilled uses points and lines the colors need to be copied even for
hardware with flatshading.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
