Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 16.12.2011 19:27, Ian Romanick wrote: On 12/13/2011 05:08 PM, Christoph Bumiller wrote: On 12/14/2011 12:58 AM, Ian Romanick wrote: On 12/13/2011 01: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. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. GeForce8+ = scalar architecture, no vectors, addresses are byte based, can access individual components just fine. Something like: gl_ClipDistance[i - 12] = some_value; DCL OUT[0].xyzw, POSITION DCL OUT[1-8].x, CLIPDIST[0-7] MOV OUT1[ADDR[0].x - 12].x, TEMP[0]. * ** * - tgsi_dimension.Index specifying the base address by referencing a declaration ** - tgsi_src_register.Index is the only way I see to make this work nicely on all hardware. (This is also needed if OUT[i] and OUT[i + 1] cannot be assigned to contiguous hardware resources because of semantic.) For constrained hardware the driver can build the clunky c := ADDR[0].x % 4 i := ADDR[0].x / 4 IF [c == 0] MOV OUT[i].x, TEMP[0]. ELSE IF [c == 1] MOV OUT[i].y, TEMP[0]. ELSE IF [c == 2] MOV OUT[i].z, TEMP[0]. ELSE MOV OUT[i].w, TEMP[0]. ENDIF itself. Doing it at that low-level has a number of significant drawbacks. The worst is that it's long after any high-level optimizations can be done on the code. It also means that it has to be reimplemented in every driver that needs. This really belongs at a higher level in the code. Note that lowering pass that already exists changes the accesses to 'float gl_ClipDistance[8]' to 'vec4 gl_ClipDistanceMESA[2]'. Is there a compelling reason to not do the same at the lower level? Of course, we can add a CAP/option to let the driver choose whether it wants a TGSI array or some pass at a higher level to lower the assignment. I'd just like TGSI to be extended to be able to express what's *actually* going on so I can produce my simple: shl $r0, constbuf0[0], 2 store out[$r0+0x270], $r1 (0x270-0x28c are fixed locations for clip distances) for gl_ClipDistance[uniform int i] = some_value; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- Original Message - On 12/14/2011 12:58 AM, Ian Romanick wrote: On 12/13/2011 01: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. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. GeForce8+ = scalar architecture, no vectors, addresses are byte based, can access individual components just fine. Ok. So we should avoid baking this vec4 assumption in TGSI semantics. Something like: gl_ClipDistance[i - 12] = some_value; DCL OUT[0].xyzw, POSITION DCL OUT[1-8].x, CLIPDIST[0-7] MOV OUT1[ADDR[0].x - 12].x, TEMP[0]. * ** * - tgsi_dimension.Index specifying the base address by referencing a declaration ** - tgsi_src_register.Index is the only way I see to make this work nicely on all hardware. (This is also needed if OUT[i] and OUT[i + 1] cannot be assigned to contiguous hardware resources because of semantic.) I think that having indexable temps, like D3D10, would be a cleaner: DCL OUT[0].xyzw, POSITION DCL OUT[1][0-7].x, CLIPDIST[0-7] MOV OUT[1][ADDR[0].x - 12].x, TEMP[0]. I propose we first add this new kind of temp at a first stage, then prohibit indirect addressing of all but this kind of temps. For constrained hardware the driver can build the clunky c := ADDR[0].x % 4 i := ADDR[0].x / 4 IF [c == 0] MOV OUT[i].x, TEMP[0]. ELSE IF [c == 1] MOV OUT[i].y, TEMP[0]. ELSE IF [c == 2] MOV OUT[i].z, TEMP[0]. ELSE MOV OUT[i].w, TEMP[0]. ENDIF itself. Sounds good plan to me. BTW, I took a look at inputs/outputs UsageMasks and although we don't use them, I really think we really should, as having that info readily accessible would allow to avoid wasting time/bandwidth copying attributes which are not needed. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- Original Message - 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
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 15.12.2011 20:09, Jose Fonseca wrote: - Original Message - On 12/14/2011 12:58 AM, Ian Romanick wrote: On 12/13/2011 01: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. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. GeForce8+ = scalar architecture, no vectors, addresses are byte based, can access individual components just fine. Ok. So we should avoid baking this vec4 assumption in TGSI semantics. Something like: gl_ClipDistance[i - 12] = some_value; DCL OUT[0].xyzw, POSITION DCL OUT[1-8].x, CLIPDIST[0-7] MOV OUT1[ADDR[0].x - 12].x, TEMP[0]. * ** * - tgsi_dimension.Index specifying the base address by referencing a declaration ** - tgsi_src_register.Index is the only way I see to make this work nicely on all hardware. (This is also needed if OUT[i] and OUT[i + 1] cannot be assigned to contiguous hardware resources because of semantic.) I think that having indexable temps, like D3D10, would be a cleaner: The problem is that we need an indexable version of every file then (at least INPUT, OUTPUT), and then all the nice 32 bit structs break down when we get more than 16 files. D3D doesn't have these because indirect IN/OUT isn't allowed there, but it is in GL and the hardware can do it. Also, having an indexable version of every file seems odd, especially since we need a way to distinguish individual arrays inside that file anyway (just SM4 uses 2 indices to access INDEXABLE_TEMP; for INPUT we'll need 3 indices). DCL OUT[0].xyzw, POSITION DCL OUT[1][0-7].x, CLIPDIST[0-7] MOV OUT[1][ADDR[0].x - 12].x, TEMP[0]. I propose we first add this new kind of temp at a first stage, then prohibit indirect addressing of all but this kind of temps. There's already TEMPORARY_ARRAY, but no one wants to use it because it's not clear how to distinguish individual arrays ... For constrained hardware the driver can build the clunky c := ADDR[0].x % 4 i := ADDR[0].x / 4 IF [c == 0] MOV OUT[i].x, TEMP[0]. ELSE IF [c == 1] MOV OUT[i].y, TEMP[0]. ELSE IF [c == 2] MOV OUT[i].z, TEMP[0]. ELSE MOV OUT[i].w, TEMP[0]. ENDIF itself. Sounds good plan to me. BTW, I took a look at inputs/outputs UsageMasks and although we don't use them, I really think we really should, as having that info readily accessible would allow to avoid wasting time/bandwidth copying attributes which are not
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- Original Message - On 12/13/2011 04:22 PM, Jose Fonseca wrote: - Original Message - - 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. Wait, where does it do that? When I search through tgsi_ureg.c for UsageMask, all it shows are assignments of TGSI_WRITEMASK_XYZW to the UsageMask property. ah. I may be lying. But I'm pretty sure I wrote such code somewhere, sometime. Let me dig it. I was lying. I wrote tgsi_util_get_inst_usage_mask() in src/gallium/auxiliary/tgsi/tgsi_util.c , but it only analyses which registers are _read_, and never got hooked into ureg anyway. I don't want you to go over hoops just to pass a scalar quantity. So may be just add ability to ureg to specify declaration's output mask? One problem with this is that the output mask would have to be a parameter to a new declaration function in ureg, like ureg_DECL_output_with_mask() instead of just ureg_DECL_output(). In this case, ureg_DECL_output_with_mask() would be the only DECL function with a usage mask specified. If that asymmetry is okay with you, I think I could go the UsageMask route. It looks from Christoph Bullimer's reply that it might be better to describe CLIPDIST as an array after all. But FWIW ureg_DECL_output_with_mask() makes sense on its own right, as I really think we should start filling these masks, instead of assuming that everything takes 4 components. Ureg to fill them automatically from the
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- Original Message - On 15.12.2011 20:09, Jose Fonseca wrote: - Original Message - On 12/14/2011 12:58 AM, Ian Romanick wrote: On 12/13/2011 01: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. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. GeForce8+ = scalar architecture, no vectors, addresses are byte based, can access individual components just fine. Ok. So we should avoid baking this vec4 assumption in TGSI semantics. Something like: gl_ClipDistance[i - 12] = some_value; DCL OUT[0].xyzw, POSITION DCL OUT[1-8].x, CLIPDIST[0-7] MOV OUT1[ADDR[0].x - 12].x, TEMP[0]. * ** * - tgsi_dimension.Index specifying the base address by referencing a declaration ** - tgsi_src_register.Index is the only way I see to make this work nicely on all hardware. (This is also needed if OUT[i] and OUT[i + 1] cannot be assigned to contiguous hardware resources because of semantic.) I think that having indexable temps, like D3D10, would be a cleaner: The problem is that we need an indexable version of every file then (at least INPUT, OUTPUT), and then all the nice 32 bit structs break down when we get more than 16 files. D3D doesn't have these because indirect IN/OUT isn't allowed there, but it is in GL and the hardware can do it. Indirect IN/OUT is allowed on D3D9 , http://msdn.microsoft.com/en-us/library/windows/desktop/bb172963%28v=vs.85%29.aspx , but it looks like SM4 indeed doens't allow, http://msdn.microsoft.com/en-us/library/windows/desktop/ff471378%28v=VS.85%29.aspx , which means that indirect input needs spilling the inputs into a indexable temporary. Also, having an indexable version of every file seems odd, especially since we need a way to distinguish individual arrays inside that file anyway (just SM4 uses 2 indices to access INDEXABLE_TEMP; for INPUT we'll need 3 indices). Fair enough. DCL OUT[0].xyzw, POSITION DCL OUT[1][0-7].x, CLIPDIST[0-7] MOV OUT[1][ADDR[0].x - 12].x, TEMP[0]. I propose we first add this new kind of temp at a first stage, then prohibit indirect addressing of all but this kind of temps. There's already TEMPORARY_ARRAY, but no one wants to use it because it's not clear how to distinguish individual arrays
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- Original Message - - Original Message - On 15.12.2011 20:09, Jose Fonseca wrote: - Original Message - On 12/14/2011 12:58 AM, Ian Romanick wrote: On 12/13/2011 01: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. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. GeForce8+ = scalar architecture, no vectors, addresses are byte based, can access individual components just fine. Ok. So we should avoid baking this vec4 assumption in TGSI semantics. Something like: gl_ClipDistance[i - 12] = some_value; DCL OUT[0].xyzw, POSITION DCL OUT[1-8].x, CLIPDIST[0-7] MOV OUT1[ADDR[0].x - 12].x, TEMP[0]. * ** * - tgsi_dimension.Index specifying the base address by referencing a declaration ** - tgsi_src_register.Index is the only way I see to make this work nicely on all hardware. (This is also needed if OUT[i] and OUT[i + 1] cannot be assigned to contiguous hardware resources because of semantic.) I think that having indexable temps, like D3D10, would be a cleaner: The problem is that we need an indexable version of every file then (at least INPUT, OUTPUT), and then all the nice 32 bit structs break down when we get more than 16 files. D3D doesn't have these because indirect IN/OUT isn't allowed there, but it is in GL and the hardware can do it. Indirect IN/OUT is allowed on D3D9 , http://msdn.microsoft.com/en-us/library/windows/desktop/bb172963%28v=vs.85%29.aspx , but it looks like SM4 indeed doens't allow, http://msdn.microsoft.com/en-us/library/windows/desktop/ff471378%28v=VS.85%29.aspx , which means that indirect input needs spilling the inputs into a indexable temporary. Also, having an indexable version of every file seems odd, especially since we need a way to distinguish individual arrays inside that file anyway (just SM4 uses 2 indices to access INDEXABLE_TEMP; for INPUT we'll need 3 indices). Fair enough. DCL OUT[0].xyzw, POSITION DCL OUT[1][0-7].x, CLIPDIST[0-7] MOV OUT[1][ADDR[0].x - 12].x, TEMP[0]. I propose we first
[Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- 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 ? Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful for the drivers? I personally don't have nothing against it, but just like to understand why it makes a difference. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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. Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful for the drivers? I personally don't have nothing against it, but just like to understand why it makes a difference. Jose Unless my understanding of clip distances is wrong, the GPU uses clip distances to decide whether a vertex should be clipped, and thus needs to know which of the vertex shader outputs are clip distances. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 12/13/2011 09:29 PM, Christoph Bumiller wrote: On 12/13/2011 09: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 ? Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful for the drivers? I personally don't have nothing against it, but just like to understand why it makes a difference. Why does TGSI_SEMANTIC_*POSITION* make a difference ? Right, because the position values are consumed by the fixed function rasterizer. So are the clip distances. This is not about pipe_clip_state.ucp but about what this legacy cruft has to be turned into if GL_CLIP_PLANEi is used instead of GLSL 1.3's gl_ClipDistance[i]. That wasn't clear. I meant that UCP could be replaced by TGSI_SEMANTIC_CLIPDIST (which is what drivers for newer cards effectively do internally), but older cards still support UCPs separately so it best be kept alive as well. If the shader writes TGSI_SEMANTIC_CLIPDIST, UCP state can be ignored. The same mentality (What's information useful for ?) cost me TGSI_SEMANTIC_TEXCOORD and now I have to rely on a hack to make point coordinate replacement work on nvc0 (http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nvc0/nvc0_program.c#n29). I'm sorry I'm a bit sensitive on the issue of dropping information at the gallium threshold. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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. Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful for the drivers? I personally don't have nothing against it, but just like to understand why it makes a difference. Jose Unless my understanding of clip distances is wrong, the GPU uses clip distances to decide whether a vertex should be clipped, and thus needs to know which of the vertex shader outputs are clip distances. Right. Clip distance is generally written to a special register that some fixed-function hardware uses to do clipping. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- Original Message - - Original Message - On 12/13/2011 09: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 ? Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful for the drivers? I personally don't have nothing against it, but just like to understand why it makes a difference. Why does TGSI_SEMANTIC_*POSITION* make a difference ? Right, because the position values are consumed by the fixed function rasterizer. So are the clip distances. This is not about pipe_clip_state.ucp but about what this legacy cruft has to be turned into if GL_CLIP_PLANEi is used instead of GLSL 1.3's gl_ClipDistance[i]. I'm just surprised because I thought there was no more fixed function clipping. Don't know what I was thinking. Please ignore. Can you give an example of such legacy cruft? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 12/13/2011 09:58 PM, Jose Fonseca wrote: - Original Message - On 12/13/2011 09: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 ? Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful for the drivers? I personally don't have nothing against it, but just like to understand why it makes a difference. Why does TGSI_SEMANTIC_*POSITION* make a difference ? Right, because the position values are consumed by the fixed function rasterizer. So are the clip distances. This is not about pipe_clip_state.ucp but about what this legacy cruft has to be turned into if GL_CLIP_PLANEi is used instead of GLSL 1.3's gl_ClipDistance[i]. I'm just surprised because I thought there was no more fixed function clipping. nvfx and r300, and I think even r600, are probably happy to have UCPs in the interface and can make direct use of them, see nvfx_ucp_validate in nvfx_state_emit.c or r300_set_clip_state in r300_state.c nv50 and nvc0 have to use the same shader outputs for both legacy glClipPlanes and gl_ClipDistance[]. On nv50, there is shader-external state that designates which outputs are clip distances, on nvc0 they have to be written to special output slots/addresses so the semantic information is important to be able to assign slots at compile time (the GPU was specially designed to make this possible and to support ARB_separate_shader_objects nicely). In D3D10/11, there is a system value semantic for clip distances and cull distances (cull distance is a different clipping mode and consumes the same slots as clip distances). See http://msdn.microsoft.com/en-us/library/windows/desktop/bb509647%28v=vs.85%29.aspx. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- 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. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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. Wait, where does it do that? When I search through tgsi_ureg.c for UsageMask, all it shows are assignments of TGSI_WRITEMASK_XYZW to the UsageMask property. Bryan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- 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. Wait, where does it do that? When I search through tgsi_ureg.c for UsageMask, all it shows are assignments of TGSI_WRITEMASK_XYZW to the UsageMask property. ah. I may be lying. But I'm pretty sure I wrote such code somewhere, sometime. Let me dig it. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- 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
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 12/13/2011 10: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 This cannot work properly yet. For instance, the clip distance slots in my hardware's output memory space are packed, i.e. consuming NUM_CLIP_DISTANCES * 4 bytes. (This cannot be changed, except by spilling outputs to high latency memory and moving them all at the end, which is very undesirable.) The MOV OUT[ADDR[0].x].x, however, has no way to know whether to scale ADDR[0].x by 4 or by 16 bytes (as it would for arrays of vec4s) since it is not clear which declaration/output range the instruction accesses. The plan is to remedy this, at some point, by augmenting indirect accesses with an extra declaration index, and let a declaration constitute an array. This would also make the TGSI_FILE_*_ARRAY superfluous. So it would be: DCL OUT[0-8].x, CLIPDIST[0-8], making use of tgsi_declaration_range. 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
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
- Original Message - - 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. Wait, where does it do that? When I search through tgsi_ureg.c for UsageMask, all it shows are assignments of TGSI_WRITEMASK_XYZW to the UsageMask property. ah. I may be lying. But I'm pretty sure I wrote such code somewhere, sometime. Let me dig it. I was lying. I wrote tgsi_util_get_inst_usage_mask() in src/gallium/auxiliary/tgsi/tgsi_util.c , but it only analyses which registers are _read_, and never got hooked into ureg anyway. I don't want you to go over hoops just to pass a scalar quantity. So may be just add ability to ureg to specify declaration's output mask? Another approach would be just to add the property, and kill output mask. Two ways of doing the same is what I'd like to avoid. I'll need a day (it's late here) to think about this and see how output mask is being actually used in the code. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 12/13/2011 04:22 PM, Jose Fonseca wrote: - Original Message - - 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. Wait, where does it do that? When I search through tgsi_ureg.c for UsageMask, all it shows are assignments of TGSI_WRITEMASK_XYZW to the UsageMask property. ah. I may be lying. But I'm pretty sure I wrote such code somewhere, sometime. Let me dig it. I was lying. I wrote tgsi_util_get_inst_usage_mask() in src/gallium/auxiliary/tgsi/tgsi_util.c , but it only analyses which registers are _read_, and never got hooked into ureg anyway. I don't want you to go over hoops just to pass a scalar quantity. So may be just add ability to ureg to specify declaration's output mask? One problem with this is that the output mask would have to be a parameter to a new declaration function in ureg, like ureg_DECL_output_with_mask() instead of just ureg_DECL_output(). In this case, ureg_DECL_output_with_mask() would be the only DECL function with a usage mask specified. If that asymmetry is okay with you, I think I could go the UsageMask route. Another approach would be just to add the property, and kill output mask. Two ways of doing the same is what I'd like to avoid. I'll need a day (it's late here) to think about this and see how output mask is being actually used in the code. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On Tue, Dec 13, 2011 at 4:18 PM, Christoph Bumiller e0425...@student.tuwien.ac.at wrote: On 12/13/2011 09:58 PM, Jose Fonseca wrote: - Original Message - On 12/13/2011 09: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 ? Could you also elaborate on why TGSI_SEMANTIC_CLIPDIST is useful for the drivers? I personally don't have nothing against it, but just like to understand why it makes a difference. Why does TGSI_SEMANTIC_*POSITION* make a difference ? Right, because the position values are consumed by the fixed function rasterizer. So are the clip distances. This is not about pipe_clip_state.ucp but about what this legacy cruft has to be turned into if GL_CLIP_PLANEi is used instead of GLSL 1.3's gl_ClipDistance[i]. I'm just surprised because I thought there was no more fixed function clipping. nvfx and r300, and I think even r600, are probably happy to have UCPs in the interface and can make direct use of them, see nvfx_ucp_validate in nvfx_state_emit.c or r300_set_clip_state in r300_state.c R3xx-cayman all support legacy user clip planes (see r600_set_clip_state() and evergreen_set_clip_state()). r6xx-cayman also support shader exported clip/cull distance. Clip/cull distance is exported from the vertex shader (as 1 or 2 vec4s) via special export locations (similar to position, point size, edge flag, rt index, viewport index, and kill flag). See the comment starting with Special export handling in shaders in r600_shader.c. Alex nv50 and nvc0 have to use the same shader outputs for both legacy glClipPlanes and gl_ClipDistance[]. On nv50, there is shader-external state that designates which outputs are clip distances, on nvc0 they have to be written to special output slots/addresses so the semantic information is important to be able to assign slots at compile time (the GPU was specially designed to make this possible and to support ARB_separate_shader_objects nicely). In D3D10/11, there is a system value semantic for clip distances and cull distances (cull distance is a different clipping mode and consumes the same slots as clip distances). See http://msdn.microsoft.com/en-us/library/windows/desktop/bb509647%28v=vs.85%29.aspx. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On Tue, Dec 13, 2011 at 11:22 PM, Jose Fonseca jfons...@vmware.com wrote: Another approach would be just to add the property, and kill output mask. Two ways of doing the same is what I'd like to avoid. I'll need a day (it's late here) to think about this and see how output mask is being actually used in the code. I think it would be better to axe the UsageMask (unless there's a need to declare an output with the mask _Y_W for example) and add a NumComponents field. The interpolation of varyings would be less computionally-expensive if we knew the exact number of used components and the number were less than 4 (depends on hw). Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 12/14/2011 12:24 AM, Marek Olšák wrote: On Tue, Dec 13, 2011 at 11:22 PM, Jose Fonseca jfons...@vmware.com wrote: Another approach would be just to add the property, and kill output mask. Two ways of doing the same is what I'd like to avoid. I'll need a day (it's late here) to think about this and see how output mask is being actually used in the code. I think it would be better to axe the UsageMask (unless there's a need to declare an output with the mask _Y_W for example) and add a NumComponents field. The interpolation of varyings would be less computionally-expensive if we knew the exact number of used components and the number were less than 4 (depends on hw). I'd even save slots if a user only used, for example, gl_TexCoord[0].xw. You cannot make it .xy internally because of point coordinate replacement. If you want NumComponents, just do last_bit_set(UsageMask) + 1. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 12/13/2011 01: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. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
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,
Re: [Mesa-dev] [PATCH 0/2 v2] Add support for clip distances in Gallium
On 12/14/2011 12:58 AM, Ian Romanick wrote: On 12/13/2011 01: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. As far as I'm aware, all hardware represents it as the former, and we have a lowering pass to fix-up the float[] accesses to be vec4[] accesses. GeForce8+ = scalar architecture, no vectors, addresses are byte based, can access individual components just fine. Something like: gl_ClipDistance[i - 12] = some_value; DCL OUT[0].xyzw, POSITION DCL OUT[1-8].x, CLIPDIST[0-7] MOV OUT1[ADDR[0].x - 12].x, TEMP[0]. * ** * - tgsi_dimension.Index specifying the base address by referencing a declaration ** - tgsi_src_register.Index is the only way I see to make this work nicely on all hardware. (This is also needed if OUT[i] and OUT[i + 1] cannot be assigned to contiguous hardware resources because of semantic.) For constrained hardware the driver can build the clunky c := ADDR[0].x % 4 i := ADDR[0].x / 4 IF [c == 0] MOV OUT[i].x, TEMP[0]. ELSE IF [c == 1] MOV OUT[i].y, TEMP[0]. ELSE IF [c == 2] MOV OUT[i].z, TEMP[0]. ELSE MOV OUT[i].w, TEMP[0]. ENDIF itself. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
