On Tue, Sep 11, 2012 at 3:00 PM, Jerome Glisse <j.gli...@gmail.com> wrote: > On Tue, Sep 11, 2012 at 2:29 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Tue, Sep 11, 2012 at 7:41 PM, Jerome Glisse <j.gli...@gmail.com> wrote: >>> On Tue, Sep 11, 2012 at 1:10 PM, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
