[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:00:10 PDT 2012


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


More information about the mesa-dev mailing list