[Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Ian Romanick]

On 02/09/2017 05:26 PM, Ian Romanick wrote:
> On 02/09/2017 05:14 PM, Eric Anholt wrote:
>> Ian Romanick <idr at freedesktop.org> writes:
>>
>>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>>>> On 07.02.2017 23:54, Matt Turner wrote:
>>>>> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
>>>>>> <kenneth at whitecape.org> wrote:
>>>>>>> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák wrote:
>>>>>>>> On Mon, Feb 6, 2017 at 8:20 PM, Ernst Sjöstrand <ernstp at gmail.com>
>>>>>>>> wrote:
>>>>>>>>> FYI glmark2 segfaults with mesa_glthread=true. Expected that some
>>>>>>>>> programs
>>>>>>>>> will segfault?
>>>>>>>>
>>>>>>>> Yes, even segfaults are expected with mesa_glthread=true.
>>>>>>>>
>>>>>>>> Marek
>>>>>>>
>>>>>>> Would it make sense to be crash-free or even regression-free on at
>>>>>>> least Piglit, before merging?  (Or are we there already?)
>>>>>>
>>>>>> It's not necessary. glthread is disabled by default. Nobody has tested
>>>>>> piglit with glthread. That will follow after it's been merged, or
>>>>>> never if it's never merged.
>>>>>
>>>>> I don't understand why you're so concerned about merging untested
>>>>> code. That violates some pretty fundamental development practices of
>>>>> the project.
>>>>>
>>>>> It's exactly unfinished projects like this that cause problems and
>>>>> inevitably have to be deleted later (ilo, openvg, d3d1x, etc). I don't
>>>>> think it's a burden to develop something out of the master branch
>>>>> until it's somewhat useful.
>>>>
>>>> The code is already somewhat useful. Actually, make that _very_ useful
>>>> (big performance improvement) for _some_ cases.
>>>>
>>>> I suspect most of the people in this discussion haven't really looked at
>>>> the code in detail (myself included). We should probably do some of that
>>>> before it is merged, since the code isn't just a new driver that is
>>>> isolated in its own directory. So I agree with Emil that it makes sense
>>>> to let the patches go over the mailing list once.
>>>>
>>>> However, it's fine to merge this without passing piglit.
>>>
>>> No, it absolutely is not fine to merge.  We have never allowed such a
>>> thing, and I'll be damned if I'll allow this project to start.  Things
>>> that land that are known to be broken never actually get fixed.  Then we
>>> have to waste time fielding bug reports and Phoronix threads because
>>> users turn on the performance features and everything breaks.  It's just
>>> a terrible idea.
>>
>> Yeah, just like how we gated the GLSL compiler until it was completely
>> done (we didn't) and NIR until it was completely done (we didn't) and
>> Vulkan until it was completely done (we didn't) and...
> 
> But we did require that it pass the test suites.  All of that lived in
> branches for a really long time with active development.  The GLSL
> compiler and NIR are two examples that support my claim.  Those were
> massive branch merges that waited much longer to merge than the people
> working on them wanted.

Also... the GLSL compiler was long before we did time-based releases.
We block the release for a really long time so that we could achieve the
quality that we need.

>> Software that people care about gets fixed.  I'm also concerned that
>> nobody actually cares about getting glthread working completely, given
>> Marek's attitude toward piglit conformance (and my also ignoring the
>> branch for the last however many years).  However, "we have never
>> allowed merging broken software that's only turned on under env
>> vars/configure" is totally false.  We do that regularly for big things
>> we care about.
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev