On Fri, Oct 21, 2016 at 4:41 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 21.10.2016 um 15:17 schrieb Marek Olšák: >> On Oct 21, 2016 12:06 PM, "Jan Ziak" <0xe2.0x9a.0...@gmail.com >> <mailto:0xe2.0x9a.0...@gmail.com>> wrote: >>> >>> On Fri, Oct 21, 2016 at 12:04 PM, Marek Olšák <mar...@gmail.com >> <mailto:mar...@gmail.com>> wrote: >>> > This won't make it faster. >>> >>> Why? >> >> It's obviously a micro optimization that adds more stuff than it >> benefits the runtime. I don't think that real performance improvements >> will be so simple and obvious. >> >> Marek >> > > Still, shouldn't it be faster though, even if just very very minimally so?
If at least one of the atoms gets updated, the overhead of the update function will be so high that the saved couple of instructions in the while loop will be unmeasurable. Yes, st_validate_state is pretty huge in profilers. However, the problem is not only in st_validate_state and the atoms, but also in most of mesa/main that sets the _NEW_* flags, which in turn invokes more state updates than needed. That's a big problem of mesa/main and quite a complex one to solve. It's also partly a Gallium design problem, because OpenGL doesn't have per-stage shader resource slots like DX11 has, but instead all texture etc. slots are global, e.g. texture unit 0 is slot 0 in all shader stages. This is going into some deep design issues and even if we had a perfect design, how much performance could we get with that? Isn't a threaded GL dispatch 100x easier than rewriting Mesa? Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
