[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugs.xfree86.org/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the Reassign bug to owner of selected component option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the Accept bug command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW[EMAIL PROTECTED] Or, you can use the general query page, at http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=120 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=271 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=314 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=344 --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9200 tester available
On Mon, Jun 30, 2003 at 04:19:09PM +0200, Michel Dänzer wrote: On Fri, 2003-06-27 at 21:05, Rupert Levene wrote: I'm using X 4.3 (a backport on debian woody) with the precompiled drivers from dri.sf.net and a radeon 9200. I currently have 3 issues which I think may be down to the drivers: 1. In tuxracer, noegnud and some other programs, it seems that when 2D bitmaps are drawn adjacent to each other, there are black lines between them. I've seen this with tuxracer on Mac OS X as well, so I doubt it's exclusively a driver problem. Yes, this is now fixed in noegnud. 2. In noegnud, if there is text in a window that is partially off-screen, the text is invisible. When the window is moved so that it is all on-screen the text reappears. (This _could_ be a bug in noegnud). Indeed, the driver shouldn't particularly care about this. Anyway, do you have a procedure to reproduce the problem? I didn't notice anything obvious on a quick try. Yes: hit f10 and drag the window off various edges of the screen. See http://levene.dyndns.org/invisible-text/ for screenshots. Also, there's no text in the 'console' pane at the top unless that is dragged out to fill the whole screen, which I'd guess is a manifestation of the same problem. 3. If I don't rmmod and then insmod the agpgart and radeon modules Isn't the radeon module only enough? every time before I start X, then DRI is always disabled. This isn't a huge problem, but I'm not sure why happens. This has been reported and discussed before. Does it still happen after the recent rollback of some janitorial changes? Not sure ATM. When I have a chunk of free time to try new stuff I'll do so. Rupert --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ERROR COMPILING - DRI Driver Installation (R E P O S T)
After I see this: Compiling... ERROR: Kernel modules did not compile I get the following in dri.log, when I try sh install.sh make -f Makefile.linux DRM_MODULES=radeon.o modulesmake[1]: Entering directory `/home/john/dripkg/drm'make -C /lib/modules/2.4.20-8/build SUBDIRS=`pwd` DRMSRCDIR=`pwd` modulesmake[2]: Entering directory `/usr/src/linux-2.4.20-8'make -r -f tmp_include_depends allmake[3]: Entering directory `/usr/src/linux-2.4.20-8'touch: creating `/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h': No such file or directorymake[3]: *** [/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h] Error 1make[3]: Leaving directory `/usr/src/linux-2.4.20-8'make[2]: *** [tmp_include_depends] Error 2make[2]: Leaving directory `/usr/src/linux-2.4.20-8'make[1]: *** [modules] Error 2make[1]: Leaving directory `/home/john/dripkg/drm'make: *** [radeon.o] Error 2 I have RedHat 9 and an ATI Radeon 64MB DDR VIVO. Yes, I do have the kernel source installed. --John
Re: [Dri-devel] ERROR COMPILING - DRI Driver Installation (R E P O S T)
John, On Wed, Jul 02, 2003 at 09:15:42AM -0400, John R. Tomawski wrote: After I see this: Compiling... ERROR: Kernel modules did not compile I get the following in dri.log, when I try sh install.sh make -f Makefile.linux DRM_MODULES=radeon.o modules make[1]: Entering directory `/home/john/dripkg/drm' make -C /lib/modules/2.4.20-8/build SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules make[2]: Entering directory `/usr/src/linux-2.4.20-8' ^^ You say you have the kernel source installed, but that's not enough. It must be configured exactly as your target kernel and the dependencies must have been made, i.e., 'make dep' on the kernel source dir. Also try just doing: make -f Makefile.linux radeon.o on /home/john/dripkg/drm and see if it helps. make -r -f tmp_include_depends all make[3]: Entering directory `/usr/src/linux-2.4.20-8' touch: creating `/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h': No such file or directory make[3]: *** [/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.20-8' make[2]: *** [tmp_include_depends] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20-8' make[1]: *** [modules] Error 2 make[1]: Leaving directory `/home/john/dripkg/drm' make: *** [radeon.o] Error 2 I have RedHat 9 and an ATI Radeon 64MB DDR VIVO. Yes, I do have the kernel source installed. José Fonseca --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS keywords in Imakefiles
On Tue, Jul 01, 2003 at 10:30:48PM +0200, Felix Kühling wrote: Hi, I've been wondering about keywords in Imakefiles that look like CVS keywords. Examples from xc/programs/Imakefile: XCOMM $Xorg: Imakefile,v 1.4 2000/08/17 19:47:01 cpqbld Exp $ XCOMM $XFree86: xc/programs/Imakefile,v 3.53 2002/11/20 04:43:50 dawes Exp $ Of course they are not documented in the CVS manual. How did they get expanded? What should I write in a new Imakefile? All you need to write in each file is... /* $XFree86$ */ And this will get expanded properly when it hits XFree86's CVS. You can ignore the Xorg one though - you don't need to add that. Alan. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS keywords in Imakefiles
On Wed, Jul 02, 2003 at 05:28:05PM +0100, Alan Hourihane wrote: On Tue, Jul 01, 2003 at 10:30:48PM +0200, Felix Kühling wrote: Hi, I've been wondering about keywords in Imakefiles that look like CVS keywords. Examples from xc/programs/Imakefile: XCOMM $Xorg: Imakefile,v 1.4 2000/08/17 19:47:01 cpqbld Exp $ XCOMM $XFree86: xc/programs/Imakefile,v 3.53 2002/11/20 04:43:50 dawes Exp $ Of course they are not documented in the CVS manual. How did they get expanded? What should I write in a new Imakefile? All you need to write in each file is... /* $XFree86$ */ And this will get expanded properly when it hits XFree86's CVS. You can ignore the Xorg one though - you don't need to add that. Sorry, forgot to add... In an Imakefile you need to do this XCOMM $XFree86$ Alan. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Stange multi-context problem in Radeon driver (and probably others)
I have completed all of the device-independent support (both client-side server-side) for SGI_make_current_read. I wanted to update a couple drivers to support this extension before committing it. I was able to update the MGA driver without any problems. The Radeon (r100) driver is a totally different story. To test things, I've been using a modified version of our favorite glxgears (patch attached) that uses two windows. The usual gears are rendered into one window, then the contents of that window are used as a texture for a single quad in the other window. The test can run properly when either SGI_make_read_current, GLX 1.3, or plain GLX 1.1 (i.e., no extensions) is supported. On the Radeon, this test fails even in GLX 1.1 mode. In GLX 1.1 mode, the first window is empty (all black), but the second window, that uses the contents of the first as a texture, was drawn correctly. I tracked this down to a problem in radeonCopyBuffer (radeon_ioctl.c, line 807). Even though a __DRIdrawablePrivate is passed into this function, it uses the drawable stored in the current context. Note the uses of rmesa-dri.drawable. I investigated a bit further and discovered that the r200 r128 drivers all have this problem. I made the obvious fix to radeonCopyBuffer and tried again. There are now three different, probably unrelated problems. 1. When the first window is moved around, parts of its contents get left behind on other windows and on the desktop. Moving the second window around does not have this problem. 2. When a window partially obstructs the first window, the texture used for the second window is clipped. That is, the part of the texture that corresponds to the obscured part of the first window is black. I suspect this is just the nature of having a single back-buffer. 3. When the test is run with both -twowindow and -ztrick, the texture used in the second window is always all black. For some reason, on my system, -ztrick does not work in indirect mode. If I change the drawing of the background polygon to use glColor3f glVertex3f directly instead of a vertex list, it works. I have not investigated this yet. Using -ztrick by itself on the R100 works fine. I haven't tried any of this on an R200 yet, and I don't have access to a Rage128. I expect there's some state that isn't being properly updated when the drawable changes, but it's not obvious to me what it is. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200: Why is SW TCL faster?
IIRC this came up in a discussion with Michel Dänzer and someone else some months ago. I noticed that glxgears was slightly faster without TCL on my Radeon 7500. We argued that TCL means that the graphics card has to do more work and the CPU less. If your CPU is not otherwise occupied you can get higher framerates without TCL as the work is sort of shared by CPU and graphics card. You should also notice a higher CPU utilisation without TCL. If you get big differences in frame rates it may be something else, though. Well, I don't know if I'd call them big differences but they seem significant. In atlantis (800x600) for example: HWTCL 354.9 fps SWTCL 436.6 fps ATI 436.6 fps Where ATI is the x4.3.0 drivers found here: http://www.schneider-digital.de/html/download_ati.html In gears (800x600) the diffrence between HWTCL and SWTCL are less notcible (I used top to get the idle times). HWTCL 235.8 fps 96-97% idle SWTCL 235.6 fps 92-93% idle ATI 394.3 fps 0% idle (??) This all seems very weird to me. Could it be that there are cases where using HWTCL just isn't worth it? jOrGe W. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Stange multi-context problem in Radeon driver (andprobably others)
Ian Romanick wrote:
To test things, I've been using a modified version of our favorite
glxgears (patch attached) that uses two windows.
Eh-hem. The summer heat must have melted my brain. The patch is
actually attached this time. :)
Index: glxgears.c
===
RCS file: /cvsroot/mesa3d/Mesa/xdemos/glxgears.c,v
retrieving revision 1.7
diff -u -d -r1.7 glxgears.c
--- glxgears.c 30 May 2003 18:41:38 - 1.7
+++ glxgears.c 2 Jul 2003 16:26:42 -
@@ -48,6 +48,8 @@
#include GL/gl.h
#include GL/glx.h
+#include assert.h
+
#ifndef GLX_MESA_swap_control
typedef GLint ( * PFNGLXSWAPINTERVALMESAPROC) (unsigned interval);
typedef GLint ( * PFNGLXGETSWAPINTERVALMESAPROC) ( void );
@@ -112,7 +114,9 @@
static GLint gear1, gear2, gear3;
static GLfloat angle = 0.0;
+static GLboolean has_GLX_1_3 = GL_FALSE;
static GLboolean has_OML_sync_control = GL_FALSE;
+static GLboolean has_SGI_make_current_read = GL_FALSE;
static GLboolean has_SGI_swap_control = GL_FALSE;
static GLboolean has_MESA_swap_control = GL_FALSE;
static GLboolean has_MESA_swap_frame_usage = GL_FALSE;
@@ -266,6 +270,7 @@
draw(void)
{
if ( use_ztrick ) {
+ unsigned i;
static GLboolean flip = GL_FALSE;
static const GLfloat vert[4][3] = {
{ -1, -1, -0.999 },
@@ -352,9 +357,74 @@
}
+static void
+draw2( Display * dpy, Window * win, GLXContext ctx )
+{
+ GLboolean result;
+
+ if ( has_GLX_1_3 ) {
+ result = glXMakeContextCurrent(dpy, win[1], win[0], ctx);
+ }
+ else if ( has_SGI_make_current_read ) {
+ result = glXMakeCurrentReadSGI(dpy, win[1], win[0], ctx);
+ }
+ else {
+ result = glXMakeCurrent(dpy, win[0], ctx);
+ }
+
+ /* FIXME: If this fails, how can the app determine why it failed? */
+ assert( result );
+
+ glBindTexture( GL_TEXTURE_2D, 1 );
+ glCopyTexSubImage2D( GL_TEXTURE_2D, 0, 0, 0, 0, 0, 300, 300 );
+
+ if ( ! (has_GLX_1_3 || has_SGI_make_current_read) ) {
+ result = glXMakeCurrent(dpy, win[1], ctx);
+ assert( result );
+ }
+
+ glBindTexture( GL_TEXTURE_2D, 1 );
+
+ glDisable(GL_CULL_FACE);
+ glDisable(GL_LIGHTING);
+ glDisable(GL_LIGHT0);
+ glDisable(GL_DEPTH_TEST);
+ glEnable(GL_TEXTURE_2D);
+
+ glMatrixMode(GL_TEXTURE);
+ glLoadIdentity();
+ glTranslatef(0.5, 0.5, 0.0);
+ glRotatef(angle, 0, 0, 1);
+ glTranslatef(-0.5, -0.5, 0.0);
+ glMatrixMode(GL_MODELVIEW);
+
+ glBegin(GL_POLYGON);
+
+ glTexCoord2f( 0.0, 0.0 );
+ glVertex2f( -5.0, -5.0 );
+
+ glTexCoord2f( 0.0, 0.0 );
+ glVertex2f( 5.0, -5.0 );
+
+ glTexCoord2f( 1.0, 1.0 );
+ glVertex2f( 5.0, 5.0 );
+
+ glTexCoord2f( 0.0, 1.0 );
+ glVertex2f( -5.0, 5.0 );
+
+ glEnd();
+
+ glDisable(GL_TEXTURE_2D);
+ glEnable(GL_CULL_FACE);
+ glEnable(GL_LIGHTING);
+ glEnable(GL_LIGHT0);
+ glEnable(GL_DEPTH_TEST);
+}
+
+
/* new window size or exposure */
static void
-reshape(int width, int height)
+reshape(Window win, int width, int height)
{
aspect = (GLfloat) height / (GLfloat) width;
@@ -371,7 +441,7 @@
static void
-init(void)
+init(GLboolean create_texture_object)
{
static GLfloat pos[4] = { 5.0, 5.0, 10.0, 0.0 };
static GLfloat red[4] = { 0.8, 0.1, 0.0, 1.0 };
@@ -404,6 +474,21 @@
glEndList();
glEnable(GL_NORMALIZE);
+
+
+ /* Initialize the texture object so that glCopyTexSubImage2D can be used
+* to update its contents.
+*/
+
+ if ( create_texture_object ) {
+ glBindTexture(GL_TEXTURE_2D, 1);
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
+ glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 512, 512, 0, GL_RGB, GL_BYTE,
+ NULL);
+ }
}
@@ -414,7 +499,8 @@
static void
make_window( Display *dpy, const char *name,
int x, int y, int width, int height,
- Window *winRet, GLXContext *ctxRet)
+ Window *winRet, GLXContext *ctxRet,
+GLboolean two_windows )
{
int attrib[] = { GLX_RGBA,
GLX_RED_SIZE, 1,
@@ -427,9 +513,8 @@
XSetWindowAttributes attr;
unsigned long mask;
Window root;
- Window win;
- GLXContext ctx;
XVisualInfo *visinfo;
+ XSizeHints sizehints;
scrnum = DefaultScreen( dpy );
root = RootWindow( dpy, scrnum );
@@ -447,51 +532,72 @@
attr.event_mask = StructureNotifyMask | ExposureMask | KeyPressMask;
mask = CWBackPixel | CWBorderPixel | CWColormap | CWEventMask;
- win = XCreateWindow( dpy, root, 0, 0, width, height,
- 0, visinfo-depth, InputOutput,
- visinfo-visual, mask, attr );
+ winRet[0] = XCreateWindow( dpy, root, 0, 0, width, height,
+ 0, visinfo-depth,
Re: [Dri-devel] Stange multi-context problem in Radeon driver (andprobably others)
Ian Romanick wrote: I have completed all of the device-independent support (both client-side server-side) for SGI_make_current_read. I wanted to update a couple drivers to support this extension before committing it. I was able to update the MGA driver without any problems. The Radeon (r100) driver is a totally different story. To test things, I've been using a modified version of our favorite glxgears (patch attached) that uses two windows. The usual gears are rendered into one window, then the contents of that window are used as a texture for a single quad in the other window. The test can run properly when either SGI_make_read_current, GLX 1.3, or plain GLX 1.1 (i.e., no extensions) is supported. On the Radeon, this test fails even in GLX 1.1 mode. In GLX 1.1 mode, the first window is empty (all black), but the second window, that uses the contents of the first as a texture, was drawn correctly. I tracked this down to a problem in radeonCopyBuffer (radeon_ioctl.c, line 807). Even though a __DRIdrawablePrivate is passed into this function, it uses the drawable stored in the current context. Note the uses of rmesa-dri.drawable. I investigated a bit further and discovered that the r200 r128 drivers all have this problem. I made the obvious fix to radeonCopyBuffer and tried again. There are now three different, probably unrelated problems. 1. When the first window is moved around, parts of its contents get left behind on other windows and on the desktop. Moving the second window around does not have this problem. Off the top of my head... There's a macro to the effect of VALIDATE_DRAWABLE which needs to be called to ensure that the cliprect list for a drawable is up to date before rendering. I'd look in that area. 2. When a window partially obstructs the first window, the texture used for the second window is clipped. That is, the part of the texture that corresponds to the obscured part of the first window is black. I suspect this is just the nature of having a single back-buffer. That's correct. The OpenGL spec says that the contents of the color/depth/stencil/etc buffers may be undefined when regions are obscured or off-screen. 3. When the test is run with both -twowindow and -ztrick, the texture used in the second window is always all black. For some reason, on my system, -ztrick does not work in indirect mode. If I change the drawing of the background polygon to use glColor3f glVertex3f directly instead of a vertex list, it works. I have not investigated this yet. Using -ztrick by itself on the R100 works fine. By vertex list do you mean display list? Perhaps some state isn't getting validated before the list is executing. Try putting a glFlush() before glCallList and see what happens. I haven't tried any of this on an R200 yet, and I don't have access to a Rage128. I expect there's some state that isn't being properly updated when the drawable changes, but it's not obvious to me what it is. BTW, I think I'd like to see glxgears restored to its original, unextended state. Then, exercise these extensions (and swap control, etc) in new variants of glxgears (like swaprate.c and/or readbuffer.c). I'm still not convinced the inttypes.h problem is solved and I'd like to keep glxgears simple/portable. -Brian --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ERROR COMPILING - DRI Driver Installation (R E P O S T)
Please explain this a little more. You say you have the kernel source installed, but that's not enough. It must be configured exactly as your target kernel and the dependencies must have been made, i.e., 'make dep' on the kernel source dir. I did this, it gave me the same errors. Also try just doing: make -f Makefile.linux radeon.o on /home/john/dripkg/drm and see if it helps. - Original Message - From: José Fonseca [EMAIL PROTECTED] To: John R. Tomawski [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 10:05 AM Subject: Re: [Dri-devel] ERROR COMPILING - DRI Driver Installation (R E P O S T) John, On Wed, Jul 02, 2003 at 09:15:42AM -0400, John R. Tomawski wrote: After I see this: Compiling... ERROR: Kernel modules did not compile I get the following in dri.log, when I try sh install.sh make -f Makefile.linux DRM_MODULES=radeon.o modules make[1]: Entering directory `/home/john/dripkg/drm' make -C /lib/modules/2.4.20-8/build SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules make[2]: Entering directory `/usr/src/linux-2.4.20-8' ^^ You say you have the kernel source installed, but that's not enough. It must be configured exactly as your target kernel and the dependencies must have been made, i.e., 'make dep' on the kernel source dir. Also try just doing: make -f Makefile.linux radeon.o on /home/john/dripkg/drm and see if it helps. make -r -f tmp_include_depends all make[3]: Entering directory `/usr/src/linux-2.4.20-8' touch: creating `/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug. h': No such file or directory make[3]: *** [/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug. h] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.20-8' make[2]: *** [tmp_include_depends] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20-8' make[1]: *** [modules] Error 2 make[1]: Leaving directory `/home/john/dripkg/drm' make: *** [radeon.o] Error 2 I have RedHat 9 and an ATI Radeon 64MB DDR VIVO. Yes, I do have the kernel source installed. José Fonseca --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Stange multi-context problem in Radeon driver (and probably others)
Am Mittwoch, 2. Juli 2003 18:50 schrieb Ian Romanick: I have completed all of the device-independent support (both client-side server-side) for SGI_make_current_read. I wanted to update a couple drivers to support this extension before committing it. I was able to update the MGA driver without any problems. The Radeon (r100) driver is a totally different story. To test things, I've been using a modified version of our favorite glxgears (patch attached) that uses two windows. The usual gears are rendered into one window, then the contents of that window are used as a texture for a single quad in the other window. The test can run properly when either SGI_make_read_current, GLX 1.3, or plain GLX 1.1 (i.e., no extensions) is supported. On the Radeon, this test fails even in GLX 1.1 mode. In GLX 1.1 mode, the first window is empty (all black), but the second window, that uses the contents of the first as a texture, was drawn correctly. I tracked this down to a problem in radeonCopyBuffer (radeon_ioctl.c, line 807). Even though a __DRIdrawablePrivate is passed into this function, it uses the drawable stored in the current context. Note the uses of rmesa-dri.drawable. I investigated a bit further and discovered that the r200 r128 drivers all have this problem. Have you tried with the normal CVS trunk r100/r200 driver? Some others (e.g. Andreas) and I have reported several times that there is a multi-context (locking) problem. See: [Dri-devel] Problem with Radeon 9000 and lockups and [Dri-devel] radeon locking doesnt work right Try two gears plus one ipers or two ipers = boom. Some xdemos apps show it, too. wincopy isn't working. Mesa/xdemos ./wincopy glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() [-] manywin update only the lasted created window in hardware mode (n=28). All additional windows (indirect mode) would be updated simultaneously. Sometimes it locks X after the second try. glthreads locks X after some seconds, some copies, too. My former system (single 1 GHz Athlon SlotA, Voodoo5 5500 AGP) could run n=100 (or more) with both. I see some VTK multi-context (TaskParallelism, window resizing/overlapping) problems, too. And there are some textures/colors missing (ParallelIso, ParallelIsoTest, PipelineParallelism, TaskParallelismWithPorts). setenv R200_NO_TCL 1 fix this. Next one: stex3d show a clipping (?) bug. When I move stex3d to the right side of my desktop (1280x1024x24/32) the torus would be falsely clipped and broken rendered. I have snapshots. Last one celestia: The earth (Follow Earth [Earth]) show some flickering (wrong triangles, triangel strips) between Southafrica and the Southpole. Most of these problems are gone with indirect rendering. Except: wincopy and VTK TaskParallelism (window resizing/overlapping). Regards, Dieter --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Stange multi-context problem in Radeon driver (andprobably others)
Dieter Nützel wrote: Am Mittwoch, 2. Juli 2003 18:50 schrieb Ian Romanick: I have completed all of the device-independent support (both client-side server-side) for SGI_make_current_read. I wanted to update a couple drivers to support this extension before committing it. I was able to update the MGA driver without any problems. The Radeon (r100) driver is a totally different story. To test things, I've been using a modified version of our favorite glxgears (patch attached) that uses two windows. The usual gears are rendered into one window, then the contents of that window are used as a texture for a single quad in the other window. The test can run properly when either SGI_make_read_current, GLX 1.3, or plain GLX 1.1 (i.e., no extensions) is supported. On the Radeon, this test fails even in GLX 1.1 mode. In GLX 1.1 mode, the first window is empty (all black), but the second window, that uses the contents of the first as a texture, was drawn correctly. I tracked this down to a problem in radeonCopyBuffer (radeon_ioctl.c, line 807). Even though a __DRIdrawablePrivate is passed into this function, it uses the drawable stored in the current context. Note the uses of rmesa-dri.drawable. I investigated a bit further and discovered that the r200 r128 drivers all have this problem. Have you tried with the normal CVS trunk r100/r200 driver? Some others (e.g. Andreas) and I have reported several times that there is a multi-context (locking) problem. See: [Dri-devel] Problem with Radeon 9000 and lockups and [Dri-devel] radeon locking doesnt work right Try two gears plus one ipers or two ipers = boom. This is a different issue, I believe. The problem here seems to be related to having two different processes, each with a GL context. The problems that I'm seeing are related to having a single process with multiple contexts. Some xdemos apps show it, too. wincopy isn't working. Mesa/xdemos ./wincopy glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() [-] wincopy doesn't work because it's trying to use an unsupported GLX 1.3 call. glXMakeContextCurrent glXMakeCurrentReadSGI are the functions that I'm trying to add support for. On my system with my patches, wincopy works fairly well. :) manywin update only the lasted created window in hardware mode (n=28). All additional windows (indirect mode) would be updated simultaneously. Sometimes it locks X after the second try. *This* might very well be related. I notice that if manywin is run with '-s' it works fine. Is there a bug filed, either in the DRI database or the XFree86 database, for this? --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Stange multi-context problem in Radeon driver (and probably others)
Am Mittwoch, 2. Juli 2003 22:26 schrieb Ian Romanick: Dieter Nützel wrote: Am Mittwoch, 2. Juli 2003 18:50 schrieb Ian Romanick: I have completed all of the device-independent support (both client-side server-side) for SGI_make_current_read. I wanted to update a couple drivers to support this extension before committing it. I was able to update the MGA driver without any problems. The Radeon (r100) driver is a totally different story. To test things, I've been using a modified version of our favorite glxgears (patch attached) that uses two windows. The usual gears are rendered into one window, then the contents of that window are used as a texture for a single quad in the other window. The test can run properly when either SGI_make_read_current, GLX 1.3, or plain GLX 1.1 (i.e., no extensions) is supported. On the Radeon, this test fails even in GLX 1.1 mode. In GLX 1.1 mode, the first window is empty (all black), but the second window, that uses the contents of the first as a texture, was drawn correctly. I tracked this down to a problem in radeonCopyBuffer (radeon_ioctl.c, line 807). Even though a __DRIdrawablePrivate is passed into this function, it uses the drawable stored in the current context. Note the uses of rmesa-dri.drawable. I investigated a bit further and discovered that the r200 r128 drivers all have this problem. Have you tried with the normal CVS trunk r100/r200 driver? Some others (e.g. Andreas) and I have reported several times that there is a multi-context (locking) problem. See: [Dri-devel] Problem with Radeon 9000 and lockups and [Dri-devel] radeon locking doesnt work right Try two gears plus one ipers or two ipers = boom. This is a different issue, I believe. The problem here seems to be related to having two different processes, each with a GL context. The problems that I'm seeing are related to having a single process with multiple contexts. Some xdemos apps show it, too. wincopy isn't working. Mesa/xdemos ./wincopy glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() [-] wincopy doesn't work because it's trying to use an unsupported GLX 1.3 call. glXMakeContextCurrent glXMakeCurrentReadSGI are the functions that I'm trying to add support for. On my system with my patches, wincopy works fairly well. :) I want Mesa 5.1 (5.2), now ;-) manywin update only the lasted created window in hardware mode (n=28). All additional windows (indirect mode) would be updated simultaneously. Sometimes it locks X after the second try. *This* might very well be related. I notice that if manywin is run with '-s' it works fine. Is there a bug filed, either in the DRI database or the XFree86 database, for this? No? --- Not from me. It worked with tdfx...;-) What about stex3d? Does it work on r100/mga? -Dieter --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 453] New: manywin (from Mesa) doesn't update all windows w/direct rendering
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=453 Summary: manywin (from Mesa) doesn't update all windows w/direct rendering Product: Drivers Version: 4.3 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ATI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] When using direct rendering, the manywin application from Mesa does not update all windows. On the last window is animated. If the -s option to manywin is used, all windows are correctly updated. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9200 tester available
On Wed, 2003-07-02 at 12:57, Rupert Levene wrote: On Mon, Jun 30, 2003 at 04:19:09PM +0200, Michel Dänzer wrote: On Fri, 2003-06-27 at 21:05, Rupert Levene wrote: 2. In noegnud, if there is text in a window that is partially off-screen, the text is invisible. When the window is moved so that it is all on-screen the text reappears. (This _could_ be a bug in noegnud). Indeed, the driver shouldn't particularly care about this. Anyway, do you have a procedure to reproduce the problem? I didn't notice anything obvious on a quick try. Yes: hit f10 and drag the window off various edges of the screen. See http://levene.dyndns.org/invisible-text/ for screenshots. Also, there's no text in the 'console' pane at the top unless that is dragged out to fill the whole screen, which I'd guess is a manifestation of the same problem. Indeed. I have a feeling this isn't a driver problem either, but it could be. Can you ask other noegnud players to try and reproduce the problem with different drivers, e.g. the proprietary nVidia drivers? PS: http://levene.dyndns.org/invisible-text/normal.png does show a driver problem - the lighting is wrong with HW TCL - but you didn't report that... ;) -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 453] manywin (from Mesa) doesn't update all windows w/direct rendering
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=453 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Platform||All --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Stange multi-context problem in Radeon driver (andprobably others)
Dieter Nützel wrote:
Am Mittwoch, 2. Juli 2003 22:26 schrieb Ian Romanick:
Dieter Nützel wrote:
Some xdemos apps show it, too.
wincopy isn't working.
Mesa/xdemos ./wincopy
glXMakeContextCurrent failed in Redraw()
glXMakeContextCurrent failed in Redraw()
glXMakeContextCurrent failed in Redraw()
[-]
wincopy doesn't work because it's trying to use an unsupported GLX 1.3
call. glXMakeContextCurrent glXMakeCurrentReadSGI are the functions
that I'm trying to add support for. On my system with my patches,
wincopy works fairly well. :)
I want Mesa 5.1 (5.2), now ;-)
You won't have to wait that long. SGI_make_current_read will probably
be supported for indirect contexts tomorrow. I think I'm going to go
ahead and commit all of the device independent parts tomorrow, and
commit the device dependent parts as they are fixed.
manywin update only the lasted created window in hardware mode (n=28).
All additional windows (indirect mode) would be updated simultaneously.
Sometimes it locks X after the second try.
Could you try the attached patch? It should fix the problem for both
r100 and r200 based cards. I had to hand-edit the patch to remove some
other changes from glxcmds.c, so let me know if you have any problems
getting it to apply cleanly. Hopefully this will be the *last time*
that I have to modify GetDRIDrawable! :)
*This* might very well be related. I notice that if manywin is run with
'-s' it works fine. Is there a bug filed, either in the DRI database or
the XFree86 database, for this?
No? --- Not from me. It worked with tdfx...;-)
Okay. I created one in the XFree86 database. It's bug #453.
Index: lib/GL/glx/glxcmds.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/glx/glxcmds.c,v
retrieving revision 1.44
diff -u -d -r1.44 glxcmds.c
--- lib/GL/glx/glxcmds.c25 Jun 2003 00:39:58 - 1.44
+++ lib/GL/glx/glxcmds.c3 Jul 2003 01:01:33 -
@@ -164,31 +164,36 @@
*/
static __DRIdrawable *
-GetDRIDrawable( GLXContext gc, GLXDrawable drawable )
+GetDRIDrawable( Display *dpy, GLXDrawable drawable )
{
#ifdef GLX_DIRECT_RENDERING
__DRIdrawable *pdraw = NULL;
+__GLXdisplayPrivate *priv = __glXInitialize(dpy);
+unsigned i;
+const unsigned screen_count = ScreenCount(dpy);
-if ((gc != NULL) gc-isDirect) {
- __GLXdisplayPrivate *priv = __glXInitialize(gc-currentDpy);
- if (priv-driDisplay.private) {
- __GLXscreenConfigs *psc = priv-screenConfigs[gc-screen];
+if (priv-driDisplay.private) {
+ for ( i = 0 ; i screen_count ; i++ ) {
+ __GLXscreenConfigs *psc = priv-screenConfigs[i];
if (psc psc-driScreen.private) {
/*
** getDrawable returning NULL implies that the drawable is
** not bound to a direct rendering context.
*/
- pdraw = (*psc-driScreen.getDrawable)(gc-currentDpy,
+ pdraw = (*psc-driScreen.getDrawable)(dpy,
drawable,
psc-driScreen.private);
+ if ( pdraw != NULL ) {
+ break;
+ }
}
}
}
return pdraw;
#else
-(void) gc;
+(void) dpy;
return NULL;
#endif
}
@@ -694,11 +699,11 @@
void GLX_PREFIX(glXSwapBuffers)(Display *dpy, GLXDrawable drawable)
{
xGLXSwapBuffersReq *req;
-GLXContext gc = __glXGetCurrentContext();
+GLXContext gc;
GLXContextTag tag;
CARD8 opcode;
#ifdef GLX_DIRECT_RENDERING
-__DRIdrawable *pdraw = GetDRIDrawable( gc, drawable );
+__DRIdrawable *pdraw = GetDRIDrawable( dpy, drawable );
if ( pdraw != NULL ) {
(*pdraw-swapBuffers)(dpy, pdraw-private);
@@ -715,7 +720,9 @@
** The calling thread may or may not have a current context. If it
** does, send the context tag so the server can do a flush.
*/
-if ((dpy == gc-currentDpy) (drawable == gc-currentDrawable)) {
+gc = __glXGetCurrentContext();
+if ((gc != NULL) (dpy == gc-currentDpy)
+ ((drawable == gc-currentDrawable) || (drawable == gc-currentReadable)) ) {
tag = gc-currentContextTag;
} else {
tag = 0;
@@ -1921,7 +1928,8 @@
#ifdef GLX_DIRECT_RENDERING
if ( gc-isDirect __glXExtensionBitIsEnabled( SGI_swap_control_bit ) ) {
- __DRIdrawable *pdraw = GetDRIDrawable( gc, gc-currentDrawable );
+ __DRIdrawable *pdraw = GetDRIDrawable( gc-currentDpy,
+gc-currentDrawable );
if ( pdraw != NULL ) {
pdraw-swap_interval = interval;
@@ -1961,7 +1969,8 @@
{
#ifdef GLX_DIRECT_RENDERING
GLXContext gc = __glXGetCurrentContext();
- __DRIdrawable *pdraw = GetDRIDrawable( gc, gc-currentDrawable );
+ __DRIdrawable *pdraw = GetDRIDrawable( gc-currentDpy,
+ gc-currentDrawable
Re: [Dri-devel] Stange multi-context problem in Radeon driver (and probably others)
Am Donnerstag, 3. Juli 2003 03:18 schrieb Ian Romanick:
Dieter Nützel wrote:
Am Mittwoch, 2. Juli 2003 22:26 schrieb Ian Romanick:
Dieter Nützel wrote:
Some xdemos apps show it, too.
wincopy isn't working.
Mesa/xdemos ./wincopy
glXMakeContextCurrent failed in Redraw()
glXMakeContextCurrent failed in Redraw()
glXMakeContextCurrent failed in Redraw()
[-]
wincopy doesn't work because it's trying to use an unsupported GLX 1.3
call. glXMakeContextCurrent glXMakeCurrentReadSGI are the functions
that I'm trying to add support for. On my system with my patches,
wincopy works fairly well. :)
I want Mesa 5.1 (5.2), now ;-)
You won't have to wait that long. SGI_make_current_read will probably
be supported for indirect contexts tomorrow. I think I'm going to go
ahead and commit all of the device independent parts tomorrow, and
commit the device dependent parts as they are fixed.
manywin update only the lasted created window in hardware mode
(n=28). All additional windows (indirect mode) would be updated
simultaneously. Sometimes it locks X after the second try.
Could you try the attached patch? It should fix the problem for both
r100 and r200 based cards. I had to hand-edit the patch to remove some
other changes from glxcmds.c, so let me know if you have any problems
getting it to apply cleanly.
That worked.
Hopefully this will be the *last time*
that I have to modify GetDRIDrawable! :)
But one error:
[-]
_MESA -DUSE_X86_ASMglxcmds.c
glxcmds.c: In function `glXSwapBuffers':
glxcmds.c:725: structure has no member named `currentReadable'
make[5]: *** [glxcmds.o] Error 1
[-]
-if ((dpy == gc-currentDpy) (drawable == gc-currentDrawable)) {
+gc = __glXGetCurrentContext();
+if ((gc != NULL) (dpy == gc-currentDpy)
+ ((drawable == gc-currentDrawable) || (drawable ==
gc-currentReadable)) ) {
[-]
*This* might very well be related. I notice that if manywin is run with
'-s' it works fine. Is there a bug filed, either in the DRI database or
the XFree86 database, for this?
No? --- Not from me. It worked with tdfx...;-)
Okay. I created one in the XFree86 database. It's bug #453.
Thanks!
Dieter
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
