intel/blorp: Rework our usage of ralloc when compiling shaders

Previously, we were creating the shader with a NULL ralloc context and then
trusting in blorp_compile_fs to clean it up.  The only problem was that
blorp_compile_fs didn't clean up its context properly so we were leaking.
When I went to fix that, I realized that it couldn't because it has to
return the shader binary which is allocated off of that context and used by
the caller.  The solution is to make blorp_compile_fs take a ralloc
context, allocate the nir_shaders directly off that context, and clean it
all up in whatever function creates the shader and calls blorp_compile_fs.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "12.0, 13.0" <mesa-stable@lists.freedesktop.org>

src/intel/blorp/blorp.c

@@ -165,7 +165,8 @@ nir_uniform_type_size(const struct glsl_type *type)
 }
 
 const unsigned *
-blorp_compile_fs(struct blorp_context *blorp, struct nir_shader *nir,
+blorp_compile_fs(struct blorp_context *blorp, void *mem_ctx,
+                 struct nir_shader *nir,
                  const struct brw_wm_prog_key *wm_key,
                  bool use_repclear,
                  struct brw_blorp_prog_data *prog_data,
@@ -173,13 +174,6 @@ blorp_compile_fs(struct blorp_context *blorp, struct nir_shader *nir,
 {
    const struct brw_compiler *compiler = blorp->compiler;
 
-   void *mem_ctx = ralloc_context(NULL);
-
-   /* Calling brw_preprocess_nir and friends is destructive and, if cloning is
-    * enabled, may end up completely replacing the nir_shader.  Therefore, we
-    * own it and might as well put it in our context for easy cleanup.
-    */
-   ralloc_steal(mem_ctx, nir);
    nir->options =
       compiler->glsl_compiler_options[MESA_SHADER_FRAGMENT].NirOptions;