-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Ian Romanick wrote: >>> >>> 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.
That's music to my ears. :) >> 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 was thinking along the lines of GL_NV_vertex_program[23] and GL_NV_fragment_program2. Having support for some of the newer Nvidia EXT and NV extensions in software Mesa would be very nice. Man...I need to get back to doing work on Mesa... > 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. True. However, if we can support some of the existing assembly language interfaces for the meager cost of a parser, it seems worth it. Besides, there's a part of me that really wants to see GL_NV_vertex_program2, etc. running on ATI hardware. >:) > 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. At one point you had mentioned using (creating?) a backend generator. Did anything ever happen 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFF3ynAX1gOwKyEAw8RAvr1AJsFQTw8EwpyI29YA9RC0Kt9pYtBSwCdG9Sx B+w9nD8HnxEBCwl/cieZHH8= =sS7a -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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
