https://bugs.winehq.org/show_bug.cgi?id=43118
--- Comment #3 from Henri Verbeet hverbeet@gmail.com --- (In reply to Emil Lauridsen from comment #2)
Does this ring any bells for anybody with knowledge of the wine d3d implementation?
Mostly just "You get to keep all the pieces if it breaks." and "This is why I avoid proprietary drivers.", I'm afraid.
We keep arb_program_shader.c around because some people find it useful and it's not too obnoxious to keep around, but it isn't really being maintained and may be broken in subtle or not so subtle ways at any given time. Likewise, a significant amount of time is spent in the driver, and without driver source you're left making guesses at what might be going on.
That said, you may want to check whether the issue is that compilation time of individual shaders is unreasonably large, or if instead the issue is that we're generating an unreasonable number of shader variants. In the latter case, "shader_data->num_gl_shaders" in e.g. find_arb_vshader() being large would be a hint in that direction.
Also, are you sure you're actually getting the Direct3D 11 renderer? ARB program shaders don't implement shader model 4 and up. Somewhat related, how "clean" is that profile? I see references to both shader_glsl_select() and shader_arb_select() in there, which shouldn't normally happen within the same process.