[1/7] [wined3d] move creation of NP2 fixup uniforms into separate loop (retry)
liquid.acid at gmx.net
Fri Apr 24 14:49:16 CDT 2009
Stefan Dösinger wrote:
>> I think Henri is generally against adding something to the
>> ps_compiled_shader structure - but I might be wrong there.
>> However I don't know how to implement the code without introducing new
>> data to ps_compiled_shader.
> No, he doesn't like having this info visible outside the backend. You can
> certainly introduce new per-compiled-gl shader information, but it should not
> be 'visible' outside the respective shader backend. So in an ideal world your
> patchset would not touch wined3d_private.h, only glsl_shader.c, and later
> arb_program_shader.c, since all the NP2 fixup interfaces the backend needs
> are already in place.
OK, I totally misunderstood him then. Sry Henri!!
> In the past we've done a considerable amount of work to separate the shader
> backend implementations from the rest of the code. E.g. the ps_compile_args
> structure is part of that(avoids direct stateblock accesses), Henri moved
> parsing the D3D bytecode into the frontend(the backends operate on
> bytecode-independent structures), etc. The goals are an abstraction from the
> bytecode to enable d3d10 support, the stateblock separation allowed shader
> duplication, etc. However, the work is not entirely done yet,
> I can implement the modification of ps_compiled_shader so you can add your
> data structures properly. An example of what it should more or less look like
> is the fragment pipeline replacement - e.g. the ATIFS specific structures are
> all defined in ati_fragment_shader.c, and all the frontend offers is a void *
> to store a pointer in the device. The question is obviously when I'll get to
> it, as I still have to play around with that java-jboss-whatever stuff for
OK, I'll wait then. Thanks again Stefan for explaining this!
More information about the wine-devel