[PATCH 0/1] MR2260: wined3d: Initialise GLSL outputs to avoid nVidia warning
nVidia's GLSL compiler spits out a warning if a value is potentially used without being initialized. This affects many of wined3d's GLSL shaders, as either some element of the (e.g.) vs_out array are not initialized, or individual vector components remain unwritten to. As a quick way of working around this, initialize all vs_out, gs_out, and temporary Rn registers to vec4(0,0,0,0). This gets rid of all of the warnings in the cases I tried. (A more complete solution would probably track if we're initialising these, and only add what is required. Or would just disable the warning somehow.) Some example warnings (from a shader in the 'Pharaoh: A New Era' demo): ``` 0264:fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #3: 0264:fixme:d3d_shader:print_glsl_info_log Vertex info 0264:fixme:d3d_shader:print_glsl_info_log ----------- 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[2].zw" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[5].w" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[7]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[8]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[9]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[10]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[11]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[12]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[13]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[14]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[15]" might be used before being initialized ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260
From: David Gow <david(a)ingeniumdigital.com> nVidia's GLSL compiler spits out a warning if a value is potentially used without being initialized. This affects many of wined3d's GLSL shaders, as either some element of the (e.g.) vs_out array are not initialized, or individual vector components remain unwritten to. As a quick way of working around this, initialize all vs_out, gs_out, and temporary Rn registers to vec4(0,0,0,0). This gets rid of all of the warnings in the cases I tried. (A more complete solution would probably track if we're initialising these, and only add what is required. Or would just disable the warning somehow.) Some example warnings (from a shader in the 'Pharaoh: A New Era' demo): 0264:fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #3: 0264:fixme:d3d_shader:print_glsl_info_log Vertex info 0264:fixme:d3d_shader:print_glsl_info_log ----------- 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[2].zw" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[5].w" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[7]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[8]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[9]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[10]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[11]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[12]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[13]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[14]" might be used before being initialized 0264:fixme:d3d_shader:print_glsl_info_log 0(28) : warning C7050: "vs_out[15]" might be used before being initialized --- dlls/wined3d/glsl_shader.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c index 594fdf73f46..d7249e6eed5 100644 --- a/dlls/wined3d/glsl_shader.c +++ b/dlls/wined3d/glsl_shader.c @@ -2515,7 +2515,7 @@ static void shader_generate_glsl_declarations(const struct wined3d_context_gl *c if (reg_maps->temporary_count) { for (i = 0; i < reg_maps->temporary_count; ++i) - shader_addline(buffer, "vec4 R%u;\n", i); + shader_addline(buffer, "vec4 R%u = vec4(0.0, 0.0, 0.0, 0.0);\n", i); } else if (version->major < 4) { @@ -8072,6 +8072,13 @@ static GLuint shader_glsl_generate_vertex_shader(const struct wined3d_context_gl shader_addline(buffer, "vs_in[%u] = vs_in%u;\n", e->register_idx, e->register_idx); } } + if (shader->limits->packed_output) + { + for (i = 0; i < shader->limits->packed_output; ++i) + { + shader_addline(buffer, "vs_out[%u] = vec4(0.0, 0.0, 0.0, 0.0);\n", i); + } + } if (FAILED(shader_generate_code(shader, buffer, reg_maps, &priv_ctx, NULL, NULL))) return 0; @@ -8402,6 +8409,10 @@ static GLuint shader_glsl_generate_geometry_shader(const struct wined3d_context_ } shader_addline(buffer, "void main()\n{\n"); + for (i = 0; i < shader->limits->packed_output; ++i) + { + shader_addline(buffer, "gs_out[%u] = vec4(0.0, 0.0, 0.0, 0.0);\n", i); + } if (shader->function) { if (FAILED(shader_generate_code(shader, buffer, reg_maps, &priv_ctx, NULL, NULL))) -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/2260
I'm not 100% convinced this is the right way to solve this, but the log spam was annoying me, so it's here if you want it. No worries if you'd rather a more proper fix, though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_25152
Yeah, I'd be tempted to argue this is not our problem to fix. I remember looking at these in the past, and IIRC the issue the NVIDIA GLSL compiler is warning about exists in the original shaders. An argument could also be made that the warnings in question are a bit overzealous; ideally there would be some "#pragma optionNV()" we could use to just turn these off, although I'm not aware of one. We do have quirk_infolog_spam(), originally created for FGLRX we could use for this... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_25155
I don't object to fixing this (nor do I object to leaving it alone, frankly) but I'm kind of inclined to agree it's better to just silence the warning on nvidia rather than modifying the byte code. That said... I kind of wonder if we could avoid it by just not passing vs_out as an input parameter? Since it's a global variable, do we even need to do that in the first place? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_25454
Not our bug, but if it annoys our users.. if a more satisfying solution isn't put forward, I think it's reasonable to work around it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_25743
That said... I kind of wonder if we could avoid it by just not passing vs_out as an input parameter? Since it's a global variable, do we even need to do that in the first place?
Ah, because we compile the setup_vs_output() function as a separate GL shader for sm3 (and only sm3). That's annoying, maybe we could stop doing that? Or would that end up being too expensive... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_25951
That said... I kind of wonder if we could avoid it by just not passing vs_out as an input parameter? Since it's a global variable, do we even need to do that in the first place?
Ah, because we compile the setup_vs_output() function as a separate GL shader for sm3 (and only sm3). That's annoying, maybe we could stop doing that? Or would that end up being too expensive...
Possibly, although we'd potentially introduce more shader variants. Note that this isn't just about vs_out[] and gs_out[] though, there are warnings about temporaries too. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_26017
Possibly, although we'd potentially introduce more shader variants. Note that this isn't just about vs_out\[\] and gs_out\[\] though, there are warnings about temporaries too.
Hmm, I don't recall those offhand, do you have an example? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_26018
Possibly, although we'd potentially introduce more shader variants. Note that this isn't just about vs_out\[\] and gs_out\[\] though, there are warnings about temporaries too.
Hmm, I don't recall those offhand, do you have an example?
I don't, but it's mentioned in the MR description, and I do remember seeing those back in the day. IIRC the kind of thing that typically happens is that e.g. the first two components of a register are initialised, then the entire register is copied/swizzled, and ultimately the uninitialised components end up being discarded/unused. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_26019
Possibly, although we'd potentially introduce more shader variants. Note that this isn't just about vs_out\[\] and gs_out\[\] though, there are warnings about temporaries too.
Hmm, I don't recall those offhand, do you have an example?
I don't, but it's mentioned in the MR description, and I do remember seeing those back in the day. IIRC the kind of thing that typically happens is that e.g. the first two components of a register are initialised, then the entire register is copied/swizzled, and ultimately the uninitialised components end up being discarded/unused.
Ah, yeah, that seems distinctly harder to work around, if at all possible. I guess we should just silence the warnings after all. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2260#note_26025
participants (5)
-
David Gow -
David Gow (＠sulix)
-
Henri Verbeet (＠hverbeet)
-
Jan Sikorski (＠jsikorski)
-
Zebediah Figura (＠zfigura)