-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeffrey Timanus wrote:
> I've searched around the mesa site, and the sourceforge project site, but > I did not come across any specific information with regards to the current > status of implementing GLSL within MESA. Is this an active goal? Yes and no. There is working being done on some of the necessary infrastructure (see below), but no work is being done on GLSL specifically at this time. > I suppose since mesa already supports vertex and fragment programs, only a > compiler from GLSL to these targets is required. (As opposed to a full > programmable hardware emulator . . . ) The current support for vertex and fragment programs is missing quite a bit of functionality that GLSL would need. For example, branches and subroutine calls are not currently supported. I'm currently working with a group of students at Portland State University to create a *full* compiler backend for their final-year project. The goal is to fully support all of the existing vertex assembly programming extensions. The relevence is that GL_NV_vertex_program2_option adds support to GL_ARB_vertex_program for both branches and subroutine calls. The ultimate goal is to be able to plug other language frontends (e.g., GLSL and / or Cg) into the backend. The interface between the two would just be the IR used by the compiler backend. > I'm also interested in volunteering myself to help with any GLSL > implementations. Is there any documentation online to help me figure out > what efforts need the most help? There are a couple things that could be done to pave the way for GLSL support. The first would be to review IR documents (should be available soon?) for the vertex program project. We'll want to make note of any deficencies in the IR. I doubt the group will have time to do too much about any such problems now. The other would be to get the 3dlabs GLSL frontend into shape. I'd be very interested in exploring converting the GLSL frontend into a shared library. The compiler would then load the library for the appropriate language frontend, call into it to conver the source to the compiler's IR, then build the IR into the proper machine code (either for the host CPU or the GPU). Structuring it in this way should make it easier to take new code drops from 3dlabs, and would reduce the space required by N different drivers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDjj6UX1gOwKyEAw8RAtsIAJ9CsLNqkiZn46JOLEiyJlEEB8pgNgCeJRM5 NmvMEdWiJY0CdmGNP4gwWT0= =tlK/ -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
