On Thu, Feb 9, 2017 at 8:18 PM, Marek Olšák <mar...@gmail.com> wrote: > On Thu, Feb 9, 2017 at 6:23 PM, Ian Romanick <i...@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 <i...@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 <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. >>> >>> 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
