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! Greets, Tobias