Bug 5002

There is currently no GLX protocol defined for ARB_vertex_buffer_object.  There
are two opcodes that can be used for glDrawArrays, but, other than the opcode
number being different, the protocol is identical.  I suspect that Nvidia's
server-side GLX code, like most, supports both.

Are you able to reproduce this bug when not using glInterleavedArrays (as in bug
#5001)?  My best guess is that the problem you identified in that bug is the
root cause here.

I can reproduce this bug without using glInterleavedArrays() and just use
glVertexPointer() and friends.  There's only one section of our code that uses
InterleavedArrays(), even if i turn that off (ifdef it out), I still get a blank
window.  That's why I decided to file this as a separate bug.

btw, I grabbed a knoppix cd from a friend.  He said it was kinda old (knoppix
3.7).  It's running XFree86 4.3.0.1 with glxinfo reporting 1.3 Mesa 4.0.4 for
the version string.

With my display set to the knoppix machine and enable InterleavedArrays, I get
some glx error saying the request is too large (we do have like 4,000 vertices
in that InterleavedArray call).

If I disable InterleavedArrays, I get a:

X Error of failed request:  GLXBadRenderRequest
  Major opcode of failed request:  144 (GLX)
  Minor opcode of failed request:  1 (X_GLXRender)
  Serial number of failed request:  187
  Current serial number in output stream:  189

haven't narrowed down why that is yet.  Not sure I want to spend time on it
right now.  I care more about making sure things display on the nvidia machine.

If I keep InterleavedArrays disabled and set LIBGL_NO_DRAWARRAYS=1, everything
renders fine on the knoppix machine.

Are you running the app from a big-endian system?  I have filed bug 5911
regarding a byte-swapping problem in the Xorg server for glDrawArrays.

Yes, I am running from a big-endian machine and displaying onto a little endian
machine.

Created attachment 6671 [details]
Small glut program that causes the GLXBadRenderRequest

Hi.  I ran into a similar problem.  I am running the program on an Ubuntu 6.06
machine and displaying to a debian "sarge"-based machine.  Both are x86
machines running inside vmware, so there are no endian issues and no NVIDIA
closed-source drivers.

As another commenter noted, setting LIBGL_NO_DRAWARRAYS=1 conceals the problem.


The Ubuntu system (running "glt") has "xserver-xorg 7.0.0-0ubuntu4" and
"libgl1-mesa 6.4.1-0ubuntu8"

The debian system (used as the DISPLAY) has "xserver-xfree86
4.3.0.dfsg.1-14sarge1" and "xlibmesa-gl-dev 4.3.0.dfsg.1-14sarge1"

Created attachment 33195 [details]
draws an empty window instead a quad

Hello,

seems I hit the same problem.
(3 years and a few month later its still present. :)

I added my demo attachment.

The problematic code is:

  // vertex test
  glEnableClientState(GL_VERTEX_ARRAY);
  glVertexPointer(3,GL_FLOAT,0,vertices);
  glDrawArrays(GL_QUADS,0,4);
  glDisableClientState(GL_VERTEX_ARRAY);

This only draws an empty window.

setting LIBGL_NO_DRAWARRAYS=1 fixes the problem for me.
The latest nvidia driver which worked was:

-173.14

The first one which didnt work for me was:(there may be earlier drivers)

-185.18

This is still true for the current linux beta driver:

-195.30

I have posted this to the mesa-devel mailinglist with the subject:

"mesa / nvidia indirect GLX question (OpenSuSE 11.1)"

This is the posting:

http://sourceforge.net/mailarchive/forum.php?thread_name=4B700921.504%40itwm.fraunhofer.de&forum_name=mesa3d-dev

and the reply:
http://sourceforge.net/mailarchive/forum.php?thread_name=4B705700.2000406%40freedesktop.org&forum_name=mesa3d-dev

regards,

Martin

I also keep running into this problem with workstations running NVIDIA drivers > 180.  Try running Googleearth from a remote server for example..

Some people are getting around it by using an old NVIDIA driver or by copying the proprietary NVIDIA lib to the server and replacing the Mesa lib. 

In my case, I am setting LIBGL_NO_DRAWARRAYS=1 on the server before launching the application which works but is really a workaround rather than a solution.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/953.