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. > 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
