[Bug 79029] INTEL_DEBUG=shader_time is full of lies
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Sun Jun 15 16:53:26 PDT 2014
https://bugs.freedesktop.org/show_bug.cgi?id=79029
Kenneth Graunke <kenneth at whitecape.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Kenneth Graunke <kenneth at whitecape.org> ---
This should pretty much be fixed by:
commit d0575d98fc595dcc17706dc73d1eb461027ca17a
Author: Kenneth Graunke <kenneth at whitecape.org>
Date: Sat Jun 14 03:53:07 2014 -0700
i965/vec4: Fix dead code elimination for VGRFs of size > 1.
When faced with code such as:
mov vgrf31.0:UD, 960D
mov vgrf31.1:UD, vgrf30.xxxx:UD
The dead code eliminator didn't consider reg_offsets, so it decided that
the second instruction was writing was writing to the same register as
the first one, and eliminated the first one. But they're actually
different registers.
This fixes INTEL_DEBUG=shader_time for vertex shaders. In the above
code, vgrf31.0 represents the offset into the shader_time buffer where
the data should be written, and vgrf31.1 represents the actual time
data. With a completely undefined offset, results were...unexpected.
I think this is probably one of the few cases (maybe only case) where we
generate multiple MOVs to a large VGRF. Normally, we just use them as
texturing results; the other SEND-from-GRF uses a size 1 VGRF.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79029
Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
Reviewed-by: Matt Turner <mattst88 at gmail.com>
Cc: mesa-stable at lists.freedesktop.org
It's at least now giving me data in the same ballpark as the other methods,
though I haven't checked if it's entirely the same. Thankfully it was
something simple.
--
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/20140615/907bdfea/attachment.html>
More information about the intel-3d-bugs
mailing list