<p dir="ltr"><br>
On Oct 14, 2015 10:48 PM, "Pohjolainen, Topi" <<a href="mailto:topi.pohjolainen@intel.com">topi.pohjolainen@intel.com</a>> wrote:<br>
><br>
> On Wed, Oct 14, 2015 at 11:53:37AM -0700, Jason Ekstrand wrote:<br>
> > On Wed, Oct 14, 2015 at 1:41 AM, Pohjolainen, Topi<br>
> > <<a href="mailto:topi.pohjolainen@intel.com">topi.pohjolainen@intel.com</a>> wrote:<br>
> > > On Wed, Oct 14, 2015 at 11:25:40AM +0300, Pohjolainen, Topi wrote:<br>
> > >> On Sat, Oct 10, 2015 at 08:09:01AM -0700, Jason Ekstrand wrote:<br>
> > >> > This commit removes all dependence on GL state by getting rid of the<br>
> > >> > brw_context parameter and the GL data structures.<br>
> > >> ><br>
> > >> > v2 (Jason Ekstrand):<br>
> > >> > - Patch use_legacy_snorm_formula through as a function argument rather<br>
> > >> > than trying to go through the shader key.<br>
> > >> > ---<br>
> > >> > src/mesa/drivers/dri/i965/brw_vec4.cpp | 70 +++++++++++++---------------------<br>
> > >> > src/mesa/drivers/dri/i965/brw_vs.c | 16 +++++++-<br>
> > >> > src/mesa/drivers/dri/i965/brw_vs.h | 12 ++++--<br>
> > >> > 3 files changed, 49 insertions(+), 49 deletions(-)<br>
> > >> ><br>
> > >> > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp b/src/mesa/drivers/dri/i965/brw_vec4.cpp<br>
> > >> > index 4b8390f..8e38729 100644<br>
> > >> > --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp<br>
> > >> > +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp<br>
> > >> > @@ -1937,51 +1937,42 @@ extern "C" {<br>
> > >> > * Returns the final assembly and the program's size.<br>
> > >> > */<br>
> > >> > const unsigned *<br>
> > >> > -brw_vs_emit(struct brw_context *brw,<br>
> > >> > +brw_vs_emit(const struct brw_compiler *compiler, void *log_data,<br>
> > >> > void *mem_ctx,<br>
> > >> > const struct brw_vs_prog_key *key,<br>
> > >> > struct brw_vs_prog_data *prog_data,<br>
> > >> > - struct gl_vertex_program *vp,<br>
> > >> > - struct gl_shader_program *prog,<br>
> > >> > + const nir_shader *shader,<br>
> > >> > + gl_clip_plane *clip_planes,<br>
> > >> > + bool use_legacy_snorm_formula,<br>
> > >> > int shader_time_index,<br>
> > >> > - unsigned *final_assembly_size)<br>
> > >> > + unsigned *final_assembly_size,<br>
> > >> > + char **error_str)<br>
> > >> > {<br>
> > >> > const unsigned *assembly = NULL;<br>
> > >> ><br>
> > >> > - if (brw->intelScreen->compiler->scalar_vs) {<br>
> > >> > + if (compiler->scalar_vs) {<br>
> > >> > prog_data->base.dispatch_mode = DISPATCH_MODE_SIMD8;<br>
> > >> ><br>
> > >> > - fs_visitor v(brw->intelScreen->compiler, brw,<br>
> > >> > - mem_ctx, key, &prog_data->base.base,<br>
> > >> > + fs_visitor v(compiler, log_data, mem_ctx, key, &prog_data->base.base,<br>
> > >> > NULL, /* prog; Only used for TEXTURE_RECTANGLE on gen < 8 */<br>
> > >> > - vp->Base.nir, 8, shader_time_index);<br>
> > >> > - if (!v.run_vs(brw_select_clip_planes(&brw->ctx))) {<br>
> > >> > - if (prog) {<br>
> > >> > - prog->LinkStatus = false;<br>
> > >> > - ralloc_strcat(&prog->InfoLog, v.fail_msg);<br>
> > >> > - }<br>
> > >> > -<br>
> > >> > - _mesa_problem(NULL, "Failed to compile vertex shader: %s\n",<br>
> > >> > - v.fail_msg);<br>
> > >> > + shader, 8, shader_time_index);<br>
> > >> > + if (!v.run_vs(clip_planes)) {<br>
> > >> > + if (error_str)<br>
> > >> > + *error_str = ralloc_strdup(mem_ctx, v.fail_msg);<br>
> > >><br>
> > >> I don't particularly like the complexity of the error reporting mechanism.<br>
> > >> First vec4_visitor::fail() uses ralloc_asprintf() to create one string, then<br>
> > >> we make a copy of it here and finally the caller of brw_vs_emit() makes yet<br>
> > >> another copy using ralloc_strcat().<br>
> > >> I wonder if we could pass the final destination all the way for the<br>
> > >> vec4_visitor::fail() to augment with ralloc_asprintf() and hence avoid all<br>
> > ><br>
> > > Or more appropiately using ralloc_asprintf_append()...<br>
> > ><br>
> > >> the indirection in the middle. What do you think?<br>
> ><br>
> > I'd be moderately ok with just doing "*error_str = v.fail_msg" and<br>
> > avoiding the extra copy. I'm not a big fan of the extra copy, but I<br>
> > decided to leave it in for a couple of reasons<br>
> ><br>
> > 1) It only happens on the error path so it's not a big deal.<br>
><br>
> I wasn't concerned about the overhead either, as you said this is error path<br>
> only.<br>
><br>
> ><br>
> > 2) Not copying it is kind of a layering violation. You're grabbing a<br>
> > string from an object without copying it, destroying the object, and<br>
> > then handing it back to the thing that called you. The only way this<br>
> > works is if you know that the class ralloc'd the string from the<br>
> > context you gave it. We do, in this case, but it did seem like a bit<br>
> > of a layering violation.<br>
> ><br>
> > 3) The first time I did this rework, I created a new memory context<br>
> > for *_emit and destroyed that memory context at the end. Because<br>
> > fail_msg was allocated out of this temp context, I had to do something<br>
> > with it before returning it. The objective there was to remove the<br>
> > mem_ctx input parameter and make it more self-contained. Then I<br>
> > realized that we had to do something about the pointer that gets<br>
> > returned. The only sane use of the emit function is to call it,<br>
> > immediately copy the result into some buffer, and destroy the context<br>
> > so it wasn't like having a temp context just for *_emit was really<br>
> > going help us keep stuff around for a shorter period of time. In the<br>
> > end, I put the mem_ctx parameter back in.<br>
> ><br>
> > There's my reasoning. That said, if you'd still like to get rid of<br>
> > the copy, I'm ok with that.<br>
><br>
> Clearly you have given it more thought than I have. I don't really have<br>
> preference between making the copy or assigning the pointer directly. I can<br>
> only think of policy-based designs giving control to the caller (which in<br>
> turn would involve templates). So lets just leave it as is:<br>
><br>
> Reviewed-by: Topi Pohjolainen <<a href="mailto:topi.pohjolainen@intel.com">topi.pohjolainen@intel.com</a>></p>
<p dir="ltr">Were you planning on reviewing the rest of the series? There are still some patches needing review.<br>
--Jason</p>