On Tue, Mar 30, 2010 at 7:09 AM, 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?
>
One of the goals might be to pass all relevant piglit tests including
glean/glsl1 which exercises various opcodes but it's not so important and
I'd be surprised if you would make it in your timeframe. You may use it for
testing though.
> > 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?
>
Well, I am eosie, thanks for the info, it's always cool to be reminded what
I've written on IRC. ;)
Another idea was to convert TGSI to a SSA form. That would make unrolling
branches much easier as the Phi function would basically become a linear
interpolation, loops and subroutines with conditional return statements
might be trickier. The r300 compiler already uses SSA for its optimization
passes so maybe you wouldn't need to mess with TGSI that much...
> 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?
>
Not that I know of. You may do it wherever you want theoretically, even in
the r300 compiler and leaving TGSI untouched, but I think most people would
appreciate if these translation were done in TGSI.
> > * 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?
>
Well the derivatives don't work and NOP is not being inserted anywhere. The
quoted statement from the docs was supposed to give you a clue. NOP after a
texture lookup is *not required*, that means it would be just silly to put
it there but it shouldn't break anything.
-Marek
------------------------------------------------------------------------------
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
