On 12/13/2011 02:12 PM, Jose Fonseca wrote:
----- Original Message -----
On 12/13/2011 03:48 PM, Jose Fonseca wrote:
----- Original Message -----
On 12/13/2011 03:25 PM, Jose Fonseca wrote:
----- Original Message -----
On 12/13/2011 03:09 PM, Jose Fonseca wrote:
----- Original Message -----
On 12/13/2011 12:26 PM, Bryan Cain wrote:
On 12/13/2011 02:11 PM, Jose Fonseca wrote:
----- Original Message -----
This is an updated version of the patch set I sent to the
list
a
few
hours
ago.
There is now a TGSI property called
TGSI_PROPERTY_NUM_CLIP_DISTANCES
that drivers can use to determine how many of the 8
available
clip
distances
are actually used by a shader.
Can't the info in TGSI_PROPERTY_NUM_CLIP_DISTANCES be easily
derived from the shader, and queried through
src/gallium/auxiliary/tgsi/tgsi_scan.h ?
No. The clip distances can be indirectly addressed (there
are
up
to 2
of them in vec4 form for a total of 8 floats), which makes it
impossible
to determine which ones are used by analyzing the shader.
The description is almost complete. :) The issue is that the
shader
may
declare
out float gl_ClipDistance[4];
the use non-constant addressing of the array. The compiler
knows
that
gl_ClipDistance has at most 4 elements, but post-hoc analysis
would
not
be able to determine that. Often the fixed-function hardware
(see
below) needs to know which clip distance values are actually
written.
But don't all the clip distances written by the shader need to
be
declared?
E.g.:
DCL OUT[0], CLIPDIST[0]
DCL OUT[1], CLIPDIST[1]
DCL OUT[2], CLIPDIST[2]
DCL OUT[3], CLIPDIST[3]
therefore a trivial analysis of the declarations convey that?
No. Clip distance is an array of up to 8 floats in GLSL, but
it's
represented in the hardware as 2 vec4s. You can tell by
analyzing
the
declarations whether there are more than 4 clip distances in
use,
but
not which components the shader writes to.
TGSI_PROPERTY_NUM_CLIP_DISTANCES is the number of components in
use,
not
the number of full vectors.
Lets imagine
out float gl_ClipDistance[6];
Each a clip distance is a scalar float.
Either all hardware represents the 8 clip distances as two 4
vectors, and we do:
DCL OUT[0].xywz, CLIPDIST[0]
DCL OUT[1].xy, CLIPDIST[1]
using the full range of struct tgsi_declaration::UsageMask [1] or
we represent them as as scalars:
DCL OUT[0].x, CLIPDIST[0]
DCL OUT[1].x, CLIPDIST[1]
DCL OUT[2].x, CLIPDIST[2]
DCL OUT[3].x, CLIPDIST[3]
DCL OUT[4].x, CLIPDIST[4]
DCL OUT[5].x, CLIPDIST[5]
If indirect addressing is allowed as I read bore, then maybe the
later is better.
I confess my ignorance about clipping and maybe I'm being dense,
but I still don't see the need for this
TGSI_PROPERTY_NUM_CLIP_DISTANCES. Could you please draft an
example TGSI shader showing this property (or just paste one
generated with your change)? I think that would help a lot.
Jose
[1] I don't know if tgsi_dump pays much attention to
tgsi_declaration::UsageMask, but it does exist.
UsageMask might work, but before that can be considered a viable
solution, someone will need to make it possible to actually
declare
it
from ureg. As it is, ureg is hardcoded to set UsageMask to xyzw
no
matter what on all declared inputs and outputs.
ureg automatically fills the UsageMask from the destionation
register masks, since it easy to determine from the opcodes.
Which leads me to my second point, if indirect addressing of
CLIPDIST is allowed, then we can't really pack the clip distance
as 4-elem vectors in TGSI: not only the syntax would be very
weird, but it would create havoc on all tgsi-translating code that
makes decisions based on indirect addressing of registers.
That is,
float gl_ClipDistance[6];
gl_ClipDistance[i] = foo;
would become
DCL OUT[0].x, CLIPDIST[0]
DCL OUT[1].x, CLIPDIST[1]
DCL OUT[2].x, CLIPDIST[2]
DCL OUT[3].x, CLIPDIST[3]
DCL OUT[4].x, CLIPDIST[4]
DCL OUT[5].x, CLIPDIST[5]
MOV OUT[ADDR[0].x].x, foo
and the info from TGSI_PROPERTY_NUM_CLIP_DISTANCES can be obtained
by walking the declaration (which can/should be done only once in
tgsi_scan).
But this just doesn't look like it would ever work:
DCL OUT[0].xyzw, CLIPDIST[0]
DCL OUT[1].xy , CLIPDIST[1]
MOV OUT[ADDR[0].x].????, foo
Jose
If ureg automatically fills the UsageMask from the accessed
components,
it's probably a better solution than the property.
About the indirect addressing of components: the GLSL compiler lowers
indirect addressing of the gl_ClipDistance array to indirect
addressing
of the 2 vec4s, combined with conditional moves to the different
components. Which is okay, because although indirect addressing of
gl_ClipDistance is allowed by the GLSL specification, meaning have to
support it, it's not something that's actually useful in practical
situations.
It sounds a bit complicated -- the lowered indirect addressing code will
certainly result in inefficient code for software rendering (e.g, draw module +
llvm), but that alone is probably not reason to be different. Could everybody
confirm that all hardware uses 2 vec4s for clip distances and is not able to
natively do indirect addressing?
Those are (or should be) orthogonal. For example, i965 uses vec4[2],
but it can indirect access components of a vector. We don't do that
yet, but we could. I don't know if there's a way to represent that in
TGSI, but it can be represented in the GLSL IR. We just have two
separate lowering passes. One does the float[]->vec4[] conversion, and
the other does the vec4 indexing conversion.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
