http://bugs.winehq.org/show_bug.cgi?id=14762
--- Comment #53 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-01 17:24:13 ---
PROBLEM: What's the easiest way to get access to the ps_compile_args structure inside shader_arb_load_constants. Wasn't a big thing with GLSL, but I'm not really sure which structure that is available from inside the function leads me to ps_compile_args.
I've no quick idea. The idea behind the compile_args struct is to be used only during compilation, so the answer is probably you don't access it(neither in GLSL, although there it is easy to use it). Probably fetch some values from the stateblock, and/or shadow them in the compiled_shader structure.
(actually, you may access the compile_args struct in a compiled_shader member, but don't try to access the same pointer that is passed to compile_shader)
(4) Not sure about this: gen_arbfp_ffp_shader. Since it contains texture sampling instructions that can encounter RECT types, it should probably be changed as well, right?
You don't have to do anything there necessarily. The vertex pipeline is supposed to take care of this if no d3d pixel shader is used.
However, you could add some fixup code there too instead of fixing the coords in the vertex shader. Note that for fully correct operation you still need to be able to handle the fixups in the vertex shader, but keeping it in the pixel shader and fp ffp replacement may be easier and keep the state management simpler. If it keeps the code simpler I'd be willing to say that an ffp replacement is needed for proper RECT operation with vertex shaders(all cards that have vshaders have either atifs, arbfp or nvts) The question is how this affects performance. We're adding extra instructions and probably a dependent read to the fragment processing, but avoid interdependencies between vertex and fragment pipeline.
I also don't know if we can handle the RECT fixup in atifs or nvts. They only have 8 instructions and 8 constants, and may not even be able to perform dependent reads on RECT textures.