https://bugs.winehq.org/show_bug.cgi?id=41213
--- Comment #7 from Jason Wood sandain@hotmail.com --- (In reply to Matteo Bruni from comment #6)
Actually it isn't, see gl_info->limits.fragment_samplers in wined3d_adapter_init_limits(). MAX_FRAGMENT_SAMPLERS is used as an upper bound though and the reason is that there are a number of data structures and bitmasks in wined3d which are statically sized (the masks would need to be updated to account for the change, btw). In turn, some of those really shouldn't depend on the d3d max sampler count (e.g. resource_info in struct wined3d_shader_reg_maps) but on the max resource count. That's because of historical reasons i.e. the two values happened to match for d3d <= 9.
In the end, raising MAX_FRAGMENT_SAMPLERS probably isn't the correct fix for the bug, this would need more work.
It is exactly the statically sized data structures defined in wined3d_private.h that I was speaking of when I was talking about the value being hard coded. I imagine anything that utilizes any of the values listed under /* Device caps */ (line 179) to define the size of a data structure is probably going to hit a similar issue as reported here, particularly with the MAX_FRAGMENT_SAMPLERS as already mentioned, MAX_VERTEX_SAMPLERS, and MAX_COMBINED_SAMPLERS constants.
Would it be possible to switch to run-time initialization of these structs? Or maybe reallocate the stucts once the device caps are known? Since I am unfamiliar with the code base and I'm not sure what masks would need to be updated, I'll probably defer any further work on this to someone that knows the code. I might keep poking around since it would be nice to have a real fix for this issue, but I doubt that I'll make much progress.