[Mesa-dev] [PATCH 2/2] i965/fs: Only apply Gen4 work-arounds if regs_written > 1.

[Kenneth Graunke]

On Tuesday, January 13, 2015 03:40:32 PM Matt Turner wrote:
> On Tue, Jan 13, 2015 at 3:35 PM, Matt Turner <mattst88 at gmail.com> wrote:
> > Otherwise, we would have necessarily read the results or eliminated the
> > dead SEND. In either case, no work around is necessary.
> >
> > Noticed when debugging the problem the previous patch fixed that any
> > time we hit a math instruction, we'd walk through subsequent
> > instructions, and of course each time discover that its result was in
> > fact used.
> > ---
> 
> I was thinking through the pre-send dependency work around:
> 
> /**
>  * Implements this workaround for the original 965:
>  *
>  *     "[DevBW, DevCL] Implementation Restrictions: As the hardware does not
>  *      check for post destination dependencies on this instruction, software
>  *      must ensure that there is no destination hazard for the case of ‘write
>  *      followed by a posted write’ shown in the following example.
>  *
>  *      1. mov r3 0
>  *      2. send r3.xy <rest of send instruction>
>  *      3. mov r2 r3
>  *
>  *      Due to no post-destination dependency check on the ‘send’, the above
>  *      code sequence could have two instructions (1 and 2) in flight at the
>  *      same time that both consider ‘r3’ as the target of their final writes.
>  */
> 
> While this is a hardware problem or something, isn't it impossible for
> us to hit? If the first MOV's results weren't read, we would have dead
> code eliminated it. If they were read (necessarily between it and the
> SEND), we would never have both instructions in flight at once.

It's definitely pretty rare, though I'm not certain I can say it never
happens.  If you care to look into it further, I found the bug report
which spawned this code:

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

The attachment contains a sample application which I managed to compile via:
$ for file in *.h; do moc-qt4 $file > moc-$(basename $file .h).cpp; done
$ g++ -Wall -g $(pkg-config --libs --cflags QtCore QtGui QtOpenGL gl) *.cpp

It would be great if we could make a Piglit test.

> Is there some case where we could realistically hit this problem?
> Maybe with control flow?
> 
> I would like to mention that neither of these work arounds are
> implemented in the vec4 backend.

That's true, but they probably should be.  We originally reproduced this bug
with texturing instructions, which at the time were only supported in the FS.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150117/7c49c0e7/attachment-0001.sig>