On Mon, Mar 29, 2010 at 10:09 PM, Tom Stellard <tstel...@gmail.com> wrote: > On Sat, Mar 27, 2010 at 02:11:54AM +0100, Marek Olšák wrote: >> >> From the driver point of view, we don't have to work on the GLSL compiler >> itself. The Mesa state tracker compiles GLSL to an assembler-like language >> called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader >> representation. The more TGSI we handle, the more GLSL support we get. >> > > Is adding support for the TGSI opcodes that are currently ignored by > r300_tgsi_to_rc.c something that needs to be done? If so, are there > some opcodes you would prefer to see done first? > >> So now the status. r300g GLSL is missing the following features: >> >> 1) Branching and looping >> >> This is the most important one and there are 3 things which need to be done. >> * Unrolling loops and converting conditionals to multiplications. This is >> crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases >> but should be fine for the most common ones. This is kind of a standard in >> all proprietary drivers supporting shaders 2.0. It would be nice have it >> work with pure TGSI shaders so that drivers like nvfx can reuse it too and I >> personally prefer to have this feature first before going on. > > Would you be able to provide a small example of how to convert the > conditionals to multiplications? I understand the basic idea is to mask > values based on the result of the conditional, but it would help me to see > an example. On IRC, eosie mentioned an alternate technique for emulating > conditionals: Save the values of variables that might be affected by > the conditional statement. Then, after executing both the if and the else > branches, roll back the variables that were affected by the branch that > was not supposed to be taken. Would this technique work as well? > > Is the conditional translation something that only needs to be done > in the Gallium drivers, or would it be useful to apply the translation > before the Mesa IR is converted into TGSI? Are any of the other drivers > (Gallium or Mesa) currently doing this kind of translation? > >> * Teaching the R300 compiler loops and conditionals for R500 fragment >> shaders. Note that R500 supports the jump instruction so besides adding new >> opcodes, the compiler optimization passes should be updated too (I think >> they haven't been designed with loops in mind). >> * The same but for R500 vertex shaders. The difference is conditionals must >> be implemented using predication opcodes and predication writes (stuff gets >> masked out). I think this only affects the conversion to machine code at the >> end of the pipeline. >> >> 2) Derivatives instructions fix >> >> It's implemented but broken. From docs: "If src0 is computed in the previous >> instruction, then a NOP needs to be inserted between the two instructions. >> Do this by setting the NOP flag in the previous instruction. This is not >> required if the previous instruction is a texture lookup." .. and that >> should be the fix. > > Is the only problem here that NOP is being inserted after texture > lookups when it shouldn't be? > >> 3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing >> >> I think this is specific to the rasterizer (RS) block in hw ([3]). >> > > For my proposal, I am thinking about a schedule that looks > something like this (in this order): > > 1) Branching and looping - 4 to 6 weeks > 2) Derivatives instructions fix - 1 to 2 weeks > 3) Adding support for priority TGSI_OPCODES - 3 to 4 weeks > 4) Perspective, flat, and centroid varying modifiers, gl_FrontFacing > and Adding support for more TGSI_OPCODES - (if there is time left)* > > *GSOC lasts for 12 weeks. > > I would appreciate feedback on the order or the time estimates in this > schedule. I am sure some of the developers will have a better idea > how long some of these tasks might take. Also, if there is something > important that I am leaving out or something not important that I have > included let me know.
This seems reasonable. The missing opcodes are all related to branches and loops, AFAIR, so you'll be working with those. Go ahead and set up your proposal on the GSoC site; we'll let you know if it needs tuning or tweaking. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
