Re: glx failing
On Fri, Nov 14, 2003 at 12:40:55PM +0100, Frank Gießler wrote: >David Dawes wrote: >> >> The patch below fixes the problem. The command lengths for several >> rendering requests were getting set incorrectly because of mis-ordered >> variable initialisations. I'm committing it now. >> >> Index: g_render.c >> === >> RCS file: /home/x-cvs/xc/lib/GL/glx/g_render.c,v >> retrieving revision 1.5 >> diff -u -r1.5 g_render.c > >I'm still getting the same error with some Mesa demos (cubemap, drawpix, fire, gamma, >gloss, >and more). Others work (bounce, clearspd, gears, geartrain, and more). > >The patch above only changes g_render.c, what about render2.c and renderpix.c? In >them, there >also some places that look very similar to the ones changed in g_render.c. Yes, it looks like the same problem is in other places too. I called it a night after getting glxgears running. I'll commit the remaining fixes today. >Just a thought... Thanks. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glx failing
David Dawes wrote: The patch below fixes the problem. The command lengths for several rendering requests were getting set incorrectly because of mis-ordered variable initialisations. I'm committing it now. Index: g_render.c === RCS file: /home/x-cvs/xc/lib/GL/glx/g_render.c,v retrieving revision 1.5 diff -u -r1.5 g_render.c I'm still getting the same error with some Mesa demos (cubemap, drawpix, fire, gamma, gloss, and more). Others work (bounce, clearspd, gears, geartrain, and more). The patch above only changes g_render.c, what about render2.c and renderpix.c? In them, there also some places that look very similar to the ones changed in g_render.c. Just a thought... Regards, Frank. -- Frank Giessler Klinikum der Universitaet Jena Tel.: +49-3641-9 32 57 80 Biomagnetisches Zentrum Fax : +49-3641-9 32 57 72 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glx failing
On Thu, Nov 13, 2003 at 04:40:30PM -0800, Torrey Lyons wrote:
>At 10:01 AM -0800 11/10/03, Ian Romanick wrote:
>>Frank Gießler wrote:
>>>with my current CVS snapshot (Changelog up to
>>>#530), glxgears gives me the following at
>>>startup:
>>>
>>>X Error of failed request: BadLength (poly
>>>request too large or internal Xlib length error)
>>> Major opcode of failed request: 144 (GLX)
>>> Minor opcode of failed request: 1 (X_GLXRender)
>>> Serial number of failed request: 22
>>> Current serial number in output stream: 23
>>>
>>>This used to work before. I've seen this on
>>>both OS/2 and SuSE Linux 8.2 (XFree CVS built
>>>without DRI). Any idea what this means and/or
>>>where I should look?
>>
>>Can you give any details to help reproduce this
>>error? There is a reported bug in this area,
>>but I thought that it was fixed. Your
>>XF86Config would also be useful.
>>
>>http://bugs.xfree86.org/show_bug.cgi?id=439
>
>I'll put this on Bugzilla as well, but it is
>quite easy on XDarwin to reproduce this error.
>GLX fails consistently with indirect rendering
>and worked properly in 4.3.0. Only direct
>rendering works now.
>
>[65:~] torrey% glxgears
>2006 frames in 5.0 seconds = 401.200 FPS
>^C
>[65:~] torrey% setenv LIBGL_ALWAYS_INDIRECT 1
>[65:~] torrey% glxgears
>X Error of failed request: BadLength (poly
>request too large or internal Xlib length error)
> Major opcode of failed request: 151 (GLX)
> Minor opcode of failed request: 1 (X_GLXRender)
> Serial number of failed request: 22
> Current serial number in output stream: 23
>
>This bug is still present in the top of the tree.
The patch below fixes the problem. The command lengths for several
rendering requests were getting set incorrectly because of mis-ordered
variable initialisations. I'm committing it now.
Index: g_render.c
===
RCS file: /home/x-cvs/xc/lib/GL/glx/g_render.c,v
retrieving revision 1.5
diff -u -r1.5 g_render.c
--- g_render.c 28 Sep 2003 20:15:01 - 1.5
+++ g_render.c 14 Nov 2003 04:17:00 -
@@ -1639,8 +1639,8 @@
void glFogfv(GLenum pname, const GLfloat *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glFogfv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glFogfv_size(pname);
cmdlen = 8+compsize*4;
__GLX_BEGIN(X_GLrop_Fogfv,cmdlen);
__GLX_PUT_LONG(4,pname);
@@ -1661,8 +1661,8 @@
void glFogiv(GLenum pname, const GLint *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glFogiv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glFogiv_size(pname);
cmdlen = 8+compsize*4;
__GLX_BEGIN(X_GLrop_Fogiv,cmdlen);
__GLX_PUT_LONG(4,pname);
@@ -1703,8 +1703,8 @@
void glLightfv(GLenum light, GLenum pname, const GLfloat *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glLightfv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glLightfv_size(pname);
cmdlen = 12+compsize*4;
__GLX_BEGIN(X_GLrop_Lightfv,cmdlen);
__GLX_PUT_LONG(4,light);
@@ -1727,8 +1727,8 @@
void glLightiv(GLenum light, GLenum pname, const GLint *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glLightiv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glLightiv_size(pname);
cmdlen = 12+compsize*4;
__GLX_BEGIN(X_GLrop_Lightiv,cmdlen);
__GLX_PUT_LONG(4,light);
@@ -1750,8 +1750,8 @@
void glLightModelfv(GLenum pname, const GLfloat *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glLightModelfv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glLightModelfv_size(pname);
cmdlen = 8+compsize*4;
__GLX_BEGIN(X_GLrop_LightModelfv,cmdlen);
__GLX_PUT_LONG(4,pname);
@@ -1772,8 +1772,8 @@
void glLightModeliv(GLenum pname, const GLint *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glLightModeliv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glLightModeliv_size(pname);
cmdlen = 8+compsize*4;
__GLX_BEGIN(X_GLrop_LightModeliv,cmdlen);
__GLX_PUT_LONG(4,pname);
@@ -1814,8 +1814,8 @@
void glMaterialfv(GLenum face, GLenum pname, const GLfloat *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glMaterialfv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glMaterialfv_size(pname);
cmdlen = 12+compsize*4;
__GLX_BEGIN(X_GLrop_Materialfv,cmdlen);
__GLX_PUT_LONG(4,face);
@@ -1838,8 +1838,8 @@
void glMaterialiv(GLenum face, GLenum pname, const GLint *params)
{
__GLX_DECLARE_VARIABLES();
- compsize = __glMaterialiv_size(pname);
__GLX_LOAD_VARIABLES();
+ compsize = __glMaterialiv_size(pname);
cmdlen = 12+compsize*4;
__GLX_BEGIN(X_GLrop_Materialiv,cmdlen);
__GLX_PUT_LONG(4,face);
@@ -1902,8 +1902,8 @@
void glTexParameterfv(GLenum t
Re: glx failing
At 10:01 AM -0800 11/10/03, Ian Romanick wrote: Frank Gießler wrote: with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 (XFree CVS built without DRI). Any idea what this means and/or where I should look? Can you give any details to help reproduce this error? There is a reported bug in this area, but I thought that it was fixed. Your XF86Config would also be useful. http://bugs.xfree86.org/show_bug.cgi?id=439 I'll put this on Bugzilla as well, but it is quite easy on XDarwin to reproduce this error. GLX fails consistently with indirect rendering and worked properly in 4.3.0. Only direct rendering works now. [65:~] torrey% glxgears 2006 frames in 5.0 seconds = 401.200 FPS ^C [65:~] torrey% setenv LIBGL_ALWAYS_INDIRECT 1 [65:~] torrey% glxgears X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This bug is still present in the top of the tree. --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glx failing
Zitat von Ian Romanick <[EMAIL PROTECTED]>: > Frank Gießler wrote: > > with my current CVS snapshot (Changelog up to #530), glxgears gives me > > the following at startup: > > > > X Error of failed request: BadLength (poly request too large or > > internal Xlib length error) > > Major opcode of failed request: 144 (GLX) > > Minor opcode of failed request: 1 (X_GLXRender) > > Serial number of failed request: 22 > > Current serial number in output stream: 23 > > > > This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 > > (XFree CVS built without DRI). Any idea what this means and/or where I > > should look? > > Can you give any details to help reproduce this error? There is a > reported bug in this area, but I thought that it was fixed. Your > XF86Config would also be useful. On Linux I simply build the abovementioned version with 'make World' with this host.def in xc/config/cf: #define NormalLibFont YES #define SharedLibFont NO #define BuildDPSLibrary YES #define XprtServer YES #define XnestServer YES #define XVirtualFramebufferServer YES #define BuildFonts NO /* #define BuildCIDFonts YES */ #define BuildDocs NO #define BuildServer YES #define BuildGlxExt YES #define BuildOSMesaLib YES #define ProjectRoot /XFree86 #define HasMMXSupport YES #define Has3DNowSupport YES #define HasKatmaiSupport YES #define HasSSESupport YES #define BuildXF86DRI NO Then 'make install', start the server (as root) with cd /XFree86/bin setenv DISPLAY :1 setenv LD_LIBRARY_PATH /XFree86/lib ./xinit /XFree86/bin/xterm -- /XFree86/bin/XFree86 :1 -xf86config /etc/X11/XF86Config.test After the xterm comes up, start 'glxgears' -> bang. I'll send you the configfile as PM. Frank. -- Frank Giessler Klinikum der Universitaet Jena Tel.: +49-3641-9 32 57 80 Biomagnetisches Zentrum Fax : +49-3641-9 32 57 72 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glx failing
Frank Gießler wrote: with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 (XFree CVS built without DRI). Any idea what this means and/or where I should look? Can you give any details to help reproduce this error? There is a reported bug in this area, but I thought that it was fixed. Your XF86Config would also be useful. http://bugs.xfree86.org/show_bug.cgi?id=439 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
glx failing
Hi all, with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 22 Current serial number in output stream: 23 This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 (XFree CVS built without DRI). Any idea what this means and/or where I should look? Thanks, Frank. -- Frank Giessler Klinikum der Universitaet Jena Tel.: +49-3641-9 32 57 80 Biomagnetisches Zentrum Fax : +49-3641-9 32 57 72 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
