On 18 July 2017 at 09:26, Grigori Goronzy <g...@chown.ath.cx> wrote:
> On 2017-07-17 19:21, Emil Velikov wrote:
>>
>> On 13 July 2017 at 12:09, Grigori Goronzy <g...@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.
>
The XML device section allows empty "driver name". Hence something
like the following should just work.
If it doesn't we have a bug somewhere. On the confusing "dri2" name:
we could purge relatively easy - but that for another day.
<driconf>
<device>
...
<application name="goo" executable="bar">
<option name="mesa_no_error" value="true" />
</application>
...
</device>
</driconf>
> 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.
>
As mentioned earlier - keeping it at Gallium level (current solution
is not at driver level) makes perfect sense.
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
