<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="FI" link="blue" vlink="purple"> <div class="WordSection1"> Hello all,<o:p></o:p> <o:p> </o:p> I am new to Mesa development (and in particular the i965 driver). I am currently trying to gain an understanding of Mesa’s implementation with mostly an eye on (just) the i965 driver. Some questions:<o:p></o:p> <o:p> </o:p> There are some docs in docs, how up to date are those documents? In particular I saw this: ( from User Topics/Shading Language on the side bar)<o:p></o:p> <o:p> </o:p> a. Shading language programs are compiled into low-level programs very similar to those of GL_ARB_vertex/fragment_program.<o:p></o:p> b. All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full float[4] registers.<o:p></o:p> c. Float constants and variables are packed so that up to four floats can occupy one program parameter/register.<o:p></o:p> d. All function calls are inlined.<o:p></o:p> e. Shaders which use too many registers will not compile.<o:p></o:p> f. The quality of generated code is pretty good, register usage is fair.<o:p></o:p> g. Shader error detection and reporting of errors (InfoLog) is not very good yet.<o:p></o:p> h. The ftransform() function doesn't necessarily match the results of fixed-function transformation.<o:p></o:p> <o:p> </o:p> My questions are:<o:p></o:p> <![if !supportLists]>1. <![endif]>for item (a), I thought Mesa was using a custom IR that sorted of looked like LISP, is that correct? Is (a) even correct? For that matter where does the assembly style shader magicks fit in? [even though the asm interface is old, it is used in common user-oriented games, like Doom3 for example]. Additionally, there are extensions out there that update the asm interface for GL3 and GL4 features. Are those extensions already implemented in Mesa?<o:p></o:p> <![if !supportLists]>2. <![endif]>my question for item (b) mostly concerns the i965 driver. First a disclaimer: I am quite *new* so some of my starting points might be utterly wrong. My understanding of the i965 so far is that it strongly prefers to work with SIMD commands (I guess operating on vec4’s typically). One idea is that compiling of fragment shaders would break all operations down to scalar operations and then the shader would be re-assembled to process 4 fragments at a time by “combining” the shader commands of 4 fragments from 4 scalar ops into one vec4 op. Is this already done? [I have memory of seeing a slide from Ian R. that the i965 driver draws 8(or was it 4) pixels “at a time”].<o:p></o:p> <![if !supportLists]>3. <![endif]>related to (d), but not exactly the same: how are branches related to (non-unrollable) loops handled? in particular nested loops?<o:p></o:p> <o:p> </o:p> There is also some doxygen stuff found in doxygen, some of it (for example glapi.doxy) seems to being suffering from bit rot (for glapi.doxy it points to a directory that does not even exist anymore). On a related note, where are the beans about the dispatch table? <o:p></o:p> <o:p> </o:p> Also, is src/mesa/state_tracker part of Mesa main or Gallium stuff? Taking a quick, non-careful look, it looks like state tracking is handled by bits running around in mesa/main, is that correct?<o:p></o:p> <o:p> </o:p> What is the general rule of thumb of code that belongs in mesa/main vs further down to the drivers/dri/XXX (for me XXX-i965).<o:p></o:p> <o:p> </o:p> Best Regards<o:p></o:p> -Kevin Rogovin <o:p></o:p> <o:p> </o:p> <o:p></o:p> </div> --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.</body> </html>