On Tue, Dec 8, 2015 at 6:57 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 7 December 2015 at 18:55, Rob Clark <robdcl...@gmail.com> wrote: >> On Mon, Dec 7, 2015 at 1:42 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On 7 December 2015 at 16:45, Rob Clark <robdcl...@gmail.com> wrote: >>>> From: Rob Clark <robcl...@freedesktop.org> >>>> >>>> Only exposed w/ ST_DEBUG=gremedy. >>>> >>> Perhaps a bit of a silly question - why expose the extension only for >>> debug mesa builds ? Afaict there isn't any noticeable performance >>> implication (from infrastructural POV) is there ? >>> >>> If driver X performance goes down the drain, just have them >>> conditionally return 0/1 for PIPE_CAP_STRING_MARKER ? >> >> It was suggested, iirc by Ian, on the basis that apps might do >> something non-performant if they see the extension (since the original >> use-case was that the extension is injected by the gremedy debugger). >> > Hmm fair enough. Can you add some/most of that in the commit message, please ?
Perhaps something like: Since the GREMEDY extensions are normally only exposed by the gremedy debugger (and could possibly trigger debug paths in the app), we don't expose the extension by default, but instead only with ST_DEBUG=gremedy. ? I wouldn't mind at least getting this one patch pushed in the near future (since it conflicts all over the place every time someone adds a new pipe-cap ;-)) BR, -R > Thanks > Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
