[Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Brian Paul]

Hi Nanley,

Maybe you can fix an issue I have with the new extension code.

Previously, I could do something like export 
MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no longer 
see it in the GL_EXTENSIONS string, even if it was an "always on" extension.


Now when I try that I get:

Mesa 11.1.0-devel implementation error: Trying to disable permanently 
enabled extensions: GL_ARB_get_texture_sub_image

Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa

The whole point of the "-GL_EXT_foobar" syntax was to hide an extension 
from the application when it queries the driver's extensions.


Can you please fix this so it works as before?

Thanks.

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Ilia Mirkin]

On Thu, Nov 19, 2015 at 3:13 PM, Brian Paul  wrote:
> Hi Nanley,
>
> Maybe you can fix an issue I have with the new extension code.
>
> Previously, I could do something like export
> MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no longer see
> it in the GL_EXTENSIONS string, even if it was an "always on" extension.

How sure are you that this worked? AFAIK there was no way to
enable/disable an always-on ext. That env var never affected the
extension strings, but only the actual ctx->Extensions struct, which
would indirectly modify the ext string. If the entry in that ext table
was a dummy one, it had logic to not futz with it. (But it did so
silently.)

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Brian Paul]

On 11/19/2015 01:19 PM, Ilia Mirkin wrote:

On Thu, Nov 19, 2015 at 3:13 PM, Brian Paul  wrote:

Hi Nanley,

Maybe you can fix an issue I have with the new extension code.

Previously, I could do something like export
MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no longer see
it in the GL_EXTENSIONS string, even if it was an "always on" extension.


How sure are you that this worked?


I'm pretty sure it worked that way when I first wrote it.



AFAIK there was no way to
enable/disable an always-on ext.


That's not the point.  The point is to change what 
glGetString(GL_EXTENSIONS) (or the glGetStringi() method) returns to the 
application.  I don't care if the underlying functionality is still 
working in Mesa.  We're trying to tell the application to not use a 
feature.  I've found this extremely helpful when debugging some apps.




That env var never affected the
extension strings, but only the actual ctx->Extensions struct, which
would indirectly modify the ext string. If the entry in that ext table
was a dummy one, it had logic to not futz with it. (But it did so
silently.)


Yeah, I don't care about the table.  I only care about the return value 
of glGetString(GL_EXTENSIONS).


-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Ilia Mirkin]

On Thu, Nov 19, 2015 at 3:25 PM, Brian Paul  wrote:
> On 11/19/2015 01:19 PM, Ilia Mirkin wrote:
>>
>> On Thu, Nov 19, 2015 at 3:13 PM, Brian Paul  wrote:
>>>
>>> Hi Nanley,
>>>
>>> Maybe you can fix an issue I have with the new extension code.
>>>
>>> Previously, I could do something like export
>>> MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no longer
>>> see
>>> it in the GL_EXTENSIONS string, even if it was an "always on" extension.
>>
>>
>> How sure are you that this worked?
>
>
> I'm pretty sure it worked that way when I first wrote it.
>
>
>> AFAIK there was no way to
>> enable/disable an always-on ext.
>
>
> That's not the point.  The point is to change what
> glGetString(GL_EXTENSIONS) (or the glGetStringi() method) returns to the
> application.  I don't care if the underlying functionality is still working
> in Mesa.  We're trying to tell the application to not use a feature.  I've
> found this extremely helpful when debugging some apps.
>
>
>> That env var never affected the
>> extension strings, but only the actual ctx->Extensions struct, which
>> would indirectly modify the ext string. If the entry in that ext table
>> was a dummy one, it had logic to not futz with it. (But it did so
>> silently.)
>
>
> Yeah, I don't care about the table.  I only care about the return value of
> glGetString(GL_EXTENSIONS).

I was pretty annoyed at that too -- having it affect exts returned by
the driver seemed to be the important bit, but I think I investigated
why it didn't work ~6 months ago, and came to the above conclusion
[that it only futzed with the table]. In fact recently someone was
unable to work around an ARB_dsa shortcoming in nouveau by disabling
it with an override.

IMHO it makes sense for it to affect both the table and the ext
string... i.e. if there's a ctx->Extensions.foo listed, it should turn
that on/off, but if there isn't, it should still touch up the returned
ext list.

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Nanley Chery]

On Thu, Nov 19, 2015 at 12:13 PM, Brian Paul  wrote:

> Hi Nanley,
>
>
Hi Brian,


> Maybe you can fix an issue I have with the new extension code.
>
> Previously, I could do something like export
> MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no longer
> see it in the GL_EXTENSIONS string, even if it was an "always on" extension.
>
> Now when I try that I get:
>
> Mesa 11.1.0-devel implementation error: Trying to disable permanently
> enabled extensions: GL_ARB_get_texture_sub_image
> Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
>
> The whole point of the "-GL_EXT_foobar" syntax was to hide an extension
> from the application when it queries the driver's extensions.
>
> Can you please fix this so it works as before?
>
>
I have two branches that provide the ability to disable permanently enabled
extensions:
1. The first only modifies the extension strings and is located here:
http://cgit.freedesktop.org/~nchery/mesa/commit/?h=mod_always_on
2. The second modifies the extension strings and disables the extension
within the driver (assuming appropriate the helper function is used). It
also provides some performance benefits. :
http://cgit.freedesktop.org/~nchery/mesa/commit/?h=init_ext_vals

I'd appreciate any feedback on the two approaches as I work to get the
feature upstreamed.

Regards,
Nanley


> Thanks.
>
> -Brian
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Ian Romanick]

On 11/19/2015 12:30 PM, Ilia Mirkin wrote:
> On Thu, Nov 19, 2015 at 3:25 PM, Brian Paul  wrote:
>> On 11/19/2015 01:19 PM, Ilia Mirkin wrote:
>>> On Thu, Nov 19, 2015 at 3:13 PM, Brian Paul  wrote:

 Hi Nanley,

 Maybe you can fix an issue I have with the new extension code.

 Previously, I could do something like export
 MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no longer
 see
 it in the GL_EXTENSIONS string, even if it was an "always on" extension.
>>>
>>> How sure are you that this worked?
>>
>> I'm pretty sure it worked that way when I first wrote it.
>>
>>> AFAIK there was no way to
>>> enable/disable an always-on ext.
>>
>> That's not the point.  The point is to change what
>> glGetString(GL_EXTENSIONS) (or the glGetStringi() method) returns to the
>> application.  I don't care if the underlying functionality is still working
>> in Mesa.  We're trying to tell the application to not use a feature.  I've
>> found this extremely helpful when debugging some apps.
>>
>>> That env var never affected the
>>> extension strings, but only the actual ctx->Extensions struct, which
>>> would indirectly modify the ext string. If the entry in that ext table
>>> was a dummy one, it had logic to not futz with it. (But it did so
>>> silently.)
>>
>> Yeah, I don't care about the table.  I only care about the return value of
>> glGetString(GL_EXTENSIONS).
> 
> I was pretty annoyed at that too -- having it affect exts returned by
> the driver seemed to be the important bit, but I think I investigated
> why it didn't work ~6 months ago, and came to the above conclusion
> [that it only futzed with the table]. In fact recently someone was
> unable to work around an ARB_dsa shortcoming in nouveau by disabling
> it with an override.

Ugh... How much should this work?  Extensions are used to determine GL
versions, and compute_version can't check that "always on" extensions
have been disabled.  If you try to disable GL_EXT_texture, you'll still
get at least OpenGL 1.1. :)  Is it okay that the version override is
still needed to disable newer versions?

> IMHO it makes sense for it to affect both the table and the ext
> string... i.e. if there's a ctx->Extensions.foo listed, it should turn
> that on/off, but if there isn't, it should still touch up the returned
> ext list.
> 
>   -ilia
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Ian Romanick]

On 11/19/2015 05:40 PM, Nanley Chery wrote:
> 
> On Thu, Nov 19, 2015 at 12:13 PM, Brian Paul  > wrote:
> 
> Hi Nanley,
> 
>  
> Hi Brian,
>  
> 
> Maybe you can fix an issue I have with the new extension code.
> 
> Previously, I could do something like export
> MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no
> longer see it in the GL_EXTENSIONS string, even if it was an "always
> on" extension.
> 
> Now when I try that I get:
> 
> Mesa 11.1.0-devel implementation error: Trying to disable
> permanently enabled extensions: GL_ARB_get_texture_sub_image
> Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
> 
> The whole point of the "-GL_EXT_foobar" syntax was to hide an
> extension from the application when it queries the driver's extensions.
> 
> Can you please fix this so it works as before?
> 
> 
> I have two branches that provide the ability to disable permanently
> enabled extensions:
> 1. The first only modifies the extension strings and is located here:
> http://cgit.freedesktop.org/~nchery/mesa/commit/?h=mod_always_on
> 
> 2. The second modifies the extension strings and disables the extension
> within the driver (assuming appropriate the helper function is used). It
> also provides some performance benefits. :
> http://cgit.freedesktop.org/~nchery/mesa/commit/?h=init_ext_vals
> 
> 
> I'd appreciate any feedback on the two approaches as I work to get the
> feature upstreamed.

I think #2 might be better, but there's a lot of churn.  I don't know
that we want that much churn right around the time of the release branch
point, and I think it would be good to have this resolved in 11.1.  I
also have a few bits of feedback in #2, so it might take a couple
iterations before that could land.

Whatever we do, I think we should create some 'make check' tests to
verify that the functionality continues to work in the future.

> Regards,
> Nanley
>  
> 
> Thanks.
> 
> -Brian
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org 
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Brian Paul]

On Thu, Nov 19, 2015 at 7:04 PM, Ian Romanick  wrote:

> On 11/19/2015 05:40 PM, Nanley Chery wrote:
> >
> > On Thu, Nov 19, 2015 at 12:13 PM, Brian Paul  > > wrote:
> >
> > Hi Nanley,
> >
> >
> > Hi Brian,
> >
> >
> > Maybe you can fix an issue I have with the new extension code.
> >
> > Previously, I could do something like export
> > MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no
> > longer see it in the GL_EXTENSIONS string, even if it was an "always
> > on" extension.
> >
> > Now when I try that I get:
> >
> > Mesa 11.1.0-devel implementation error: Trying to disable
> > permanently enabled extensions: GL_ARB_get_texture_sub_image
> > Please report at
> https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
> >
> > The whole point of the "-GL_EXT_foobar" syntax was to hide an
> > extension from the application when it queries the driver's
> extensions.
> >
> > Can you please fix this so it works as before?
> >
> >
> > I have two branches that provide the ability to disable permanently
> > enabled extensions:
> > 1. The first only modifies the extension strings and is located here:
> > http://cgit.freedesktop.org/~nchery/mesa/commit/?h=mod_always_on
> > 
> > 2. The second modifies the extension strings and disables the extension
> > within the driver (assuming appropriate the helper function is used). It
> > also provides some performance benefits. :
> > http://cgit.freedesktop.org/~nchery/mesa/commit/?h=init_ext_vals
> > 
> >
> > I'd appreciate any feedback on the two approaches as I work to get the
> > feature upstreamed.
>
> I think #2 might be better, but there's a lot of churn.  I don't know
> that we want that much churn right around the time of the release branch
> point, and I think it would be good to have this resolved in 11.1.  I
> also have a few bits of feedback in #2, so it might take a couple
> iterations before that could land.
>
>
Since 11.1 is coming up, can we go with the simpler #1 for now, then go to
#2 after 11.1 branches?

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Nanley Chery]

On Fri, Nov 20, 2015 at 8:49 AM, Brian Paul  wrote:

> On Thu, Nov 19, 2015 at 7:04 PM, Ian Romanick  wrote:
>
>> On 11/19/2015 05:40 PM, Nanley Chery wrote:
>> >
>> > On Thu, Nov 19, 2015 at 12:13 PM, Brian Paul > > > wrote:
>> >
>> > Hi Nanley,
>> >
>> >
>> > Hi Brian,
>> >
>> >
>> > Maybe you can fix an issue I have with the new extension code.
>> >
>> > Previously, I could do something like export
>> > MESA_EXTENSION_OVERRIDE="-ARB_clear_buffer_object" and I would no
>> > longer see it in the GL_EXTENSIONS string, even if it was an "always
>> > on" extension.
>> >
>> > Now when I try that I get:
>> >
>> > Mesa 11.1.0-devel implementation error: Trying to disable
>> > permanently enabled extensions: GL_ARB_get_texture_sub_image
>> > Please report at
>> https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
>> >
>> > The whole point of the "-GL_EXT_foobar" syntax was to hide an
>> > extension from the application when it queries the driver's
>> extensions.
>> >
>> > Can you please fix this so it works as before?
>> >
>> >
>> > I have two branches that provide the ability to disable permanently
>> > enabled extensions:
>> > 1. The first only modifies the extension strings and is located here:
>> > http://cgit.freedesktop.org/~nchery/mesa/commit/?h=mod_always_on
>> > 
>> > 2. The second modifies the extension strings and disables the extension
>> > within the driver (assuming appropriate the helper function is used). It
>> > also provides some performance benefits. :
>> > http://cgit.freedesktop.org/~nchery/mesa/commit/?h=init_ext_vals
>> > 
>> >
>> > I'd appreciate any feedback on the two approaches as I work to get the
>> > feature upstreamed.
>>
>> I think #2 might be better, but there's a lot of churn.  I don't know
>> that we want that much churn right around the time of the release branch
>> point, and I think it would be good to have this resolved in 11.1.  I
>> also have a few bits of feedback in #2, so it might take a couple
>> iterations before that could land.
>>
>>
> Since 11.1 is coming up, can we go with the simpler #1 for now, then go to
> #2 after 11.1 branches?
>
>
I don't mind going this route. Unfortunately, I'm running into presently
unexplainable linker errors in the process of making the gtest for this
feature.

- Nanley
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Chad Versace]

On Fri 20 Nov 2015, Nanley Chery wrote:
> On Fri, Nov 20, 2015 at 8:49 AM, Brian Paul  wrote:
> 
> > On Thu, Nov 19, 2015 at 7:04 PM, Ian Romanick  wrote:

> >> I think #2 might be better, but there's a lot of churn.  I don't know
> >> that we want that much churn right around the time of the release branch
> >> point, and I think it would be good to have this resolved in 11.1.  I
> >> also have a few bits of feedback in #2, so it might take a couple
> >> iterations before that could land.
> >>
> >>
> > Since 11.1 is coming up, can we go with the simpler #1 for now, then go to
> > #2 after 11.1 branches?
> >
> >
> I don't mind going this route. Unfortunately, I'm running into presently
> unexplainable linker errors in the process of making the gtest for this
> feature.

Nanley, you're branch has two patches. If you remove the gtest patch
(patch #2) from your branch, does everything work as expected? If so,
then I think it's best to get patch #1 into
11.1 before the Emil creates the branchpoint, and worry about the gtest
afterwards.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Nanley Chery]

On Fri, Nov 20, 2015 at 3:38 PM, Chad Versace 
wrote:

> On Fri 20 Nov 2015, Nanley Chery wrote:
> > On Fri, Nov 20, 2015 at 8:49 AM, Brian Paul 
> wrote:
> >
> > > On Thu, Nov 19, 2015 at 7:04 PM, Ian Romanick 
> wrote:
>
> > >> I think #2 might be better, but there's a lot of churn.  I don't know
> > >> that we want that much churn right around the time of the release
> branch
> > >> point, and I think it would be good to have this resolved in 11.1.  I
> > >> also have a few bits of feedback in #2, so it might take a couple
> > >> iterations before that could land.
> > >>
> > >>
> > > Since 11.1 is coming up, can we go with the simpler #1 for now, then
> go to
> > > #2 after 11.1 branches?
> > >
> > >
> > I don't mind going this route. Unfortunately, I'm running into presently
> > unexplainable linker errors in the process of making the gtest for this
> > feature.
>
> Nanley, you're branch has two patches. If you remove the gtest patch
> (patch #2) from your branch, does everything work as expected? If so,
> then I think it's best to get patch #1 into
> 11.1 before the Emil creates the branchpoint, and worry about the gtest
> afterwards.
>

Yes, it does work as expected. I'll send out the patch then.

Thanks,
Nanley
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Nanley Chery]

On Fri, Nov 20, 2015 at 3:38 PM, Chad Versace 
wrote:

> On Fri 20 Nov 2015, Nanley Chery wrote:
> > On Fri, Nov 20, 2015 at 8:49 AM, Brian Paul 
> wrote:
> >
> > > On Thu, Nov 19, 2015 at 7:04 PM, Ian Romanick 
> wrote:
>
> > >> I think #2 might be better, but there's a lot of churn.  I don't know
> > >> that we want that much churn right around the time of the release
> branch
> > >> point, and I think it would be good to have this resolved in 11.1.  I
> > >> also have a few bits of feedback in #2, so it might take a couple
> > >> iterations before that could land.
> > >>
> > >>
> > > Since 11.1 is coming up, can we go with the simpler #1 for now, then
> go to
> > > #2 after 11.1 branches?
> > >
> > >
> > I don't mind going this route. Unfortunately, I'm running into presently
> > unexplainable linker errors in the process of making the gtest for this
> > feature.
>
> Nanley, you're branch has two patches. If you remove the gtest patch
> (patch #2) from your branch, does everything work as expected? If so,
> then I think it's best to get patch #1 into
> 11.1 before the Emil creates the branchpoint, and worry about the gtest
> afterwards.
>

I've been told that most people wait 24 hours before pushing a patch that's
been given an Rb. Would it be acceptable to push it immediately given the
circumstances?

Regards,
Nanley
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Emil Velikov]

On 21 November 2015 at 00:31, Nanley Chery  wrote:
> On Fri, Nov 20, 2015 at 3:38 PM, Chad Versace 
> wrote:
>>
>> On Fri 20 Nov 2015, Nanley Chery wrote:
>> > On Fri, Nov 20, 2015 at 8:49 AM, Brian Paul 
>> > wrote:
>> >
>> > > On Thu, Nov 19, 2015 at 7:04 PM, Ian Romanick 
>> > > wrote:
>>
>> > >> I think #2 might be better, but there's a lot of churn.  I don't know
>> > >> that we want that much churn right around the time of the release
>> > >> branch
>> > >> point, and I think it would be good to have this resolved in 11.1.  I
>> > >> also have a few bits of feedback in #2, so it might take a couple
>> > >> iterations before that could land.
>> > >>
>> > >>
>> > > Since 11.1 is coming up, can we go with the simpler #1 for now, then
>> > > go to
>> > > #2 after 11.1 branches?
>> > >
>> > >
>> > I don't mind going this route. Unfortunately, I'm running into presently
>> > unexplainable linker errors in the process of making the gtest for this
>> > feature.
>>
>> Nanley, you're branch has two patches. If you remove the gtest patch
>> (patch #2) from your branch, does everything work as expected? If so,
>> then I think it's best to get patch #1 into
>> 11.1 before the Emil creates the branchpoint, and worry about the gtest
>> afterwards.
>
>
> I've been told that most people wait 24 hours before pushing a patch that's
> been given an Rb. Would it be acceptable to push it immediately given the
> circumstances?
>
Get it out and reviewed please. This is a bugfix I'll pick it once
it's ready, although add the mesa-stable line in there just in case
:-)

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MESA_EXTENSION_OVERRIDE problem

[Nanley Chery]

On Fri, Nov 20, 2015 at 5:05 PM, Emil Velikov 
wrote:

> On 21 November 2015 at 00:31, Nanley Chery  wrote:
> > On Fri, Nov 20, 2015 at 3:38 PM, Chad Versace 
> > wrote:
> >>
> >> On Fri 20 Nov 2015, Nanley Chery wrote:
> >> > On Fri, Nov 20, 2015 at 8:49 AM, Brian Paul 
> >> > wrote:
> >> >
> >> > > On Thu, Nov 19, 2015 at 7:04 PM, Ian Romanick 
> >> > > wrote:
> >>
> >> > >> I think #2 might be better, but there's a lot of churn.  I don't
> know
> >> > >> that we want that much churn right around the time of the release
> >> > >> branch
> >> > >> point, and I think it would be good to have this resolved in
> 11.1.  I
> >> > >> also have a few bits of feedback in #2, so it might take a couple
> >> > >> iterations before that could land.
> >> > >>
> >> > >>
> >> > > Since 11.1 is coming up, can we go with the simpler #1 for now, then
> >> > > go to
> >> > > #2 after 11.1 branches?
> >> > >
> >> > >
> >> > I don't mind going this route. Unfortunately, I'm running into
> presently
> >> > unexplainable linker errors in the process of making the gtest for
> this
> >> > feature.
> >>
> >> Nanley, you're branch has two patches. If you remove the gtest patch
> >> (patch #2) from your branch, does everything work as expected? If so,
> >> then I think it's best to get patch #1 into
> >> 11.1 before the Emil creates the branchpoint, and worry about the gtest
> >> afterwards.
> >
> >
> > I've been told that most people wait 24 hours before pushing a patch
> that's
> > been given an Rb. Would it be acceptable to push it immediately given the
> > circumstances?
> >
> Get it out and reviewed please. This is a bugfix I'll pick it once
> it's ready, although add the mesa-stable line in there just in case
> :-)
>
>
It recently has been reviewed:
http://lists.freedesktop.org/archives/mesa-dev/2015-November/101027.html

I was just wondering if I could push it to master now.

Thanks for the reply,
Nanley


> Thanks
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev