[Mesa-dev] Seeking advice on implementing KHR_no_error
Timothy Arceri
timothy.arceri at collabora.com
Thu Dec 29 23:39:52 UTC 2016
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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list