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

[Marek Olšák]

On Thu, Feb 9, 2017 at 8:18 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Thu, Feb 9, 2017 at 6:23 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 02/09/2017 03:03 PM, Marek Olšák wrote:
>>> On Thu, Feb 9, 2017 at 1:52 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>>> 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.
>>>
>>> It does pass piglit, but only when it's disabled.
>>>
>>> We have to ask the question of how long it will take to reach the
>>> level of perfection that some people here demand. 1 year? 2? 4 years
>>> even? Are we willing to wait that long? Is there a sufficient minimum
>>> requirement on merging this project that's possible to reach within 2
>>> weeks? Instead of saying "absolutely not" and "terrible idea", why not
>>> just say "yes if X gets done"?
>>
>> Nobody has touched this code in years, yet you're speaking as if it has
>> been in active development for the whole time.  Eric and Paul
>> implemented, found that it didn't help any applications that existed at
>> the time, and abandoned it.
>
> There are some good arguments in this thread, but it's not this one. I
> did touch the code. I made Borderlands 2 work by adding Gallium
> support, DRI3 support, and fixing race conditions and other bugs in
> the core glthread code and glapi XML files. Even though the commits
> have Eric and Paul as authors, I edited most of them in some way.
>
> So if I understand correctly, the requirement for merging is to pass
> piglit. If we drop support for compat profiles (do we need to drop
> support for GLES?), it shouldn't be too hard.

Talos Principle uses the compat profile, so we can't drop it. :(

Marek