[Mesa-dev] [PATCH 4/4] dri: Add KHR_no_error toggle to driconf

[Grigori Goronzy]

On 2017-07-17 19:21, Emil Velikov wrote:
> On 13 July 2017 at 12:09, Grigori Goronzy <greg at chown.ath.cx> wrote:
>> On 2017-07-12 15:15, Emil Velikov wrote:
>>> 
>>> As mentioned in earlier commit no_error should be device agnostic.
>>> Hence removing the st/dri bits and adding a DRI_CONF_MESA_NO_ERROR()
>>> line next to DRI_CONF_VBLANK_MODE seems like the better solution.
>>> 
>> 
>> Hm, driconf overrides are typically set per screen and/or driver, so 
>> that
>> won't work. The overrides will be ignored because of screen/driver 
>> mismatch.
>> So I think it needs to be implemented separately for each classic 
>> driver.
>> I'll keep this part to the Gallium state tracker for now.
>> 
> Hmm my understanding was completely different. Have you tested my
> suggestion or this is your assumption?
> 

Sure, I have tested this. Check where driParseConfigFiles() is used in 
the code. Different parts of the stack have completely separate driconf 
databases, which are associated with different "driver names" (in 
quotes, because it's a rather confusing description, given the usage). 
The generic DRI layer that handles vblank_mode uses "dri2" as "driver 
name". Other parts have other different "driver names", all of which 
aren't obvious or documented, and most of the classic Mesa drivers also 
have separate driconf databases. So I added mesa_no_error to the generic 
DRI layer, but it only produced any result when an option is added to a 
"dri2" section of the driconf XML, which makes it somewhat strange and 
impractical to use. Of course vblank_mode has the same issue. I think 
this isn't really a good design and should be addressed at same point. 
Maybe it could be a good option to move to a single global database, or 
a hierarchical database (somewhat like LDAP). There are various possible 
options.

At this time, for practical reasons, I think it makes sense to add the 
mesa_no_error flag at the graphics driver layer only. That makes it easy 
to override this setting with the "driconf" GUI tool and there is no 
obscure "driver name" magic going on that users should not need to know 
about.

Grigori