---
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > So about this locking piglit test (depthstencil-render-miplevels 146
> > > s=3Dz24_s8_d=3Dz32f_s8), I've been able to track it down to:
> > > line 218: piglit_report_result(PIGLIT_SKIP);
> >=20
> > How did you determine that? It's weird, I wouldn't expect a skipped tes=
t to
> > produce any actual GPU rendering.
>=20
> I used gdb and step into the code until it locked. It gets out at level 0,
> after going through:
>=20
> /**
> * Attach the proper miplevel of each texture to the framebuffer
> */
> void
> set_up_framebuffer_for_miplevel(int level)...
>=20
> Before this call, there is a framebuffer initialization:
> GLuint fbo;
> glGenFramebuffers(1, &fbo);
> glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
> glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
>=20
> for (int level =3D 0; level <=3D max_miplevel; ++level) {
> set_up_framebuffer_for_miplevel(level);
It seems that with latest mesa, drm, xf86 and kernel 3.7.0-rc7-71633-g3b6b5=
9b
from drm-next, it doesn't fail on this test anymore. It does lock however o=
n a
different one. I'll debug it and see where it locks.
--=20
You are receiving this mail because:
You are the assignee for the bug.
--1355693510.41aBFA0.11661
Date: Sun, 16 Dec 2012 21:31:50 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Commen=
t # 27
on bug 53111<=
/a>
from Alexandre Demers
(In reply to comment #=
21)
> (In reply to comment #20)
> > (In reply to comment #19<=
/a>)
> > > So about this locking piglit test (depthstencil-render-miple=
vels 146
> > > s=3Dz24_s8_d=3Dz32f_s8), I've been able to track it down to:
> > > line 218: piglit_report_result(PIGLIT_SKIP);
> >=20
> > How did you determine that? It's weird, I wouldn't expect a skipp=
ed test to
> > produce any actual GPU rendering.
>=20
> I used gdb and step into the code until it locked. It gets out at leve=
l 0,
> after going through:
>=20
> /**
> * Attach the proper miplevel of each texture to the framebuffer
> */
> void
> set_up_framebuffer_for_miplevel(int level)...
>=20
> Before this call, there is a framebuffer initialization:
> GLuint fbo;
> glGenFramebuffers(1, &fbo);
> glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo);
> glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
>=20
> for (int level =3D 0; level <=3D max_miplevel; ++level) {
> set_up_framebuffer_for_miplevel(level);
It seems that with latest mesa, drm, xf86 and kernel 3.7.0-rc7-71633-g3b6b5=
9b
from drm-next, it doesn't fail on this test anymore. It does lock however o=
n a
different one. I'll debug it and see where it locks.
You are receiving this mail because:
=20=20=20=20=20=20
- You are the assignee for the bug.
--1355693510.41aBFA0.11661--
--===============0224055614==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--===============0224055614==--