[Mesa-dev] R600g : rejected cs and etqw corruption with - implement wait-free buffer transfer for DISCARD_RANGE

[Andy Furniss]

Andy Furniss wrote:
> Andy Furniss wrote:
>> Andy Furniss wrote:
>>> Marek Olšák wrote:
>>>> Hi Andy,
>>>>
>>>> this should be fixed by the commit:
>>>>
>>>> commit c3c83af380d703cdc24475bd39baa1722c333b44
>>>> Author: Marek Olšák <maraeo at gmail.com>
>>>> Date:   Wed Jul 18 18:33:37 2012 +0200
>>>>
>>>>      r600g: setup streamout before calling last r600_need_cs_space
>>>> before drawing
>>>>
>>>> Please let me know if you still have any issue.
>>>
>>> That has fixed this issue - nice perf boost with your latest commits :-)
>>>
>>> Unfortunately after running for a while I managed to trigger the issue I
>>> previously reported.
>>>
>>> It only took 10 mins - after the fix following the last report I ran for
>>> an hour and then next day 45 mins without triggering it.
>>>
>>> r600_pipe.h:743:r600_write_context_reg_seq: Assertion `cs->cdw+2+num <=
>>> (16 * 1024)' failed.
>>
>> I can still 100% reproduce this - one thing I maybe didn't notice before
>> because I just checked dmesg (or maybe it just didn't happen) is that in
>> addition to the corruption followed by the above assert, there are
>> lots of
>>
>> radeon: The kernel rejected CS, see dmesg for more information
>>
>> But there is nothing in dmesg.
>
> Testing with today's Mesa a slight difference in that it took a lot
> longer than normal to assert after the corruption started and I see on
> stderr in addition to kernel rejected CS
>
> EE r600_pipe.c:79 r600_create_fence - r600: too many concurrent fences
>
> still nothing in dmesg.

Looks like this is fixed with today's commits. I ran it for an hour.

Perf has gone down to where it used to be -20ish%.