search for: st_cb_clear

When trying out the Gallium3D NV50 driver (curiosity) with a small OpenGL program that renders 2 rotating triangles partially occluding each other I noticed that depth buffer clearing by rendering a quad (st_cb_clear.c/clear_with_quad) didn't work properly. I found this was because the rasterizer state that is set by clear_with_quad has bypass_vs_clip_and_viewport = 1 which would only be commited if the viewport was marked dirty, which it isn't when only binding a new rasterizer state. I let the depth...

...ntry=1, z=1, s0=s0 at entry=0, t0=t0 at entry=0, s1=s1 at entry=0, t1=t1 at entry=0, color=color at entry=0x1dc781c, num_instances=num_instances at entry=1) at state_tracker/st_draw.c:489 #9 0x00007f5be03b2087 in clear_with_quad (clear_buffers=<optimized out>, ctx=0x1dc5d60) at state_tracker/st_cb_clear.c:297 #10 0x00007f5be03b2087 in st_Clear (ctx=0x1dc5d60, mask=16) at state_tracker/st_cb_clear.c:475 #11 0x00007f5bf0310811 in _cogl_framebuffer_gl_clear (framebuffer=0x1ee3000, buffers=<optimized out>, red=<optimized out>, green=<optimized out>, blue=<optimized out>, alpha=...

...by 0x7B6881F: copy_framebuffer_state (cso_context.c:781) ==5322== by 0x7B68962: cso_set_framebuffer (cso_context.c:791) ==5322== by 0x7AB5441: update_framebuffer_state (st_atom_framebuffer.c:147) ==5322== by 0x7AB3E41: st_validate_state (st_atom.c:188) ==5322== by 0x7ABDA2E: st_clear (st_cb_clear.c:517) ==5322== by 0x7B0BED5: _mesa_Clear (clear.c:177) ==5322== by 0x47F25FA: glClear (glapitemp.h:1100) ==5322== by 0x8048CE9: Draw (tri.c:72) ==5322== by 0x46F2C53: processWindowWorkList (glut_event.c:1302) ==5322== by 0x46F2D39: __glutProcessWindowWorkLists (glut_event.c:1354) ==...

Hi ! I think src and dst starting positions got mixed up in nv50_transfer_rect_m2mf, there's a diff at the bottom of this message. This came up when trying to make the gearbox demo run correctly, but this change alone doesn't fix it. The mesa state tracker in st_cb_clear.c assumes Y_0_TOP when clearing the color buffer, but that seems to be wrong for NV50. When bypassing the viewport transformation, vertex position (0, 0) becomes bottom left, and not top. This is a problem in several other places. In st_atom_viewport.c, because of Y_0_TOP we get inverted viewport p...

https://bugs.freedesktop.org/show_bug.cgi?id=102349 Bug ID: 102349 Summary: nv4x crashing with plasmashell - gdb log included Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: Driver/nouveau