[Mesa-dev] [PATCH] r600g: order atom emission

[Christian König]

On 06.09.2012 18:06, Jerome Glisse wrote:
> On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
>> On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse <j.glisse at gmail.com> wrote:
>>> On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie <airlied at gmail.com> wrote:
>>>> On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause <pkk at spth.de> wrote:
>>>>> On 06.09.2012 07:35, j.glisse at gmail.com wrote:
>>>>>> From: Jerome Glisse <jglisse at redhat.com>
>>>>>>
>>>>>> To avoid GPU lockup registers must be emited in a specific order
>>>>>> (no kidding ...). This patch rework atom emission so order in which
>>>>>> atom are emited in respect to each other is always the same. We
>>>>>> don't have any informations on what is the correct order so order
>>>>>> will need to be infered from fglrx command stream.
>>>>> Shouldn't this be stated in comments, so the next person who comes along
>>>>> and makes a change in this code doesn't inadvertently change the order?
>>>> Also a comment on what ordering matters most, like I suspect this is
>>>> just hiding a real issue.
>>>>
>>>> Dave.
>>> No it's not hiding an issue, afaict it's how the hw works. The hw do
>>> what some amd document call states validations. So here is how i
>>> understand how things happen and i can be completely wrong. Hw process
>>> register write in order it receive them and to avoid postponing state
>>> validation the hw do state validation while processing register. That
>>> means if writing register A trigger state validation that use some
>>> field of register B the hw might not redo state validation when
>>> register B is latter written. ie only some register trigger the state
>>> validation no matter on what they depends on. I believe state
>>> validation is only use as pipeline optimization by the hw, so the hw
>>> knows it can take some short cut. But in some rare case if short cut
>>> are taken for wrong reasons we end up in GPU lockup.
>>>
>>> No matter if my guess is right or wrong, i know for a fact that
>>> register order is important in some situation, that's the hard bottom
>>> line, no matter what is the reasons inside the hw.
>>>
>>> This patch is far from having all the order right, it's just a first
>>> step, i am atomizing everything and it's what needed to go forward
>>> without regression.
>> I've talked to the internal hw and sw guys and they said there isn't
>> any specific ordering required and the closed driver doesn't impose
>> any specific order.  The pipeline doesn't get kicked off until a draw
>> command is issued, so I don't see why the state update order would
>> matter.  It's possible there are subtle ordering requirements and the
>> closed driver just happened to get it right.  There are dependencies
>> and hw bug workarounds however.  E.g., some blocks snoop registers
>> from other blocks so you need to make sure those dependant registers
>> have been initialized before drawing.  I don't know if it's the
>> ordering so much as making sure we emit all the necessary state when
>> needed.  The closed driver tends to update a lot more state the is
>> minimally required for a lot of things.  That said, it probably
>> wouldn't hurt to mirror the closed driver more closely.
>>
>> Alex
>>
> Yeah it's possible that it's also related to some register need to be
> re-emitted, i often see that fglrx is re-emitting some register even
> if it emitted it with same value just before and some register are
> emitted several time around other register block.
>
> Anyhow this patch is a first step to atomize everything and match
> fglrx register pattern more closely.

I remember reading something in our internal HW bugtracker that 
sometimes you need to set a register twice for a certain workaround, but 
don't remember what it was exactly.

Anyway, I also think that having a determinable order of setting the 
register is a good idea.

Christian.

>
> Cheers,
> Jerome
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>