Petri Latvala <petri.latv...@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.
Thanks.
> if (v.run()) {
> vec4_generator g(brw, prog, &c->gp->program.Base,
> &c->prog_data.base,
> mem_ctx, INTEL_DEBUG & DEBUG_GS);
>[...]
pgpt3d5HdM9K6.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
