On 02/09/2017 05:26 PM, Ian Romanick wrote: > On 02/09/2017 05:14 PM, Eric Anholt wrote: >> Ian Romanick <i...@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 <mar...@gmail.com> wrote: >>>>>> On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke >>>>>> <kenn...@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 <ern...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
