Re: [Mesa-dev] [Mesa-stable] [Review Request (master branch)] st/mesa: release tgsi tokens for shader states

2019-12-19 Thread Marek Olšák
Pushed, thanks!

Marek

On Thu, Dec 19, 2019 at 2:22 PM Neha Bhende  wrote:

> Since we are using st_common_variant while creating variant for vertext
> program, we can release tokens created in st_create_vp_variant which
> are already stored in respective states.
> This fix memory leak found with piglit tests
>
> Fixes bc99b22a305b ('st/mesa: use a separate VS variant for the draw
> module')
>
> Reviewed-by: Charmaine Lee 
> ---
>  src/mesa/state_tracker/st_program.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_program.c
> b/src/mesa/state_tracker/st_program.c
> index a9ff68c1f50..ef10399fa18 100644
> --- a/src/mesa/state_tracker/st_program.c
> +++ b/src/mesa/state_tracker/st_program.c
> @@ -694,6 +694,10 @@ st_create_vp_variant(struct st_context *st,
> else
>vpv->base.driver_shader = pipe->create_vs_state(pipe, &state);
>
> +   if (state.tokens) {
> +  tgsi_free_tokens(state.tokens);
> +   }
> +
> return vpv;
>  }
>
> --
> 2.17.1
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Review Request (master branch)] st/mesa: release tgsi tokens for shader states

2019-12-19 Thread Neha Bhende
Since we are using st_common_variant while creating variant for vertext
program, we can release tokens created in st_create_vp_variant which
are already stored in respective states.
This fix memory leak found with piglit tests

Fixes bc99b22a305b ('st/mesa: use a separate VS variant for the draw module')

Reviewed-by: Charmaine Lee 
---
 src/mesa/state_tracker/st_program.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index a9ff68c1f50..ef10399fa18 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -694,6 +694,10 @@ st_create_vp_variant(struct st_context *st,
else
   vpv->base.driver_shader = pipe->create_vs_state(pipe, &state);
 
+   if (state.tokens) {
+  tgsi_free_tokens(state.tokens);
+   }
+
return vpv;
 }
 
-- 
2.17.1

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


Re: [Mesa-dev] Requiring a full author name when contributing to mesa?

2019-12-19 Thread Timur Kristóf
On Fri, 2019-12-13 at 11:00 +1100, Timothy Arceri wrote:
> On 13/12/19 10:15 am, Alex Deucher wrote:
> > What does the name matter?  The name is the least of your worries.
> > What if their patch uses a patented algorithm?  Does anyone check
> > for
> > that?  The whole Signed-off-by thing just just hazing for newbs.
> > Someone took the time to write and submit a patch.  We trust they
> > did
> > the right thing and didn't do anything illegal. It's on the
> > reviewers
> > to determine if the patch is reasonable and should be applied.  The
> > name is just window dressing.
> 
> Yes exactly the name is just window dressing, where a window dressing
> is 
> "designed to create a favourable impression". In this case to make
> our 
> project look competently and professionally run at a glance. I've
> been 
> lucky enough to be employed to work on this project for around 5
> years 
> now, but don't expect this to last forever. Eventually I'd like to
> be 
> able to point out to future employers the work I've been doing for
> all 
> this time. Personally I'd like the window dressing to look nice when 
> this time comes.
> 
> If other developers don't care which was my original question then
> I'll 
> stop wasting my time requesting people not use such author names.

We review code, not people. I agree that we should prefer a 'real'
name, but we shouldn't require it. Some people may have a good reason
to conceal their identity.

I get what you mean, but why do you feel that allowing people to
contribute using a nickname is unprofessional? You can still tell your
(hypothetical) future employer that you worked on a high-profile free /
open source project where several big companies managed to work
together.

The fact that contributions from amateurs (with or without a 'proper'
name) is accepted I think makes the project look better, not worse.

Just my 20 cents.

Best regards,
Tim

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