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

[Ian Romanick]

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.

> If you only expect absolutism and perfectionism, you'll be very
> disappointed with this project. Doing a threaded GL dispatch is hard.
> NVIDIA had had performance issues with it for a very long time. AMD
> doesn't even have a solution that can be enabled by default.

Not achieving the desired performance is vastly different from
segfaults.  Does the threaded mode in NVIDIA's driver crash?  I'd wager
not.  We have always had high quality standards for Mesa.  We have
always adhered to the specified OpenGL behavior (and worked to fix the
spec when it didn't match other vendors).  These are the things that
have made Mesa successful in the presence of drivers with more features
and / or better performance.  It has also made software developers like
Mesa and trust us.  I haven't heard a compelling reason to abandon those
fundamental principles.

There have been times in the past where we have landed performance
oriented features that didn't initially provide performance benefits to
all applications.  i965's transition to NIR is one such case.  However,
we did require that the test suites passed with the feature enabled.

> I'm not heavily invested in this project (yet), so it won't bother me
> much if this doesn't get merged before mid-2017. If people wanna
> contribute, they can send me pull requests. (please do it early &
> often, don't wait until you have something that's good enough)
> 
> I've been contemplating doing threaded gallium dispatch for a while
> now. It should be very easy if we copy some sync prevention tricks
> from radeonsi, and we might be able to enable it by default for all GL
> apps (core & compat) from day 1. That can be our short-term goal for
> gallium, while threaded GL can be our long-term goal and only limited
> to whitelisted apps for quite a while.
> 
> Marek