[Mesa-dev] [PATCH 19/19] r600g: convert the remnants of VGT state into immediate register writes

Jerome Glisse j.glisse at gmail.com
Tue Sep 11 12:24:59 PDT 2012


On Tue, Sep 11, 2012 at 3:00 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
>>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> Please provide information about the GPU and the test which locks up. I'd
>>>> like to reproduce it. Also please explain what's the cause of the
>>>> lockup if you know it (which registers are not emitted in the correct
>>>> order and how it can fixed).
>>>>
>>>> Marek
>>>>
>>>
>>> For instance
>>> http://people.freedesktop.org/~glisse/registerposition/lockup-longprim.sh
>>>
>>> will lockup probably any r6xx/r7xx (definitely rv670 & rv770)
>>>
>>> I know that the whole vgt register order is picky and that most of
>>> them need to be emitted before ta_cntl_aux and before cb/db. But the
>>> ordering relative to pa is kind of weird and moving when looking at
>>> fglrx.
>>
>> I tested RS880, which is very similar to RV670, and it didn't hang. I
>> can test RV670 later and if there's any issue, I'll fix it. I'd like
>> this patch to be fixed instead of dropped, that's why I'm asking and I
>> still haven't got a definitive answer how to change the patch, so that
>> it can be pushed. Besides that...
>>
>> Has it ever occured to you that the register ordering is changing in
>> fglrx, because the ordering doesn't matter at all, just like Alex
>> said, and the closed driver devs wrote it that way because they didn't
>> care about the ordering either?
>>
>> I think the lockups you are seeing on r600-r700 are actually caused by
>> something entirely different and it confuses you. See this thread from
>> the comment #9 onwards:
>> https://bugs.freedesktop.org/show_bug.cgi?id=50655#c9
>>
>> Marek
>
> It's simple without that patch no lockup, with it lockup all the time.
> It's just a hard fact, i am not confused about anything, i know for a
> fact that reg grouping/order matter somehow. I run several automated
> tools that compare register value at draw call time btw r600g and
> fglrx while doing hyperz and there was no difference at all, down the
> last bit. One was locking up the other not.
>
> Cheers,
> Jerome

And if your curious r600g command stream good and bad and diff btw bad
and good are at:
http://people.freedesktop.org/~glisse/longprim/

If it's the bad that is emited before the fbo-stencil test then it
lockup, if it's the good one then no lockup.

Cheers,
Jerome


More information about the mesa-dev mailing list