Brian Paul wrote: > Ian Romanick wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Brian Paul wrote: >>> Ian Romanick wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Brian Paul wrote: >>>>> I'd like to release Mesa 6.5.3 pretty soon (to be considered a >>>>> development release) then follow up fairly quickly with a Mesa 7.0 >>>>> release. The jump to 7.0 would indicate the jump to OpenGL 2.x API >>>>> support. >>>> Woohoo! >>>> >>>>> I might cut a pre-release candidate today... >>>> Will either of these releases include the glsl-compiler-1 work? >>> Yes, that branch was merged to master a while ago. >> D'oh! How did I miss that? Must have been asleep at the keys... >> >> Anyway, I started looking at the code a bit this morning. Do you have >> any advice for where a person might insert a processor-specific compiler >> back-end? It looks like I could just hook in at _mesa_execute_program, >> but I'm wondering if there's a better place. > > Well, in device drivers that generate a specific GPU program from Mesa's > generic GPU rograms, this usually happens during state validation. > > Alternately, the driver can use the ctx->Driver.ProgramStringNotify() > hook which is called after the text program string has been compiled > into instructions (though, I see I'm not calling that from the GLSL > compiler - oops). > > The decision there is whether you want to translate the program when > it's compiled, or when it's first used. > > But if you want to do something driver-independent, you probably can't > use ProgramStringNotify() because you might collide with the driver's > use of it. > > I'm thinking we might need to implement a callback manager so that any > number of modules could register a callback to get informed of newly > compiled programs.
In recent drivers I've moved away from the callbacks almost entirely - with the exception of the program string and buffer object callbacks, which have a different character to the regular state-change callbacks in that they are more like virtual functions on the objects themselves. > The other thing is program/shader linking. Linking often involves > changing register indexes. The simplest thing to do there is to > regenerate the derived programs (from scratch) after linking. A more > sophisticated approach would be to pass the linking information to the > driver/translator so it could do the relocations, etc. The first approach is ok to start with, I think we need to get more experience using these programs before going too deep. As a general idea, though, I'd prefer for the programs which the driver sees to become constant objects - ie from the drivers perspective, delete the old one and create a new one from scratch rather than issuing a program string notification. Keith ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
