[Mesa-dev] Seeking advice on implementing KHR_no_error

[Thomas Helland]

2016-12-30 0:39 GMT+01:00 Timothy Arceri <timothy.arceri at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev