On Thu, Sep 6, 2012 at 8:32 PM, Dave Airlie <airl...@gmail.com> wrote: > On Fri, Sep 7, 2012 at 10:03 AM, Marek Olšák <mar...@gmail.com> wrote: >> On Fri, Sep 7, 2012 at 12:05 AM, Jerome Glisse <j.gli...@gmail.com> wrote: >>> On Thu, Sep 6, 2012 at 4:10 PM, Marek Olšák <mar...@gmail.com> wrote: >>>> On Thu, Sep 6, 2012 at 8:34 PM, Jerome Glisse <j.gli...@gmail.com> wrote: >>>>> On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák <mar...@gmail.com> wrote: >>>>>> This looks good to me. It's funny to see the r300g architecture being >>>>>> re-implemented in r600g. :) >>>>>> >>>>>> There's one optimization that r300g has that this patch doesn't. r300g >>>>>> keeps the index of the first and the last dirty atom and the loops >>>>>> over the list of atoms look like this: >>>>>> for (i = first_dirty; i <= last_dirty; i++) >>>>>> >>>>>> And after emission: >>>>>> first_dirty = some large number; >>>>>> last_dirty= 0; >>>>>> >>>>>> The atoms should be ordered according to how frequently they are >>>>>> updated (except when the ordering is required by the hw). But most >>>>>> importantly, if there are no state changes, the loops are trivially >>>>>> skipped. >>>>>> >>>>>> Marek >>>>> >>>>> Don't think this optimization is worth it, there won't be much more >>>>> than 32 atom in the end and it definitely can't be ordered from most >>>>> frequent to less frequent as some of the stuff need to be at the last >>>>> being emitted and they are frequent one (primitive type for instance). >>>> >>>> I didn't say all atoms *must* be sorted. I meant that some (most?) >>>> atoms can be sorted, i.e. you can have some atoms at fixed positions >>>> (like the primitype type or the seamless cubemap state), but you have >>>> always at least *some* freedom where you put the rest. The ordering I >>>> had in mind was actually from the least frequent to the most frequent, >>>> in other words, from the framebuffer (least frequent) to shaders to >>>> textures to constant buffers to vertex buffers (most frequent). >>>> >>>> Of course, the code should document which atoms must have fixed >>>> positions along with an explanation. The comment that all atom >>>> positions must not be changed isn't enough, because it's not true. >>>> >>>> Marek >>> >>> I won't try to find which atom can have complete floating position, i >>> am just grouping together register that are always emitted together in >>> fglrx and then i position this group relative to each other according >>> to fglrx position. That means all atom are always emitted in a >>> specific order. So there won't be any freedom. The only freedom i can >>> think of is btw 2 position forced atom and that make the sorting >>> completely useless and complicated. >> >> I'll add the optimization anyway (without sorting). Draw operations >> without state changes or with only one state update are quite common. >> >> Anyway, it was said in the v1 thread that the hardware doesn't need >> any specific ordering for proper functioning. While it may be >> beneficial to emit one or two registers earlier than the others, >> insisting on fixed ordering of all of them is not only limiting, it >> seems useless and waste of time as well. What I don't understand: Why >> do you blindly copy everything fglrx *seems* to be doing without any >> real reason? It does not fix any bug, it does not improve performance, >> it does not clean up the code... so why? I am all ears. > > At the very least, please document a list of lockups this avoids. Less > magic more text. > > Dave.
I am doing all this for hyperz. So if it only fix hyperz that make me happy enough. Cheers, Jerome _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
