On Tuesday, January 13, 2015 03:40:32 PM Matt Turner wrote: > On Tue, Jan 13, 2015 at 3:35 PM, Matt Turner <matts...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
