Created attachment 103299 [details]
Without LIBGL_ALWAYS_SOFTWARE

Hi, I'm currently working on mupen64plus rice video plugin.

I have an intel chipset:

Tungsten Graphics, Inc - Mesa DRI Intel(R) 965GM x86/MMX/SSE2 : 2.1 Mesa 8.0.4

After moving the plugin from a fixed OpenGL pipeline to a GLSL one, I have some vertex clipping problems:

http://i.imgur.com/ltMZSpG.png

After some investigation, I realize I shoud try using this to help me to know if it's a programming problem or a driver problem:

export LIBGL_ALWAYS_SOFTWARE=1

And there is no more face clipped and everything work as except.

I've found this bug: https://bugs.freedesktop.org/show_bug.cgi?id=64668

Paul suggest to add this to the shader:

gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex;

And I guess there is an important point: The vertex projection transform is done on the CPU side. The reason is that N64 apply "current matrix" (where "current" is a model matrix stack * projection matrix stack) at the moment where the vertex is provided. So you really have this "gl_ModelViewMatrix". Anyway, adding this to the vertex shader doesn't solve the problem so maybe this is not related at all. Same for the example code provided in the linked bug (64668) it clip what ever LIBGL_ALWAYS_SOFTWARE is set or not. So once again, it's maybe not related.

Anyway, the fact it works in software (LIBGL_ALWAYS_SOFTWARE) make me realize the current code is supposed to work but maybe just fail on the 965GM chipset.

FYI, whe I define LIBGL_ALWAYS_SOFTWARE I guet this OpenGL string:

VMware, Inc. - Gallium 0.4 on llvmpipe (LLVM 0x300) : 2.1 Mesa 8.0.4


It's hard to reproduce the bug but I probide the ".trace" for qapitrace: https://github.com/apitrace/apitrace. If you open it on 965GM without LIBGL_ALWAYS_SOFTWARE and trace the frame 4 you will see the bug (image 001). If you define LIBGL_ALWAYS_SOFTWARE, run qaptitrace and trace the frame 4 you will see what is expected (image 002).

If you have any workaround to share I would really love that. :)

Best,

Dorian