Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Paul wrote: >> I'm getting close to merging the glsl-compiler-1 branch into the Mesa >> trunk. I did a trunk-to-branch merge today. I need to at least make >> sure the DRI drivers build (they don't right now). > > Excellent! > >> The docs/shading.html file is up to date and gives the status of the >> compiler, tips for writing shaders, etc. >> >> A few other highlights: >> >> 1. Both vertex and fragment programs are now interpreted/executed in >> software with the same code. Previously, there were separate >> interpreters in nvvertexec.c and s_fragprog.c. The new interpreter is >> in prog_execute.c. There other vertex program interpreter in >> t_vb_arbprogram.c file still exists though. It needs to be updated to >> handle the new branching/looping instructions. Though, that code might >> go away entirely too one of these days. > > All of the shading languages use the same backend? Meaning, > ARB_vertex_program, NV_vertex_program, etc.
Yes. All the various GL_NV/ARB_vertex/fragment_program/shader extensions produce the same kind of GPU/program instructions now. > If so, how much effort > would be involved in adding support for some of Nvidia's layered > low-level program extensions? Like GL_NV_gpu_program4? Well, it's a matter of expanding the parser to understand the grammer, then implementing the actual new instructions in prog_execute.c, etc. Next, you'd work on particular DRI drivers for hardware support. I think we want to get away from implementing low-level GPU program extensions in Mesa. The shading language is the way of the future. Internally though, various instructions from the low-level extensions (like IF/ELSE/ENDIF) have found there way into Mesa already in order to do shading language things. > I haven't looked at the code or docs yet, so this question may already > be answered. What level of effort is required to create a new backend > (e.g., for R300 or PowerPC or ...). It's a matter of translating Mesa's GPU instructions to the particular target. This has been done in the i965, i945, r300, etc. drivers. I haven't updated any drivers for the newer GPU instructions for conditionals, branching, looping, etc. I'm hoping others will help out with that. In practice, a lot of shaders don't have loops or conditionals and will compile into the basic GPU instructions that the DRI drivers already support. I should also note that Keith and Michael are working on another format for GPU instructions that should help bridge Mesa's generic GPU instructions to particular hardware. But that's a ways off yet. >> 2. A stand-alone GLSL compiler. At XDC, Dave Reveman mentioned that it >> would be useful for him to have a tool to convert shaders into low-level >> GPU programs, like those of GL_ARB_fragment_program. It occured to me >> that it would be possible to write a Mesa driver (an executable, >> actually) that would just compile shaders and emit GPU programs. So, I >> wrote a driver to do just that. It's also described in the >> docs/shading.html file. > > That's very cool. I know that the OpenGL ES people were talking about a > binary interface with a stand-alone compiler. This might form the basis > of something like that. That is, the compiler creates some intermediate > representation and emits that. At run-time the application submits the > intermediate code instead of source. Yes, I think there's lots of potential uses for this compiler. -Brian ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
