[1/7] [wined3d] move creation of NP2 fixup uniforms into separate loop (retry)

Tobias Jakobi 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 
> university.
OK, I'll wait then. Thanks again Stefan for explaining this!


More information about the wine-devel mailing list