On Thu, 2016-12-29 at 23:54 +0100, Thomas Helland wrote: > Hi all, > > I'm sitting here looking for something usefull to do on mesa in my > spare time. > I've considered implementing some optimization passes, or finding > some overhead > that I can have a shot at reducing, like the huge amount of > malloc/alloc/free calls. > However, I've found that this is hard when I have only 2-hour bursts > to work on it. > It quickly becomes a case where more time is spent catching up than > implementing. > > I've looked at the KHR_no_error extension. It looks like a usefull > one. > However, I don't know if it is used by any applications as of yet.
Last time I looked at this extension I think there was at least one of the mainstream emulators using it. Can't recall which one ... pcsx2 maybe. > It also looks like it can be implemented piecewise, as it allows > errors to be > submitted by the driver even if the extension is enabled. > So one can track down each error-checking codepath one by one. Yep. We would likely enable it and continue to turn things off over time as I see it. > As far as I've understood, _mesa_glsl_error is (one of) the > function(s) used to > report errors, and glsl_parser_extras.cpp is where a lot of the error > checking happens? Removing error checking from the compiler isn't going to be overly useful. The big wins will be from dropping draw time validation, for example _mesa_validate_program_pipeline() gets called at draw time in ES. In fact we may be able to totally drop calls to _mesa_valid_to_render() entirely. > Apart from that it's basically a case of looking at a patch series > implementing > some other fairly trivial extension to get an idea of what needs > changing apart > from the functionality of the extension itself. > > I haven't investigated to much into this yet, as I wanted to air the > suggestion. > Do you guys think this is a usefull extension, and one that is > beneficial? I think it could be useful. My only concern with this extension was that we would plaster if (KHR_no_error_enabled) everywhere. With a bit of thought and careful refactoring we might be able to do it in a way that avoids this to much. > If anyone has any suggestions for other small tasks, feel free to > share them. Not sure if you noticed but NIR loop unrolling landed recently. Yay! I believe there is likely more room for improvements in unrolling further loops. More analysis of the remaining loops in shader-db is needed. Looking at those would probably fit well into 2-hour bursts. > > Holiday greetings, > Thomas > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
