2016-12-30 0:39 GMT+01:00 Timothy Arceri <timothy.arc...@collabora.com>: > 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. >
Yeah, I was not planning on just disabling the error reporting, as that would not be as helpful. I was planning something along the following: - Find all functions used for error reporting back to the user. - Grep for the uses of these throughout the codebase - Start at the ones that are called most often, or have a lot of costly work with validation before eventually reporting an error. - Cut them off as early as possible, before to much work is done. >> 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. > I was kinda worried about this myself. The spec says that GetError should return NO_ERROR or OUT_OF_MEMORY only. So I don't think we can simply enable the extension and pretend nothing ever happened. >> 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. > Thanks for completing the work! It's nice to see this finally land. You've done one heck of a job, if I dare say so. >> >> 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
