http://bugs.winehq.org/show_bug.cgi?id=17437
--- Comment #25 from KeithG keith@penguingurus.com 2009-03-03 14:53:26 --- (In reply to comment #24)
addressing in the shader. If the shader does use all 256 uniforms we're still screwed of course.
yep. But I would assume this would be a case that is theoretical only. As you'd be using all available uniforms just for that shader with no other possible allocations. There was probably a better way to write that shader in the first place. If it truly needs all that room then it needs a higher class of card.
As for working around incorrectly advertised varyings: If we do that, this should be integrated with the card detection. E.g. for each PCI ID we detect in the card detection, we could store info such as this:
- Number of GLSL uniforms and varyings we expect the driver to advertise
- Number of ARB constants
- Number of uniforms and varyings that are really supported
- Use ARB values, GLSL values or hardcoded values?
if ( driver_advertised > expected_values) wine_values = driver_adverstised else WARN("gl driver advertised values are under spec'd for this card") wine_values = expected_values
5) card is not detected by wine (newer gpu or older version of wine), driver under reports values. What happens in this case? Does it take a patch / recompile to fix or is there some other way of reporting proper values to wine until its sorted aka, newer version of wine with the new gpu detected.
One important thing is that every workaround is built on some assumptions. The code should be able to detect when the assumptions aren't true any longer(e.g. driver update fixed the bug), and issue a warning. A workaround + a fixed driver might lead to new bugs.
As far as my patch goes.. its a hack to make it work. Nothing more. I don't have the understanding the material to make any kind of intelligent remarks beyond the very basic. Other than, like everyone else on the cc list, we have a vested interested in making it work *somehow* :)
I tried adding back the reservations of the ints / bools during the process of building the shader string buffer. And while I was able to get it to compile and link shaders successfully. It still never provided rendered models. I assumed at that point the maxF value was used to set something up the stack that would not allow the models to be displayed.
This eventually morphed into... not reserving until ints were called for within baseshader.c and I wanted something quick and dirty. So the yes/no provided that. Modifying the maxF within the shader.limits. struct at that point allowed the models to render properly and removed the issue above.
I'm just glad someone at codeweavers / wine proper is working on it at this point.