[Mesa-dev] [PATCH 1/2] i965: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically.

Ian Romanick idr at freedesktop.org
Fri Nov 22 11:26:37 PST 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/22/2013 10:05 AM, Francisco Jerez wrote:
> Petri Latvala <petri.latvala at intel.com> writes:
> 
>> [...] @@ -325,8 +326,9 @@ public: */ dst_reg
>> output_reg[BRW_VARYING_SLOT_COUNT]; const char
>> *output_reg_annotation[BRW_VARYING_SLOT_COUNT]; -   int
>> uniform_size[MAX_UNIFORMS]; -   int
>> uniform_vector_size[MAX_UNIFORMS]; +   unsigned
>> uniform_param_count; +   int* uniform_size; +   int*
>> uniform_vector_size; int uniforms;
>> 
> All the code around you uses the 'type *identifier' convention,
> please keep it consistent.
> 
>> src_reg shader_start_time; [...] @@ -556,7 +558,7 @@
>> brw_gs_emit(struct brw_context *brw, if (likely(!(INTEL_DEBUG &
>> DEBUG_NO_DUAL_OBJECT_GS))) { c->prog_data.dual_instanced_dispatch
>> = false;
>> 
>> -      vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /*
>> no_spills */); +      vec4_gs_visitor v(brw, c, prog, shader,
>> mem_ctx, true /* no_spills */, param_count);
> 
> Another possibility would be to set 'c.prog_data.base.nr_params = 
> param_count' here and in brw_vs_emit(), so you'd have the same
> value available from the constructor of vec4_visitor without all
> the parameter changes.
> 
> It would be possible to do something similar in the fs_visitor
> code, but it seems that it would be slightly more difficult because
> the fs_visitor (ab-)uses nr_params to keep track of the most
> recently allocated uniform index, you'd need to add a private
> counter variable to the fs_visitor similar to what vec4_visitor
> does.
> 
> With the upcoming ARB_shader_image_load_store changes we might get
> more than 4 * MAX_UNIFORM uniform allocations in some cases because
> image uniforms can take up several slots for the image meta-data --
> I think it would make sense to extend this change to the FS
> back-end too.

Do you think that should get done now or as a follow-on patch?  This
fixes an existing problem, and I think we want a fix that can get
picked to the 10.0 branch and possibly earlier stable branches.

> Thanks.
> 
>> if (v.run()) { vec4_generator g(brw, prog, &c->gp->program.Base,
>> &c->prog_data.base, mem_ctx, INTEL_DEBUG & DEBUG_GS); [...] 
>> _______________________________________________ mesa-dev mailing
>> list mesa-dev at lists.freedesktop.org 
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlKPr+0ACgkQX1gOwKyEAw9vzQCdE0DAxuZF85y7wFtw1Ypg+ejo
Ft4An3msa4mkI4HU/39n9vlXoY7LrEJ2
=sUh4
-----END PGP SIGNATURE-----


More information about the mesa-dev mailing list