[Bug 81649] New: Difference with software render and without (clipping vertex?)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=81649

          Priority: medium
            Bug ID: 81649
          Assignee: idr at freedesktop.org
           Summary: Difference with software render and without (clipping
                    vertex?)
        QA Contact: intel-3d-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: fevrier.dorian at yahoo.fr
          Hardware: x86 (IA32)
            Status: NEW
           Version: 8.0
         Component: Drivers/DRI/i965
           Product: Mesa

Created attachment 103299
  --> https://bugs.freedesktop.org/attachment.cgi?id=103299&action=edit
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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20140722/b2b7a43f/attachment.html>