[Bug 92623]=?UTF-8?Q?=20Reproducible=20GPU=20hang=20on=20Intel=20HD5500=20=E2=80=94=20ecode=208?=:0:0x84df3c1c

[bugzilla-daemon at freedesktop.org]

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

--- Comment #12 from Pierre Bourdon <delroth at gmail.com> ---
So I've been looking at this for the past N hours in the hope of learning more
about how Mesa and i965 work (and I've already learned a lot \o/). I noticed
something that I find interesting though. It might be completely normal and
uninteresting, but if it is I'm curious about the explanation.

I randomly figured out that adding BRW_NEW_FRAGMENT_PROGRAM to the dirty bits
that trigger upload_wm_state and gen8_emit_pma_stall_workaround works around
the crash bug. But both of these should already trigger on BRW_NEW_FS_PROG_DATA
being dirty.

In what condition should BRW_NEW_FRAGMENT_PROGRAM be dirty but not
BRW_NEW_FS_PROG_DATA? It sounds like getting a new fragment program should in
practice always come with a new prog_data as well?

-- 
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/20151028/0e4cdc45/attachment.html>