[PATCHES] R600/SI: VI fixes for bit shifts, GS

[Marek Olšák]

On Wed, Jan 28, 2015 at 11:29 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 28.01.2015 07:16, Marek Olšák wrote:
>> Hi,
>>
>> This is another set of fixes for VI. Patches 1-2, 5-6 fix real issues.
>> Patches 3-4, 7-8 are mostly cosmetic. Only patch 1 should fix an issue
>> that is reproducible by piglit.
>>
>> I couldn't test these, because my VI hw is very unstable.
>
> My testing so far on Tonga indicates that either patch 8 of this series
> decreases stability significantly, or it's just very random (sometimes
> not possible to finish a piglit run on several attempts, sometimes
> several successful runs in a row). If it's the former, it only seems to
> happen if the patch in question is applied at boot time. I'll test more
> to see which it is.

Well, your Tonga seems to be a lot more stable than mine. On my
machine, the piglit test counter doesn't even reach number 2000 after
several attempts, which is pretty bad considering there are 26k tests
or so.

>
>> I'll try and test Bonaire tomorrow.
>
> FWIW, no issues with piglit on my Kaveri.

Thanks.

>
>
>> Michel, would you be so kind as to test the first patch whether it
>> fixes the GS hang? Sorry, I'm not able to tell the difference. Please
>> apply patch 1 alone and please don't update your LLVM repo (just in
>> case it uncovers some other bug).
>
> I'm not sure what exactly you meant by the last sentence, but patch 1 on
> top of SVN r227287 does fix piglit
> spec/glsl-1.50/execution/geometry/generate-zero-primitives on my Tonga.

Thanks. The reason I asked you not to update LLVM is that I didn't
know if the hangs were caused by the kernel driver or by the latest
changes in the compiler.

>
> However, I noticed a minor problem with that patch: The code adding
> s_nop instructions seems to run before the code adding s_waitcnt
> instructions, so it unnecessarily adds an s_nop in some cases:
>
>         s_mov_b32 m0, s9                                      ; BEFC0009
>         s_waitcnt vmcnt(0) expcnt(0)                          ; BF8C0700
>         s_nop                                                 ; BF800000
>         s_sendmsg Gs(emit stream 0), [m0]                     ; BF900022
>
> That might be okay until the scheduling hazard recognizer mentioned by
> Matt handles this.

Yeah, I can fix that.

Marek