On Thu, Sep 6, 2012 at 11:32 AM, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Thu, Sep 6, 2012 at 10:54 AM, Jerome Glisse <j.gli...@gmail.com> wrote: >> On Thu, Sep 6, 2012 at 6:20 AM, Dave Airlie <airl...@gmail.com> wrote: >>> On Thu, Sep 6, 2012 at 5:21 PM, Philipp Klaus Krause <p...@spth.de> wrote: >>>> On 06.09.2012 07:35, j.gli...@gmail.com wrote: >>>>> From: Jerome Glisse <jgli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
