Hello, thank you for your feedback :) I just sent a patch that fixes the NaN issue in all places it can happen (at least in the GLSL backend). Well, stupid drivers... It seems to work really well with Mesa, but I just saw some 1 fps benchmarks, so I guess it's a *nope*. I'll do a test to make you happy, and try to fix the other things. :)
<div>-------- Message d'origine --------</div><div>De : Józef Kucia joseph.kucia@gmail.com </div><div>Date :13/06/2016 20:32 (GMT+01:00) </div><div>À : wine-devel wine-devel@winehq.org </div><div>Cc : Guillaume Charifi guillaume.charifi@sfr.fr </div><div>Objet : Re: [PATCH] wined3d: Implement icb dcl support in GLSL. </div><div> </div>This implementation has some issues, e.g. a generated GLSL shader will produce a compilation error when the immediate constant buffer contains an unsigned integer which represents NaN. Morever, from testing a similar implementation, it seems that some drivers don't handle shaders with huge arrays very well and such shaders perform poorly. My current impression is that we should implement immediate constant buffers using a uniform variable.
Also, a test would be nice.
On Mon, Jun 13, 2016 at 6:41 PM, Guillaume Charifi guillaume.charifi@sfr.fr wrote:
Signed-off-by: Guillaume Charifi guillaume.charifi@sfr.fr
dlls/wined3d/glsl_shader.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c index 55affc1..def224c 100644 --- a/dlls/wined3d/glsl_shader.c +++ b/dlls/wined3d/glsl_shader.c @@ -1886,6 +1886,19 @@ static void shader_generate_glsl_declarations(const struct wined3d_context *cont if (shader->limits->constant_bool > 0 && reg_maps->boolean_constants) shader_addline(buffer, "uniform bool %s_b[%u];\n", prefix, shader->limits->constant_bool);
- if (reg_maps->icb)
- {
shader_addline(buffer, "const vec4 %s_icb[%u] = vec4[%u](\n",
prefix, reg_maps->icb->element_count / 4, reg_maps->icb->element_count / 4);
for (i = 0; i < reg_maps->icb->element_count / 4; i++) {
shader_glsl_append_imm_vec4(buffer, (float *)®_maps->icb->data[4 * i]);
if (i != reg_maps->icb->element_count / 4 - 1)
shader_addline(buffer, ",");
shader_addline(buffer, "\n");
}
shader_addline(buffer, ");\n");
- }
I think it would be better to store the number of vectors instead of the element count in "reg_maps->icb". Not that it matters much, but this block of code would certainly look nicer.
- for (i = 0; i < WINED3D_MAX_CBS; ++i) { if (reg_maps->cb_sizes[i])
@@ -8561,7 +8574,7 @@ static const SHADER_HANDLER shader_glsl_instruction_handler_table[WINED3DSIH_TAB /* WINED3DSIH_DCL_GLOBAL_FLAGS */ shader_glsl_nop, /* WINED3DSIH_DCL_HS_FORK_PHASE_INSTANCE_COUNT */ NULL, /* WINED3DSIH_DCL_HS_MAX_TESSFACTOR */ NULL,
- /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ NULL,
- /* WINED3DSIH_DCL_IMMEDIATE_CONSTANT_BUFFER */ shader_glsl_nop, /* WINED3DSIH_DCL_INPUT */ shader_glsl_nop, /* WINED3DSIH_DCL_INPUT_CONTROL_POINT_COUNT */ NULL, /* WINED3DSIH_DCL_INPUT_PRIMITIVE */ shader_glsl_nop,
-- 2.7.4
Hello,
On Mon, Jun 13, 2016 at 11:32 PM, Guillaume Charifi guillaume.charifi@sfr.fr wrote:
Hello, thank you for your feedback :) I just sent a patch that fixes the NaN issue in all places it can happen (at least in the GLSL backend). Well, stupid drivers... It seems to work really well with Mesa, but I just saw some 1 fps benchmarks, so I guess it's a *nope*. I'll do a test to make you happy, and try to fix the other things. :)
Yeah, it should be quite easy to implement immediate constant buffers using a uniform variable, and I believe it'll save us some problems.