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

[Jerome Glisse]

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.

Cheers,
Jerome